This is a part of the series of posts on Getting memcache up and running on Kubernetes which explained how to create your first cluster and Installing memcache with Kubernetes which installed some memcache instances on your cluster and Exposing a memcache loadbalancer which makes it available externally.

Creating a test App

The test App is going to be a small API that provides access to some of the features of Star wars API. I picked this one because it’s open and doesn’t need authentication. The objectives of the next few articles are

  • Create an API external to Kubernetes that can use the memcache instances hosted on the Kubernetes cluster
  • Create a containerized version of the APP and run it on Kubernetes.
  • Run serverless versions of it
  • Look at the difference between timings using and not using cache and across versions
  • Create an Apps Script version
  • Demonstrate cache sharing across each of these platforms

The App

You’ll find it on Github. Let’s just look at the main points, as it’s a standard Express app in most respects.


The settings – are in secrets.js, which is not on GitHub – you’ll need to make your own. It looks like this.

The c9 and ku properties are to support multiple versions and are the “mode” referred to in index.js. Notice that they are different host addresses depending on whether the app mode is inside (via the cluster internal network) or outside (via the loadbalancer service) the Kubernetes cluster. I also use a silo parameter to encode my keys, and also to be able to use the same cache server for different domains of work.


The API will support only 2 kinds of endpoints for now

  • A search – for example /starwars/people?search=luke
  • An ID get – for example /starwars/people/4



Note that a get will be wrapped in a timer and a cache worker. This to make logging of timings straightforward, whereas the cache wrapper will first attempt to get the result from cache. If it fails it will do a regular fetch and write the result to the cache.


There’s quite a bit of code here for use further down the line, but for the demo we only really need to look at the get and put functions. In order to obfuscate the key I’m hashing the url with the silokey from secrets.js.


Here’s the package.json

Does it work?


time without cache
897 ‘ms to complete’

timing with cache
hit: 25960109ae793d5f3e351a5fb946726963a35f7c
14 ‘ms to complete’

timing with cache (after stopping and starting the app)
hit: 25960109ae793d5f3e351a5fb946726963a35f7c
29 ‘ms to complete’

by id

time without cache
837 ‘ms to complete’
timing with cache
hit: e734c2859ba4cd5c71e900ac3e99c802fca94f8c
12 ‘ms to complete’
timing with cache (after stopping and starting the app)
hit: e734c2859ba4cd5c71e900ac3e99c802fca94f8c
27 ‘ms to complete’

Next step

So that was quite a success, even though the API is running outside the Kubernetes cluster. Next we’ll make a container so it can be run inside the cluster.

Why not join our forum, follow the blog or follow me on twitter to ensure you get updates when they are available.