Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap #116

Open
Lusitaniae opened this issue Jun 24, 2020 · 3 comments
Open

Roadmap #116

Lusitaniae opened this issue Jun 24, 2020 · 3 comments

Comments

@Lusitaniae
Copy link

Any plans on adding new features?

E.g. adding new fields (like product image),
make body field optional,
adding search filters (e.g. size between/less/bigger than),
booleans (has feature X: yes/no)
or this point in the readme "Only searches for entire words. There are no search suggestions (yet)."

I have no experience building search engines so not really aware what is easy or good idea to build or not.

@mre
Copy link
Member

mre commented Jun 24, 2020

Just started creating a roadmap here thanks to your suggestion.
About your points:

adding new fields (like product image),

Not against that, but bundling images into a wasm blob will increase the file-size. If it's just a link to an image, that can be done in the body. tinysearch only uses the body as a corpus of information to match an entry, so it's possible to do that.
But yeah, adding/renaming/removing fields would be nice. On the other side, I want to keep tinysearch simple and... well... tiny because once custom fields come into play, a remote service like Algolia might to a better job.

make body field optional,

Good idea! Can you create an issue for that to track development?

adding search filters (e.g. size between/less/bigger than),

Not sure. Do you have a concrete use-case? Sounds like an advanced feature that not many users might understand or even know it exists. On a technical note, tinysearch is not storing any keywords from the body, just the information if they "exist" - e.g. if they were added to the Bloomfilter before.

booleans (has feature X: yes/no)

Sounds like this could be useful for a shop system or a filter tool. I might be missing something, here. Would like to get the pure search functionality right before thinking about possible extensions. ;)

or this point in the readme "Only searches for entire words. There are no search suggestions (yet)."

Yeah, I don't have an idea for a datastructure which stores prefixes without blowing up the wasm binary size. Maybe we can find a neat trick that doesn't consume more storage in the Bloomfilter if searching for a prefix.

Keep the ideas coming. 😄

@Lusitaniae
Copy link
Author

Lusitaniae commented Jun 24, 2020

Thanks for the feedback, this is also new to me, so just thinking out loud.

  1. new field: image - this is for displaying results in the frontend, we would only need an url for this.

  2. New PR about making body optional: Make body field optional #117

  3. Lets say I have a shop and I want to select products at least 1 meter wide, or between 1 meter and 2 meter, or over 2 meter.

As mentioned I was thinking what would be nice to have, not sure how's that gonna work with this project hah

Maybe along with 1) if we return additional fields to the frontend we could do additional filtering, even without tinysearh engine.

@mre
Copy link
Member

mre commented Jun 24, 2020

Great!

  1. We could eventually support a tinysearch.toml, which would allow for that sort of customization. Would think about that after 1.0, which is a little down the road I'm afraid. I'll keep a mental note, though.
  2. Thanks!
  3. Yeah that would be outside the scope. One could think about a filter system built in wasm as a separate product, though. Or maybe there will be plugin support eventually, but it's unlikely. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants