In the previous post I described what the UK Government’s new Performance Platform (made by GDS) is for. Today’s question is, how does it work?

I’ve found out two ways. Firstly, thanks to Alex Muller from GDS, who talked me through the platform. Secondly, all the code is freely available on Github, which is pretty.

Component parts

There are three main parts to the Performance platform.

1. Backdrop is where the performance data is stored. It’s written in Python, on top of MongoDB. It has an API for accepting new data and querying data. Its feature tests are a readable way of finding out what it can do.
2. Collectors (e.g. from Pingdom) gather up data from a particular service, convert it in format, and write it to the performance platform (using Backdrop’s API). They can be on the web or in data centres.
3. Limelight is the beautiful user interface on top of all this. It’s written almost entirely in Javascript, building interactive pages like this by calling Backdrop’s API. (There’s also a new project Spotlight, which will be a successor to Limelight).

Private vs. public data

Collectors by their nature have access to private data about individuals. The smart thing about them is that they always aggregate this, reducing it to information that can be made open.

This means it is IL0 (“Information Level Zero”) in G-Cloud terms, that is to say data that doesn’t need securing. Advantage one to open data!

This is also why the GDS team call them “collectors”. They gather up the (often) private data and convert it into public data, posting just that to the performance platform. The other name people use by accident is “connector”, which makes it sounds like a live connection – that would be much harder to secure.

JSON API

The API that Backdrop offers can be easily found by inspecting the network traffic when you view a Limelight page.

For example, if you open the “network debugging” feature in your browser while going to the Lasting Power of Attorney page and show only AJAX requests, you see a list of the API calls made to assemble the page (see picture).

For example, this URL gets the kinds of help people have requested in the last week and has these parameters.

• start_at: 2013-10-28T00:00:00+00:00
• end_at: 2013-11-04T00:00:00+00:00
• filter_by: eventAction:help
• group_by: eventLabel
• collect: uniqueEvents

Editing the parameters gives quite informative error messages to find out what other options there are. Since Backdrop’s source code is available you can read it to find out more. The validation function is a good starting point, and also the example Backdrop API responses which are part of Limelight’s tests.

The call returns the data in straightforward JSON, so it’s easy to use from any other program.

This is the second in a series of posts about the performance platform – next time, what are the implications for open data?