Fast and scalable client-side search with Instantsearch & ItemsJS
As a small starting web store you would like to have a search function: a function that almost every website has. A suitable solution is important. You want an easy implementation and always have a good performance, even when your business grows, more products are sold and an upgrade is needed.
Hereby not all possible functionalities are important and for example analytical data is less interesting for a start-up company. Also, the costs of a paid service can quickly add up. That is why Unplatform came up with the idea of programming a suitable solution for these start-ups. In this article we describe the approach that we have chosen; Instantsearch combined with ItemsJs.
What is Instantsearch?
"InstantSearch.js is an open-source, production-ready UI library for Vanilla JS that lets you quickly build a search interface in your front-end application."
Algolia.com
Through various widgets you can quick and easy build a front-end search functionality. These widgets are available as components in React, Vue and other frameworks. You can configure these components completely to your preference, for example to have them filter on a certain field. Also, you can turn on/off functionalities of the component.
The creator of this UI library is Algolia. They also sell a back-end service themselves. This obviously works well together, as it is made by the same company. However, the use of a search service with extensive features is often not necessary. Certainly not for a web store with a limited number of products.
ItemsJS
In order to find a good alternative to an extensive search service, research was conducted. In this research, it was determined that client-side search should be in the list of requirements, because this way of loading pages is efficient and therefore fast. This is useful for a search function, because the page often changes and thus needs to be reloaded.
Several client-side libraries were investigated, and ItemsJS came out as the most suitable candidate for this project. The research included looking at the desired functionalities and other factors such as good documentation and maintenance. Based on these criteria, the two best options were compared in a POC, where speed performance was measured. The two best options both scored high on the functionalities offered, the documentation was fine and they are actively maintained. However, ItemsJS had a better performance and that was the deciding factor in choosing ItemsJS.
The ItemsJS library takes care of indexing your dataset. This involves smartly storing the information so that searches can be performed quickly. This allows you to perform text and facet based client-side searches. Also, this library allows for the use of many other features.
ItemsJS can be seen as a back-end. It should be mentioned that it is not a back-end service. ItemsJS runs completely client-side and thus has the functionality of a back-end, but does not run on a server.
The solution: an adapter
To link ItemsJS with Instantsearch, a library was built to translate the Instantsearch logic into something ItemsJS understands and to translate the ItemsJS result back into Instantsearch logic. To publish this code, an NPM package was made available: Instantsearch-ItemsJS-Adapter. The package is public and can be easily implemented at different web stores. This makes the code reusable.
The adapter can be used in your front-end application with Instantsearch. The image below shows a schematic representation of the project. The user, shown top left, communicates with Instantsearch. Subsequently, various back-end solutions can be linked to the Instantsearch components, as shown in the image with the examples of Algolia and the Instantsearch-ItemsJS-Adapter.
Because the different back-end solutions use the same front-end, they can be interchanged relatively easily without changing anything for the user. For example, a company with a small catalog can start with ItemsJS. And as the catalog grows, it is relatively easy to switch to Algolia, for example, for more features.
Which back-end will you choose?
In the picture above, it is clearly visible that Algolia and the adapter both use the same front-end and can therefore easily be exchanged. One can thus choose to start with the (in use) free adapter and later upgrade to Algolia. This is where the consideration for more functionalities comes in. This concerns functionalities such as analytical data, marked results and auto complete. The Readme of the adapter gives a complete overview of which features are and are not available.
You can try out the adapter implementation on the Demonstration website. Feel free to take a look. The code of the Adapter and Demo are open source.
If you have any questions, please contact us through our contact form or send an email to info@unplatform.io.
