Event-Driven Sending with Google Cloud Functions
While catching up on my cloudy cloud news a while back, I read about, and then watched an event-based approach to triggering and coordinating various types of actions. While not a unique approach, this struck me as a remarkably simple flow, and it stayed in the back of my mind.
The gist is that various Google services make it easy to run code after saving stuff to a database; basically a trigger, although in this case they’re asynchronous from the session that’s saving stuff. The “run code” part can include arbitrary logic, such as calls out to the SparkPost API, for example, which is the direction this blog post will be taking. Once we have the basics in place, there are lots directions for experimentation (I heard “passwordless” in the back…), so let’s get started!
Before We Can Send
One caveat is that in order for Cloud Functions to make external API calls, you’ll need to enable billing. There is a substantial free tier for the relevant services. Suffice to say there shouldn’t be any costs associated with testing out this sort of thing.
We’re going to be living on the edge here, using a product that is still in Beta as part of this system: Google’s Cloud Functions. Not quite bleeding edge though, since we’re not using Google’s Cloud Firestore database, which is also in Beta. It’s nice when stuff keeps working, and one unstable API is enough for right now.
So let’s take this tech out for a spin with our proof of concept project! In case you’re disappointed that there’s only one Beta product in this blog post, the good news is the majority of the concepts we’re talking about here still work, no matter your tech stack.
Storing as Little as Possible
Storing juuuuust enough data to enable a “passwordless” login, means all we really need from each user is an email address. Firebase’s Auth system lets you collect and store this info a couple of ways. The easiest is using Google Sign-In, which automatically authenticates using e.g. your signed-in GMail session. Since not everybody uses GMail, the more consistent way is to use the “create an account” option.
In order to be able to call this system “passwordless”, we need to make it so that you don’t have to remember a password. We’ll generate a temporary password, store it in the database, and email it to you as part of an auto-sign-in link. When you click on the link, the system logs you in and expires the generated password.
We’re also storing as little code as possible, since there’s really not a lot of custom code involved at all. In this system, for example, there are more lines of code for handling UI interaction than for the Cloud Functions themselves.
Responsible Transactional Email
Since we’re responsible senders, we’ll need to use a Confirmed Opt-In process, which means you can’t just subscribe with any old email address. Well, you can, but unless the person who gets email at that address clicks the confirmation link we send, that’s the only email they’ll get.
Thinking about how to prank your friends is a good way to figure out how a system might be abused. Case in point: a good feature to add would be including a link in the confirmation email that lets the recipient add their email address to a suppression list, so their hilarious friends can’t send them 400 login request emails.
Not everyone is ready for “passwordless” logins, so giving your users the option to use an Identity Provider (“Sign in with Google”, etc) or a traditional username and password login is a good idea.
Google’s Cloud Functions work well with SparkPost’s API, especially since there’s a Node library ready to install. This project was a fun introduction to Cloud Functions, and makes me want to explore other possible integration points between the two services.