Serverless API with Google Cloud - Re-building the Medium claps button

Basically, it’s a one-liner:

Tadaa!

That one is available through the firebase-tools package.
You may first need to create a project on https://console.firebase.google.com/ and to configure the resource location:

Install the CLI and select your project:

Then, you can use the Firestore emulator:

I added a Makefile to run/restart those two daemons quickly. You can find it on this GitHub repo.

Well, you are all set. You can start programming now!

For the claps button, I copied the code from the codepen.io snippet and that just worked as expected.

The Javascript part comes with callback functions, ready to be integrated to your website.

🐥 Pretty basic but that’s enough. So as you can see, only 2 API_URI endpoints are consumed by this snippet: one with GET, the other one with POST.

Cloud Functions come with an optional Framework. Its purpose is to give your code some portability across:

So, that sounded right enough to me to get started with it. As of writing, the Function Framework is available for Node.js and Go lang.

Hereunder, you’ll find two versions of my Claps API, with very similar implementations. One with Node.JS, the second one with GO lang.

Repo ⭐ https://github.com/bcollard/gcloud-functions-nodejs-claps

Nothing much to say about the code. I could take benefit of the Express web framework for routing and applying some middleware.

The dependency management in Node.JS is simple and searching for libs on npmjs.org makes things quick & easy.

Also, I switched from npm to yarn because that latter looked more robust, fast and secured.

Endpoint: https://europe-west1-personal-218506.cloudfunctions.net/claps

Repo ⭐ https://github.com/bcollard/gcloud-functions-go-claps

The start was a bit tricky because I could not find a web framework similar to Express.js. I even asked to contributors of the Go Function Framework for some support and it sounds like they are thinking about it.

Meanwhile, I’m using this trick to create a secondary HTTP multiplexer (http.ServeMux).

Alternative GO endpoint: https://europe-west1-personal-218506.cloudfunctions.net/Clapsgo

The connection is technically done over gRPC and is wrapped by the firebase dependencies.

The Firestore client API is pretty similar between Node.js and Go lang 👍

Here is another piece of surprise. It’s about connecting our Google Function to a managed GCP service. It’s a good practice to not expose your Redis to the Internet. So you need internal routing.

Luckily, GCP’s got your back. Thanks to the "VPC Access Connector", you can plug Google Functions to any other VPC you own or to Google managed services, like Memorystore.

Create a VPC

Create a VPC Access Connector

Grant access rights to the Service Account used by the Function

Add a Redis Memorystore

Get the private IP

This is the last step where you will bind your function to the VPC Access Connector.

Simple deployment:

Alright, everything is up and running on GCP! 👌

The only input I get from my client is the Referer header. So I pass it through a simple Regular Expression matcher and that’s it.

Of course, it’s easy to bypass with a programmatic HTTP client (CLI or lib). Here is the GO version:

Easy to bypass as well, I’m just slowing down the attack speed. Below is the javascript version, with a middleware function passed to Express:

That’s again a simple one but effective though. Here is the Go version:

Here comes some throttling! First, the javascript version with the redis-rate-limiter lib:

Finally, I wanted to see if I was able to protect a particular endpoint with OAuth, only accessible to me.

I just looked for the Google’s OpenID Connect endpoint (see my article about OIDC) and used adequate libraries to consume it.

So, the workflow is pictured right here:

The function authorizes the access only if:

It’s a bare minimum, although it’s also advised to check for the aud and exp claims validity. I’m not checking the token expiration date because, in my implementation, I’m asking for a new token every time the endpoint is called (not reusing tokens).

In practice, I’m using the openid scope so that my Client gets an id_token, and the email scope so that the email claim is present.

With Go, it looks like there are 2 different official packages dealing with Google Authorization servers: golang.org/x/oauth2/google and google.golang.org/api/oauth2/v2. The latter looks to be more recent.

If I were to implement a rate-limiting solution in real enterprise context, I would go for the solution #3, based on a API Manager, for sure! Because it’s great to have a central place for enforcing security rules and, as I said earlier, for many more reasons!

Option #2 would fit in a more traditional IT, where there is not yet a API governance in place.

Solutions numbered #4 and #5 are just not serious hacks and I hope you will never have to do that! 😀

In my example, the Node.js lib uses a basic rate-limiting implementation. Once you have reached the limit, you have to wait for the next period to end. If I were to use a larger time span, like say one hour, then a malicious user could reach the limit within a few seconds and then be blocked for the next 59 minutes.

Hopefully, there are some better rate-limiting algorithms, like the "GCRA". It’s like an improved leaky bucket algorithm. Maybe you don’t want to read this great article, so let me picture the "leaky bucket" algorithm for you. Imagine you fill a bucket with some water. The bucket has a leak so that some amount of water is escaping at a constant rate. Once the bucket is full, you just have to wait for a few seconds before filling it again with small drops of water. Well, you got it. That’s a more permissive rate-limiting approach but the downside is that it depends on a third-party "dripping" process that might not be fast enough. The GCRA correct this with a time-centric approach and maths.