Serverless Computing With Google Clould — Part 2
Part 2 of 2
Serverless Series
This is part of a Destructive Digital Technical series, we’ll be bringing you three awesome blogs on getting setup with a serverless architecture on Google Clouds Firebase platform. In this part, we will cover adding CRUD operations to your serverless architecture and performing nested queries.
If you’ve not read part 1 catch up below before continuing :)
Let’s Get Dynamic
Previously, we created a serverless function which would access the firestore database stored on Firebase and retrieve the location data for New York city. What if we don’t just want to the location data for New York, what if we have multiple cities and want to be able to specify what data we want for which location?
To achieve this, we’re going to make the function dynamic by accepting query parameters.
HTTP requests have a payload containing information about a request, including a query attribute which denotes any query parameter passed as a parameter in the URL.
Query parameters follow the following format:
http://mysite.com?param1=valueUsing the above format, we can get the requested city by submitting a URL with the following format:
http://localhost:5000/location-api-89e5f/us-central1/getWeather?location=las-vegasFor these changes to be take effect, some modifications must be made to the cloud function
Create a new document in the firestore with an ID of las-vegas so that it can be tested against.
Remember, compile and serve your code then head into postman to test out the new functionality.
We Want More Cities
Let’s assume that the database will need to be expanded upon with simple CRUD operations. We’re going to require a resource that allows a user to send data to a cloud function which then writes to the database.
To see the results, head into the Firebase console, your results will update in real-time on the web console.
Full Circle
Now that we have a function that can read and a function that can write to the database. The last piece of functionality left to be added to the CRUD operations (excluding delete) is an update function. It will work in a similar manner to the query based searching shown in the first function.
Nesting Data
Let’s say we have the scenario where the API returns the city data like normal however this time it also returns an array of suburbs for that location. In this scenario, we want the populations of those suburbs included with the city data. The complication is suburb populations are stored within another table on the Firestore database. Embedded queries can help to solve this problem.
Firstly, let’s setup the cities collection to include the suburb data on the new-york document
Let’s also setup the new suburb collection
I Promise This Will Work
Pun intended, getting the data from another table inside of a request poses a problem, one that we can solve with promises. Firstly, the function gets the requested city data, including an array of suburbs. Iterating over the suburbs, we can fire of subsequent firestore requests to the suburb table, each request will be added to an array which will resolve only resolve when all of the promises have resolved.
Although the above may look complex at first, it’s quite simple when broken down. Essentially it follows the process:
- Get city data
- Iterate over city suburbs
- Get suburb data
- Return city data with suburb data
Running the query in postman will return the following data
