Serverless in the Google Cloud with Firebase & Cloud Functions

Earl Gay
Earl Gay
Jan 28, 2018 · 5 min read

Google Cloud Platform’s best kept secret is Firebase. Firebase is Google’s “Mobile platform that helps you quickly develop high-quality apps and grow your business.” In short, it provides a lot of awesome development services like Authentication, Hosting, Real-time Database, and more. In fact, it even takes Google Cloud Functions and adds new triggers, so that you can kick off functions from events that seemed unavailable otherwise!

If you look at GCP’s Products & Services list, or even if sign up for a GCP account and start navigating the console, you will see scarce if any reference to Firebase directly. On the products page, for example, if you search the page for “Firebase”, there is a small link in a bottom footer to go to (next to Google+ links and Chrome Dev links) and that’s it. In the GCP Console, there is no direct link from the navigation area.

Your first thought(s) based on that are probably either “Firebase must not be very important” or “I guess GCP doesn’t have those services.” Fortunately, neither are true! Combining the power Firebase & GCP equals a stellar serverless platform.

My Journey to Firebase

Cloud Functions is still technically in BETA and has some areas for improvement at the time of writing this post:

  1. Only available in us-central1
  2. Only supports Node.JS
  3. Limited triggers: Pub/Sub, Storage, HTTP/S, and Firebase; (E.g. doing a time-based trigger requires some clever workarounds)

Like with most GCP services, Google does a good job of providing tutorials through sample use cases: The first thing I needed to figure out was authentication of the HTTP/S trigger for my serverless app. In the AWS world, I would front my function with API Gateway and integrate a Cognito Authorizer there, but that isn’t exactly how it works in GCP.

There is actually an article on “Authentication in HTTP Cloud Functions”, but it uses a pretty convoluted (in my opinion) method of checking for storage.bucket.get access:

Google Cloud Functions HTTP Authorization Scheme from GCP Article

Enter Firebase Authentication

Google Cloud Function Auth through Firebase Authentication with Firebase Hosting Front-end

The above diagram shows how the authentication works at a high-level. The user accesses the static site hosted on Firebase Hosting, which provides client-side authentication through Firebase Authentication. That Firebase Authentication token is then passed to the Google Cloud Function and verified; if verified, the function runs. The demo code really only verifies that the user has a Google Account and nothing more (more granular access is left as an exercise to the reader).

Deploying a Serverless App with Firebase

Deploying an application with Firebase can be as simple as:

  1. Creating the Firebase Project
  2. Installing firebase-tools on your system through npm: npm install -g firebase-tools
  3. Logging in at the CLI with firebase login
  4. Configuring what Firebase project to use with firebase use --add
  5. Deploying with firebase deploy

The firebase tools also come with local emulators, including for Hosting & Functions, so you can test as simply as: firebase server --only hosting,functions then browsing to localhost your local dev machine!

Firebase Projects tie to GCP Projects, and Cloud Functions within Firebase deploy within the GCP Console as relatively normal Functions. I wish the UI was a bit better integrated, but the services on the backend work well together regardless.

There are a lot of tools within Firebase beyond hosting and functions, so I encourage everyone to check them all out. I suspect most folks will be very impressed.

Breaking Down & Extending the Sample Code

Function Modifications

  1. I wanted to be able to call the function directly (e.g. through Postman) with a token, so I added the /token route which displays the token that can be placed in the Authorization header inside Postman for example.
  2. Added a /world route to show it’s easy to just keep adding routes here, if desired.

Front-End Modifications

  1. I prefer to use Bootstrap for my front-end components versus the included usage of Material Design Lite, so index.html was modified to swap these.
  2. I added some basic look and feel components like a navbar.
  3. The original code included showing usage of direct Authorization and using the __session cookie. I swapped it to simply use the Authorization method. (Site note: The __session cookie can be set if you want to be able to call the Cloud Function directly from another tab for example, but isn’t really required for persistence within the app.)
  4. Added a card that shows the User’s details (e.g. Display Name, Email, etc.) after logging in.
  5. I swapped in jQuery over vanilla javascript just as a personal preference.
  6. Included some logic for creating the API URL for portability (e.g. more cleanly define the URL for all cases).

End Result

More Information

Earl Gay

Written by

Earl Gay

Practice Manager, @roundtowertech | Mobility, Cloud, and Random Technology | Posts are mine and don’t represent my company.