HowTo Video Tutorial Script (567 words)

We’re getting to the final part of these build 101 series. During this section, we will be focusing on the user-facing side of search. We’ll start by analyzing in details the composition of an API response.

Then, we will cover the two main ux patterns for implementing search and how our front-end libraries can help you speed up the implementation process. Finally, we will go over step by step video screencast that will walk you through how to create an InstantSearch experience.

Before diving into that exciting agenda, there’s one topic we have to cover first.  Where does the API call should originate from? Is it from the front-end or from the back-end? There are two ways of implementing the user-facing product search using Algolia.

Here’s a simplified query’s journey for front-end implementation. At each user keystroke, this is what’s happening under the hood. Everything starts with a user action, either a keystroke in the search bar or a click on the filter.

Then the client sends a query to Algolia’s server, Algolia processes the query and fetches the relevant records, Algolia sends back the API response to the front-end and finally the front-end renders the results.

This is the back-end alternative of the same search query. First, is the same user action, a keystroke in the search bar or click on the filter. Then, the query is sent to the back-end app, the back-end uses the Algolia’s API client to send the query to Algolia’s servers.

Algolia processes the query and fetches relevant records, Algolia sends back the API response to the back-end server and then the back-end server forwards it to the front-end, which finally renders the results.

At Algolia we believe the front-end implementation is the best option for two main reasons: speed and availability. For speed, a front-end implementation would hit our service directly without going through your back-end.

Can be up to 10x faster for the end users to retrieve the results. Another reason is our distributed search network, we have a distributed API allowing you to select multiple data centers around the world. This allows your users to target the closest server, which has a huge impact on latency. This can only work for a front-end implementation.

The final reason is availability. With the back-end implementation, your server becomes the bottleneck of your search. Algolia’s infrastructure was designed for availability and reliability. Each customer’s apps are hosted on three different servers so, even if two of those servers are down, search queries will still be properly handled.

Same goes for the network, with the back-end implementation you follow some network routes, even if there’s only a local program in the network, all of your users would be affected.

Having a front-end implementation, in case of a network issue, the outcome for your users will be greatly mitigated, thanks to our redundant DNS and our retry strategies built into our front-end libraries.

We now have a good outline of the UI implementation part and also have a good idea of the front-end vs back-end implementation. In the next video, we will be analyzing the Algolia search API response.

This is the basic common element whether you’re using one of our libraries or not. This is what you’ll get from the Algolia API, so it’s crucial to understand its composition.