Exploring Google Cloud API Gateway with Google Cloud Functions

Create a secure API Gateway that can handle params and form data (file uploads) and forward them to appropriate cloud functions

We all love APIs. Anything you need or want from the internet, chances are either there is an API for that or you can build one. So that’s what we did. In our organization, we built APIs for almost all the tasks that we could offload to the servers. But then, we had too much API. So we needed some service to perform two crucial tasks for our APIs:

1. Make a common gateway for all the related APIs to keep the APIs triggers structured, generic, and easily manageable.
2. Make the publically open APIs more secure.

Since all of our APIs are hosted on GCP, it was natural that we opt for Google API Gateway. Now let’s see how Google Cloud API Gateway solved our issues.

Prerequisites

I am assuming that you will have the following resources ready. If not there are links attached that will help to get you started:

1. GCP account with the billing activated. If you don’t have one yet you can create a new one using the free tier at $300.
2. A GCP Project
3. Google Cloud Functions ( I am using Google cloud functions but you can use App Engines and Cloud Run too).

The API Gateway can be configured using an OpenAPI spec 2.0. Before we can get into writing the actual API Config file we will need to enable the following services so that we can deploy the gateway.

We can also enable these services using the GCloud Console using the following commands:

The API gateway is made of 2 components:

1. API config: The API configuration created when you upload an API definition. We will create the API definition as an OpenAPI spec. Each time we upload an API definition, API Gateway creates a new API config. That is, we can create an API config but we cannot later modify it. If we later edit the API definition in the OpenAPI spec and then upload the edited API definition, we create a new API config.
2. Gateway: An Envoy-based, high-performance, scalable proxy that hosts the deployed API config. When we deploy an API config to a gateway it creates the external facing URL that our API clients use to access the API.
   Gateways are deployed to a specific GCP region (A region is a specific geographical region where we can deploy resources).
   The gateway must also host an API config. We cannot create an empty gateway i.e., all gateways need an API config however it can only support one API config per gateway. However, after a gateway is created, we can update the gateway to replace one API config with another.

Creating the Gateway and API Config:

Now that we are done with the theory, let’s get into the most exciting part: writing the actual OpenAPI spec file for the API Gateway. This is just for creating the API Config. If you want to know how to set up the gateway that will hold this Config file, just follow the steps given here.

So let us first create a basic spec file that just forwards the request depending on the path:

Now that we are done with that. Here is the part that I struggled with. Now I had a cloud function that I needed to pass 1 path param and query param and 1 form data(an image). So let’s deal with the passing of the params first. In the following gist I create a new path that passes our params:

Now for the final part of uploading the image file via form data. Well, this is surprisingly the easiest part as the API gateway does this automatically. Any attached data is automatically forwarded.

Securing the API:

Now, this is another aspect that is very important to us. Most of our APIs were publicly available. We could, of course, make them private and use Google’s JWT tokens to authenticate but the JWT tokens are short-lived and we didn’t want to go through the process of generating a new one every few hours for the plethora of devices and apps where we were using our APIs.

Enter API keys, which are manually generated and a single key can be used on a gateway to verify against all the APIs linked in the gateway. There are other ways to verify(JWT, Firebase, Auth0, Okta, Google Id tokens) but this is what we are going with.
Now if you want to know how to generate API keys, just follow the documentation given here.

Once we have generated API keys we can use them either as query params or header params to authenticate.

Use API key in our application bypassing it with key=API_KEY parameter for query param or x-api-key=API_KEY for the header params.

This will require us to change the API config file.

This is the final API Config. Also, remember to block unauthenticated invocations in our cloud functions, or else there will be no point in securing the APIs.

Now if we hit our API and get an error along the lines of “PERMISSION_DENIED: API is not enabled for the project.”, what we will need to do is :

1. Go to APIs & Services.
2. Click on ENABLE APIS AND SERVICES on top of the screen
3. Search for the name of our gateway.
4. Enable the API

And we are done with setting up our Gateway.

When I started working on the API gateway I found this to be an interesting and potentially very powerful service. Still, there was a lack of detailed documentation, hence this article. I hope you guys will have fun going through this service.

Thanks for reading! Share this article if you found it useful.
Please do Clap 👏 to show some love :)

Let’s become friends on LinkedIn and GitHub.