Serverless autocomplete with OpenWhisk

Autocomplete is everywhere. As you type into a web form, the page offers you completions that match.

An autocomplete service consists of three components:

Three components of an autocomplete service

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

Let’s see three ways we 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 is executed locally.

client-side autocomplete

This approach provides faster performance, but is 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 with a Redis database

For this to be quick enough to respond as a user types, the server needs to be geographically close the client and connected to a very 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 the Bluemix CloudFoundry platform and a Redis database.

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 microservices do be deployed on a pay-as-you-go basis. The more computing capacity you use, the more you pay: from zero to lots.

serverless client-server autocomplete

Our autocomplete service can bundle the both the data and the code into an OpenWhisk “action”, so we 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 our architecture means we have to do the indexing and lookup logic in our own code, but I’ve built a utility that builds an OpenWhisk autocomplete action for you. Just add data!

First you 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:

The acsetup utility indexes your data, bundles it with an OpenWhisk autocomplete algorithm written in Node.js and sends it to your OpenWhisk account. 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 auto-complete services as you like:

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

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

f you enjoyed this article, please ♡ it to recommend it to other Medium readers. For more from Glynn, see his articles on the Watson Data Lab Medium or check out his work at http://www.glynnbird.com/.