Serverless from the ground up: Building a simple microservice with Cloud Functions (Part 1)

Do your company’s employees rely on multiple scattered systems and siloed data to do their jobs? Do you wish you could easily stitch all these systems together, but can’t figure out how? Turns out there’s an easy way to combine these different systems in a way that’s useful, easy to create and easy to maintain—it’s called serverless microservices, and if you can code in Javascript, you can integrate enterprise software systems.

Today, we’re going to show you an easy way to build a custom content management system using Google Cloud Functions, our serverless event-driven framework that easily integrates with a variety of standard tools, APIs and Google products. We’ll teach by example, following Alice through her workday, and watch how a lunchtime conversation with Bob morphs into a custom document repository for their company. You could probably use a similar solution in your own organization, but may not know just how easy it can be, or where to start.

Alice and Bob both work at Blueprint Mobile—a fictional company that sells and repairs mobile phones. At lunch one day, Bob tells Alice how his entire morning was lost searching for a specific device manual. This is hardly surprising, since the company relies on documents scattered across Team and personal Drive folders, old file servers, and original manufacturer websites. Alice’s mind races to an image of a perfect world, where every manual is discoverable from a single link, and she convinces Bob to spend the afternoon seeing what they could build.

Alice’s idea is to create a URL that lists all the documents, and lets technicians use a simple web app to find the right one. Back at her desk, she pings Carol, the company’s intranet developer, to sanity-check her idea and see if it will work with the company intranet. With Carol’s help, Alice and Bob settle on this architecture:

The group gathers to brainstorm, where they decide that a microservice called handsetdocs should return a JSON array where each element is a document, belonging to a handset. They sketch out this JSON structure on a whiteboard:

Then, they decide that Bob will build a repair shop web app that will interact with Alice’s microservice like this:

Alice takes a photo of the whiteboard and goes back to her desk. She starts her code editor and implements the handsetdocs microservice using Cloud Functions:

This is the first code that runs when the service’s URL is accessed. The first line sets up Cross-Origin Resource Sharing (CORS), which we’ll explain in more detail later. The second line of the function calls getHandsetDocs() and returns the response to the caller. (Alice also took a note to look into IAM security later, to make sure that only her colleagues are able to access her microservice.)

Alice deploys the getHandsetDocs() function in the same file as handsetdocs above. Her first draft of the function is a simple hard-coded list of documents:

Finally, Alice reads up on Cross-Origin Resource Sharing (CORS) in Cloud Functions. CORS allows applications running on one domain to access content from another domain. This will let Bob and Carol write web pages that run on the company’s internal domain but make requests to the handsetdocs microservice running on cloudfunctions.net, Cloud Functions’ default hosting domain. You can read more about CORS at MDN.

Alice puts all three functions above in a file called index.js and deploys the handsetdocs microservice as a cloud function:

The code in getHandsetDocs() won’t win any prizes, but it allows Bob and Carol to start testing their web apps (which call the handsetdocs microservice) within an hour of their discussion.

Bob takes advantage of this useful microservice and writes the first version of the repair store web app. Its HTML consists of two empty lists. The first list will display all the handsets. When you click an entry in that list, the second list will be populated with all the documents for that handset.

To populate each list, calls to the handsetdocs microservice are done from the app’s Javascript file. When the web page first loads, it hits the microservice to get the list of docs and lists the unique handset names in the first list of the page. When the user clicks a handset name, the docs keyed to that handset are displayed in the second list on the page.

This code solves a real business need in a fairly simple manner—Alice calls it version 0.1. The technicians now have a single source of truth for documents. Also, Carol can call the microservice from her intranet app to publish a document list that all other employees can access. In one afternoon, Alice and Bob have hopefully prevented any more lost mornings spent hunting down the right document!

Over the next few days, Bob continues to bring Alice lists of documents for the various handsets. For each new document, Alice adds a row to the getHandsetDocs() function and deploys the new version. These quick updates allow them to grow their reference list each time someone discovers another useful document. Since Blueprint Mobile only sells a small number of handsets, this isn’t too much of a burden on either Bob or Alice. But what happens if there’s a sudden surge of documents to bring into the system?

Stay tuned for next week’s installment, when Alice and Bob use Google Sheets to enable other departments to use the system.