Serverless Autocomplete

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:

1. The data, a list of strings defining the accepted values for a web form.
2. The code that navigates the list, comparing the typed input with accepted completions.
3. The front end that renders the matches under the web form, allowing an answer to be picked.

The three basic components of any autocomplete service: data, code, and a front end.

Now, I’ll consider three ways you might deploy autocomplete in practice.

Client-side autocomplete

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.

Client-side autocomplete: bundle it all in the browser.

This approach gives you the fastest performance, but it’s only suitable for small data sets.

Client-server autocomplete

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:

Client-server autocomplete: a server-side process and a database server work in tandem to get the browser its data.

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.

Serverless autocomplete

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:

Serverless autocomplete: The browser’s request triggers a new serverless function with bundled data. The code runs on-demand, with no servers to maintain.

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.

First, you’ll need Node.js and npm installed on your machine, together with the OpenWhisk wsk utility paired with your IBM Bluemix account. Then simply install the serverless-autocomplete package:

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 names.txt

The acsetup command configures an autocomplete service for you, and provides usage examples.

The 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 curl statement.
• 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:

acsetup uspresidents.txt
acsetup soccerplayers.txt
acsetup gameofthrones.txt

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 acsetup.

Happy searching!

If you enjoyed this article, please ♡ it to recommend it to other Medium readers.