Which way of deploying an autocomplete service is right for you?
Autocomplete is everywhere. As you type into a web form, the page offers you completions that match. An autocomplete service consists of three components:
- The data, a list of strings defining the accepted values for a web form.
- The code that navigates the list, comparing the typed input with accepted completions.
- The front end that renders the matches under the web form, allowing an answer to be picked.
Now, I’ll consider three ways you might deploy autocomplete in practice.
When the data size is small (say, less than 100 options), then it makes sense to bundle the data and the code into the front end itself. When the web page is loaded, the entire list of options arrives at the web browser and the autocomplete logic executes locally.
This approach gives you the fastest performance, but it’s only suitable for small data sets.
For larger data sizes, it becomes impractical to have the web page download the entire data set. Instead, the web page makes an HTTP call to a server-side process which queries a database and returns the matching answers:
For this process to be quick enough to respond as a user types, the server needs to be geographically close to the client and connected to a fast database — typically an in-memory store like Redis. I wrote last year about a Simple Autocomplete Service that creates multiple autocomplete API microservices for you using Bluemix and Redis.
But there is a third way.
Instead of deploying server-side code that runs 24x7 waiting for autocomplete requests to arrive, “serverless” platforms like Apache OpenWhisk™ allow your micoservices to be deployed on a pay-as-you-go basis. The more computing capacity you use, the more you pay: from zero to lots.
With this minimalist approach, your autocomplete service can bundle both the data and the code into an OpenWhisk “action”, so you don’t need to have a separate database:
Bundling the data and the code in the same serverless package makes for faster performance with fewer moving parts and automatic scaling.
Building a serverless autocomplete service
Removing the database from your application architecture means you’ll have to implement the indexing and lookup functions yourself. To reduce the repetition, I’ve built a utility that builds an OpenWhisk action for you.
npm install -g serverless-autocomplete
Take a text file of strings that you want to use and run
acsetup with the path of the file:
acsetup utility indexes your data, bundles it with an OpenWhisk autocomplete algorithm written in Node.js, and sends it to your OpenWhisk account. Here's what it returns:
- The URL of your service.
- An example
- An HTML snippet that you can use in your own web page — simply save it as an HTML file and open it in your web browser.
You can create as many autocomplete services as you like:
Each service will have its own URL and is ready to use immediately. If you need to change the data, simply update the text file and re-run
If you enjoyed this article, please ♡ it to recommend it to other Medium readers.