Firebase: Serverless Notifications ?!
Before Google IO ‘16, I was a bit unsatisfied with Firebase, searching for a better solution. Why? Because Firebase is supposed to be an all-round solution and only covered most but not all of our Problems. Let’s take a look what happened so far. This article will mainly focus on Notifications and FCM.
What are our Problems?
Data Persistence
Yes, this problem is covered with Firebase very well! As a developer you don’t need to take care of this. There may some cases, where you could wish of other behaviours, but to be honest, I cannot think of one.
Authentication & Authorization
This is covered by Firebase, too. The only problem we have is, that it is limited to a couple of 3rd Party OAuth Services. Which are (at the point of writing) Google, Twitter, Facebook and Github and optionally email and password.
Not perfect, but enough for most of the cases.
Notifications
What do we need notifications for anyway? Well, a simple case would be, someone writes a comment to some content in your app. The author could be notified with a notification about it.
Before Google IO ‘16 this wasn’t possible at all. There was a (nice and impressive) talk last year (2015) by Frank van Puffelen. I’ve been asking him about this problem. He came up with “not supported yet, but…” and a quite nice workaround.
He said (Frank, please correct me if I am wrong ;) ):
Use a small server component (it could be even a raspberry i.e.), which you also connect to the Firebase database, “listen” the to a specific dataset and trigger a push when a new element gets created.
This sounds easy to achieve, since Firebase offers a couple of SDK’s for different languages. If you take a look at these SDK’s, you’ll see that they all have a method which listens to data changes in the dataset.
Now all the time the “queue” dataset changes we get a message in our micro-backend via the Firebase SDK and send a push to the devices which registered a push token for this message.
With this knowledge it is possible, but brings up an issue we were hoping to avoid when using Firebase. We have to store device push tokens of the users. This comes with the problem of multiple devices per user and… . Let’s cut this down, it’s not the best solution and a backend required (even though it’s small).
Another approach could be listening on dataset changes in the client itself and create a notification using the Android NotificationManager if required. This comes with other problems. There must be a service running in background listening to the changes. How about in doze mode?! How does this effect the battery life? How about iOS? There are too many of such questions, telling me that this is a workaround only, not a convenient solution.
What changed on Google IO 2016?
As I heard at IO is, that there’s no server-side component required anymore to send notifications. I was super excited because finally we can write our apps without any additional backend at all.
During last week a friend and me thought about an app. And both of us were very excited to finally take a look into the new firebase all-round solution.
As we came to the point of notifications we saw that they splitted the topic into two different things, Firebase Cloud Messaging (FCM former GCM) and Firebase Notifications.
What’s the difference?
Firebase Notifications is an option to send a notification to your App, meaning that you can set a title and a message which will be delivered to your App. If the app is running in background, the user will get a notification in the system tray, tapping on it will open the app. Sending additional data is possible too, so you can jump into your app, even to a specific screen (using this optional data). Even in foreground the messages can be received. More details about Firebase Notifications you can find here. This solution comes quite close the one iOS offers. Silent pushes, if the app is in Background, are not possible with Firebase Notifications.
So you can send notifications to the user, but you have to do this manually or time based.
Firebase Cloud Messaging is basically the replacement for the former Google Cloud Messaging. With this you can also send silent pushes, meaning that you can decide if you want to show a notification or not. So you have to add your Messaging Service and an Instance Id Service, then you can handle the message yourself… . Wait a moment, if we have to create our own InstanceIdService, where do we send the push tokens? A backend is required again.
We end up with the same problem as described before.
Use Firebase Notification for our purposes instead?
Well, it would feel a bit like an eunuch, because silent pushes are not possible, but it could be possible, since most of the time we want to show a notification anyway. If there would be any way of sending an automatic notification on dataset changes.
Firebase-Team, please hear our screams! An easy (and imho for Firebase not that difficult to implement) option would be to trigger some events on specific dataset changes (maybe definable similar to your permissions-approach. Like: added, changed, removed). These events could be then available in the Firebase Notifications Console to trigger the push (Notification).
At the moment this is not possible either.
Other downsides
Firebase Notifications is enabled automatically. As soon as we integrate any kind of push (via FCM), even if we don’t need Firebase Notifications, we’ll have it. You can see this taking a look your apps merged manifest. This is because they’re using the same dependency “com.google.firebase:firebase-messaging”. That also means that there’s a Service running in background for this kind of notifications, pointless if you’re not using it.
From the UX perspective this is not good for the users. When marketing people find out that this can be used in every app (ios, android), they could (and some probably will) miss-use this, until the user switches off all notifications.
Summary
Firebase made big steps, announced at Google IO ’16. Cloud Messaging-wise they added a feature called Firebase Notifications, which is reasonable in their grow- and not in their developer- section. Firebase doesn’t offer a dataset-event based notification functionality, which makes us still depending on our own backends.
Update 03/13/2017:
Since the 9th of march Firebase introduced “Firebase Functions”. This is supposed to solve this problem already. Havn’t had the time yet to take a closer look.
