Adventures in Serverless Architecture with Firebase, Zapier & Cloud Functions

James Morgan
5 min readMay 16, 2017

--

Recently I began working on what was at first a small CRM/tracking based application for a client. My employer being new to the world of software development I decided to go for a solution which I thought would fit the immediate requirements, be cost effective and relatively cheap to run as well providing me with some useful features out of the box such as authentication, ideally backed by a full JavaScript stack for speed.

The solution developed was a browser based web app written in Firebase and AngularJS. The application running completely in the browser, 100% Serverless with only a Firebase API, hosted by Firebase.

What is serverless architecture…

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”)

Nearly a year went by with new requirements, work flows, common application changes/improvements all of which were capable with the chosen architecture & stack. Requirements then started to appear which meant that the fact I have no traditional backend API posed quite a problem. Some features are just not suited to being run on browser e.g. PDF generation, email integration, payments etc.

After some research and prototyping I decided to solve this problem with Zapier. A great tool for wiring up 3rd party integrations without writing a single line of code.

Zapier quickly allows you to integrate multiple APIs together, providing a wizard to combine data points and APIs.

Later on when Google purchased Firebase I was thrilled, having spent many hours working with Firebase I was looking forward to seeing how Google would enhance it further, and enhance it they have!

Along came Firebase Functions, currently in beta this is from the docs…

Cloud Functions for Firebase lets you automatically run backend code in response to events triggered by Firebase features and HTTPS requests. Your code is stored in Google’s cloud and runs in a managed environment. There’s no need to manage and scale your own servers.

So I started to think about how I could utilise this. Below I will go over details of two examples which I have successfully used to solve common problems using Firebase functions. More examples can be found here.

Logging & Monitoring

Having the app running client side only made it harder to get good visibility on what the application was actually doing, especially when errors happen.

The solution chosen is totally serverless with no complex code, hopefully no scaling issues or extra services to manage, no additional costs & backed by a pay as you go costing structure. Firebase Cloud Functions seems like a good fit!

Below is some high level architecture describing exception logging by the client to Firebase, triggering a Firebase Function, forwarding this on to Slack.

Angular -> Firebase DB -> Firebase Function -> Slack Channel

Firstly making a basic exception handler which can easily be written for most modern client side frameworks. This then writes any issues to Firebase DB e.g. /exception/{exception-payload}

An example of the Firebase function for forwarding these to Slack is below.

Firebase functions simply allow you to glue other services to your serverless stack, executing arbitrary code on the triggering of data events.

Exception alerts now come via Slack straight from the browser.

As you may already know there are paid-for services available which can do this sort of thing but here we’re getting that for free!

Email Integration

The company spends a lot of time and effort chasing up emails. The requirement to integrate these emails into the CRM system soon became apparent.

The implementation is slightly more complex than the exception logger above in that I need to parse and match the email, associating it to a specific Firebase ref e.g. an issue raised by a supplier or a problem at a particular location. Any emails associated to these should only be seen and viewable when looking at that issue or supplier in the application.

The way I solved this is also completely serverless, easy to understand and utilises Zapier & Firebase functions, also so far been cheap to run and maintain.

Firstly a staff member will cc/bcc or forward an email to particular email address, ensuring the subject contains a key which can used to matched on later.

Zapier then receives this email and pushes it in a specific format on to a Firebase DB ref e.g. /email/raw/{email-payload}

I then use a Firebase function which runs when something is written at this path. I parse and attempt to match the email using the key in the subject.

Once matched I format and write the email to the correct location, deleting the raw email once complete. This whole process takes about 6 seconds according to the Firebase console and runs 24 hours a day, 365 days a year with minimal to no overhead or maintenance!

This is the basic breakdown of what the script does e.g.

As you can see above the two examples are both relatively simple but demonstrate how you can add more traditional server side features to a serverless application with minimal effort and minimal code.

Not all things will be solvable with tools such as cloud functions and Zapier but from my experience many of them are.

I plan on posting further details on how I have used other new additions to the Firebase stack in the near future.

I now have a common pattern for serverless integrations this could be used for many purposes including overnight scheduled jobs, alerting, SMS integrations, print jobs, etc.

I now don’t need a server, do you?

Happy firebasing…!

--

--

James Morgan

Founder of @knownorigin_io @BlockRocketTech @blockchain_manc — NFT nerd, crypto enthusiast, lover of music, humanist, mostly found hacking web3