App Engine vs Firebase — Welcome to Bizzaro World
It’s almost 2018, and you’ll be looking for a new year’s resolution. Here’s are some good ones:
- I’m going to admit I can’t be trusted with user credentials
- I’m going to stop writing my own user authentication flows
The heat on user credentials is so high now that unless you’ve got a dedicated team building and analysing your authentication systems, managing identities, and monitoring potential breaches in real time, you’re setting sail on the high seas in a leaky dingy, just waiting for a big wave to smash you into oblivion.
Like most of you, I have to deal with existing systems that hold credentials and yada yada, what’re you going to do. But what I can do is stop making it worse.
Can’t someone else do it?
Google, Facebook, Twitter, Github, there are lots of public authentication providers out there. It’s complicated to support them all, but to do that, you can use third party services like Auth0.
In the case of App Engine projects, we have a great built-in option in the Google Cloud Platform.
Or, well, almost in the Google Cloud Platform. It’s in the Bizarro World Cloud Platform, otherwise known as Firebase.
Firebase — the Bizarro App Engine
Why have one of something when you can have two or more subtly incompatible options? Google loves to do this, with operating systems, social, and chat apps, so why not with cloud platforms?
Those of you who are familiar with App Engine will be used to using it in a standard client-server kind of manner, ie: Platform as a Service:
Firebase, like Google Cloud Platform, is full of cloud services for complex software systems. However, unlike standard GCP (and particularly App Engine), its roots are as Backend as a Service, which comes out of the mobile world, and services mobile developers’ particular aversion to writing back end systems. The architecture looks like this:
Notice that the clients talk directly to the services in Firebase, using special SDKs for web and mobile environments, with your javascript Cloud Functions code (boo! what about a decent language!) being triggered by those services based on events occuring in the other services; the clients never call your code, you can’t build APIs.
This is in contrast to App Engine, where you must write an API for your clients to call, and you then talk to other GCP services on the client’s behalf.
The really positive thing about the Firebase’s bizarro world architecture is that it does some things better. Most notable for my purposes are authentication and change notification (via Firebase Authentication and Realtime Database, respectively).
The difficult thing is that, while App Engine and Firebase don’t really fight like Superman and Bizzaro, they don’t stitch together particularly easily either. It’s a bit of a cat-dog. Let’s look at the architecture:
This is the basic architecture that I’ll be fleshing out with code in the next couple of articles. The basics are:
1 — The Client will authenticate via Firebase Authentication.
2 — It’ll then have an authentication token to use when talking to App Engine.
3 — When significant events happen in App Engine that we want the client to know about, we’ll push the info into Firebase Realtime Database.
4 — The Firebase Realtime Database will push changes up to the client. The client can also query the Realtime Database as desired.
You’ll notice that I’ve expunged Cloud Functions from the picture; we wont be using them here. I want to this setup to still feel like a simple Python based App Engine app, so let’s not get into writing javascript for node.js.
Also note that we wont be putting much into the Realtime Database; it’s expensive ($5/GB!). We’ll just use it for change notifications, and put real data in Cloud Datastore.
What’s next?
In the next article we’ll get into actual code, as I tackle steps 1 and 2 above, using FirebaseUI. We’ll end up with a useful skeleton which deals with sign-in / sign-out in a single page web app using Firebase Authentication, talking probably to a Python Flask back end.
Post Script: What about Cloud Firestore?
I’ve left out the new hotness, Cloud Firestore. While I’m intrigued by it, I just can’t quite work out how to use it.
Firebase’s Cloud Firestore is GCP’s Cloud Datastore (ie: Megastore), with a few very cool changes:
- It’s simpler; no arcane key structures, no classes, just simple collection + item structures
- It has realtime notifications for clients, like Firebase’s Realtime Database
- It scales like Cloud Datastore.
Unfortunately, it’s got some drawbacks too:
- It’s missing some of the power of transactions in Cloud Datastore.
- When you use Cloud Firestore in an App Engine app, you can’t use Cloud Datastore
- Customisation requires use of Cloud Functions (and even then they don’t have the power of, say, a pre-put handler on an ndb model class). You could write a generic cloud function that just passes through to a python appengine app I suppose.
But the biggest drawback for me is that, because it’s part of Firebase, the architecture looks like this:
My problem with this is, it wants me to put my database between my external callers and my back end code. Which is a really cockamamie architecture, to my mind.
I understand why it wants to work this way; done this way, you can do realtime change notifications to clients properly, and integration with the rest of Firebase is better. But, I just don’t see how you build a really serious back end app in this configuration, and if you don’t want to build something serious, how are you going to make use of a megastore-based solution (which is mightily powerful, but requires careful handling)?
In the docs, it’s clear that the Web (browser side javascript), Android and iOS libraries are the first class citizens, and server side environments are second class citizens. Python requires the firebase-admin library which is a bit of a bastard to get going on App Engine (although this is an issue with other firebase services too).
