Query Suggestion / Autocomplete

[imraan-go]

Does MeiliSearch support word autocompletion from the documents?

[Kerollmops]

Hey @imraan-go,

Unfortunately, we do not support this feature but you can upvote it or even add it on our public roadmap and our PM @gmourier will take care of prioritizing it.

Could you just give more information on your use case, please?

[rome2o]

Hi @Kerollmops,

We'd do a +1 here.

Our use case is that we are creating mobile-friendly ecommerce user front and wants to show a dropdown autocomplete as they're writing. This would certainly increase conversions.

Currently this works on our side with Algolia however it does not seem to be supported in Meilisearch as of today. Is it correct?

[curquiza]

Hello @rome2o

Thanks for your feedback! Indeed Meilisearch does not support this so far.
I've moved this discussion to the right repo, so the product repository. The product team is managing here the user feedback to prioritize the Meilisearch roadmap!
So, feel free to detail your need and usage, it would be definitely helpful! 🙏

[samueljess]

We were also about to implement Meilisearch for an e-commerce project until we realized there is no autocomplete. It's a necessary part of a successful e-commerce UX.

[gmourier]

Hi @samueljess 👋

Can you give us more details on what you mean by auto-complete?

Thanks!

[samatzp]

@samueljess

Autocomplete feature of Youtube:

[psvnlsaikumar]

I am not sure if @samueljess is referring to the same feature as the one in YouTube.
because you typically get the hits as responses (refer : https://docs.meilisearch.com/reference/api/search.html#response)
It's up to the engineer how he wants to utilize this API to design a UI for that.

[gmourier]

Hello everyone 👋

I've started to think more about the autocomplete feature lately.

I identify two interesting capabilities and I would like your confirmation on some points.

• It allows opening Meilisearch to query suggestion feature (for example, searching an intermediate index to suggest queries bringing results that have led to a larger documents click rate or that have been searched the most over a specific period of time (popularity?) by other users).
• It also allows you to show a search query history from the previous users' search sessions.

For example, for the query suggestion, you could build an intermediate index for which you send documents having this form, depending on what you want to push for your suggestions.

{
   "query": "summer red dress"
   "clicks": 1546
}

or

{
    "query": "summer red dress"
    "popularity": 156
}

At the time of the search, you send two queries in parallel. One for the index that contains the documents (the classic one) and one for the suggestion index. Then you display, for example, the first 10 results coming from the suggestion index on top.

Concerning the search history, you could store in local storage (or elsewhere), the query terms that the user has interacted with afterward (e.g. clicked on a document in the search response for those terms) and display them when the user activates a focus event on the search bar.

All this is already possible via workarounds on your side AFAIK. If you have tried this, what are your frustrations with it? If not, why haven't you done it?

Am I missing any use cases?

[aradalvand]

Hi @gmourier; I would like to implement a similar workflow in our application; but I have a few concerns which I need some guidance on.

Let's say we have a queries index with documents that look like this — at its core, it just stores the search queries that users have used:

{
    "id": "<some-guid>", // Basically useless, but unfortunately Meilisearch does not accept documents without IDs.
    "query": "macbook pro",
    "score": 142,
}

Pretty self-explanatory and very similar to what you described; the score field roughly represents the number of times a given query was searched, for example (though you could have some more sophisticated heuristics for calculating it as well).

The main issue I've been facing is this: Whenever a user searches for a certain query, we need to either add a new document to the queries index for that query, or update the existing one if there is already a document for that particular query. Is that correct? Is that what you had in mind too? It seems to be that that was what you were trying to describe, judging by the examples you provided.

And if so, then how would you actually go about implementing this? — in terms of calls to the Meilisearch API, what would be the calls, exactly (I don't mean at the time of search, but at the time of creating these queries documents)? Is there a reliable way to ensure the uniqueness of the query field in this index? I'm a bit confused by how this would have to be set up.

I'll appreciate it if you point me in the right direction.

[louaykamel]

Hey,

I would simply hash the query string and use the hash as "id". And most importantly have frequent filtered deletes to reduce low hits queries.

[Strift]

Hello there 👋

Meilisearch now supports autocompletion via the autocomplete-client library.

If you give it a try, I'd love to hear your feedback 😄

[onurusluca]

Is there way to incorporate autocomplete with our own custom UI?
It looks like one needs to install 3 librarires for this functionality.
Is there a way to just send a request to Meilisearch and get the suggestions only?
Isn't this way better? Cause not everyone uses the algolia UI.

[Ra0R]

@onurusluca You can, but you need to go pretty deep. Here is an example (from Algolia):
https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/react-renderer?file=/src/Autocomplete.tsx

[Strift]

Hello, and thank you all for your contribution to this discussion.

The Meilisearch team has started working on a proposal solution, which we shared in a Request For Comment discussion.

Please use this new discussion to give your feedback. Thanks, everyone 🙌