This is one of a series of articles about Going serverless with Firebase. You many want to read about Firebase cloud functions and Custom domains and ssl with Firebase hosting before this article.

The dashboard

Ephemeral Exchange provides a history of api usage through it’s console. For now it’s of academic instance, but if it were a chargeable service, you’d need some evidence to base those charges on. The previous architecture used Redis to store such historical data, since the overhead would be small with such an in memory cache. Using Firebase cloud functions introduces a new problem as these are stateless and the overhead of recording to a database that a transaction had happened could be more than the effort of doing and storing the transaction.
The dashboard shows this kind of info for an account
along with a breakdown by the access key that generated the activity
Over time that can be quite a set of data, so I started to think about whether google analytics could be used as a free way to store this. Some advantages are
  • it’s free
  • it’s very fast with minimal latency
  • it has built in a real time reports for management and troubleshooting
In the end I used the Analytics measurement protocol to record events – where an event was any kind of api access. That means I can look at real time analytics like this, where I can even see the exact operation that’s being performed and how busy the API is
Or I can use the regular analytics reports to get more detailed stats such as usage by account code

Custom definitions

This all becomes possible through the use of custom definitions, which you can find in the settings page of your analytics property.
I have set up these customs dimensions
and this custom metric

Hitting analytics

The measurement protocol  allows you send messages to Analytics with some standard parameters that are going to be used in canned Analytics reports, but also some custom values that you can access later in custom reports, or in my case, using the analytics reporting API. These custom dimensions and metrics are defined by their index number, mapping back to those defined earlier in the custom definition section.
The efx API Cloud function uses these definitions to map back to those index numbers.
Requests to the measurement protocol are fired like this
The batch function returns an object that can be used to send multiple requests in one go
and a utility to convert an object to url parameters
Parameters are set according to the measurement protocol. Appropriate fields are sent using the standard parameters (remember that no personally identifiable data can be sent to Analytics), and the custom dimensions are used to send additional stats about API usage, which I’ll retrieve later.
and finally a post request to analytics
at this address

Retrieving the data

There’s a very handy node module which provides a wrapper to access all the google apis from Node. It’s in Alpha but it works very well
With that it’s just a case of authentication using a service account downloaded from my cloud console, using this code
and then constructing the rather long winded reporting analytics request resource. I won’t go into the details of that here, but note how the custom dimensions and metrics can be requested using their index numbers. This is how to get back all the data that was posted using the measurement protocol so it can be used for reporting to create the usage stats in the efx dashboard.
The complete code for the cloud function, including the analytics piece is available on github
For other articles on this topic see Going serverless with Firebase. 

For more like this, see Google Apps Scripts snippets. Why not join our forum, follow the blog or follow me on twitter to ensure you get updates when they are available.