Backend InstantSearch

Who should use this guide

Advanced InstantSearch users may have the need to query Algolia’s servers from their backend instead of the frontend, while still being able to reuse InstantSearch widgets. Possible motivations could be for security restrictions, for SEO purposes, or to enrich the data sent by the custom server (i.e. fetch Algolia data and data from their own servers). If this sounds appealing to you, feel free to follow this guide. Keep in mind though that we, at Algolia, recommend doing frontend search for performance and high availability reasons.

By the end of this guide, you will have learned how to leverage InstantSearch with your own backend architecture to query Algolia. Even if you’re not using Algolia on your backend and still want to benefit from using InstantSearch, then this guide is also for you.

A quick overview on how InstantSearch works

InstantSearch, as you probably know, offers reactive UI widgets that automatically update when new search events occur. Internally, it uses a Searcher interface that takes care of making network calls to get search results. The most important methods of that Searcher are setQuery(text: String), used to update its search query, and the suspending function search() which gets called when InstantSearch requires a new response that you will get from your backend. Let’s see how this works in action:

Basic implementation of a custom backend

• Implement your own BackEndSearcher: Searcher<ResponseSearch>, implementing the Searcher interface.
  • In setQuery, store the given text for future requests.
  • In search, call your back-end and return search results in the ResponseSearch format.
  • In search, call search() asynchronously and return the corresponding kotlinx.coroutines.Job.
  • In cancel, cancel any pending query.
• Use this Searcher in place of SearcherSingleIndex in your application.