Should I Use Firebase for Push Notifications for My App?
For many newcomers to the mobile app industry, Firebase (FCM) is their ground zero when it comes to mobile engagement. Run by Google, Firebase is a mobile application development platform. As it has the Google brand attached to it, it has the strength of public awareness behind it. So a lot of beginner mobile apps default to using Firebase for mobile engagement. But should they? Let’s take a look at some strengths and weaknesses, and how they compare to OpenBack.
Download our FREE Mobile Marketing Playbook to perfect your user engagement game!
What Is Firebase?
Firebase is an all-in-one platform that provides mobile backend as a service (MBaaS), letting you build apps without having to manage the infrastructure. It is a real-time database that provides the tools and services to continue managing those apps. Essentially, it offers the skeletal frame of all the basics needed to run and promote an app. This includes analytics, configuration, file storage, and, yes, push notifications. This frees up the developer to focus on designing and optimizing the app experience. The services exist in the cloud, with scaling that takes place with little to no input from the developer.
According to Doug Stevenson, Firebase products
“have backend components that are fully maintained and operated by Google. Client SDKs provided by Firebase interact with these backend services directly, with no need to establish any middleware between your app and the service. So, if you’re using one of the Firebase database options, you typically write code to query the database in your client app.”
Firebase offers seamless synchronization of data across all of a developer’s clients. It also includes a handful of extensions, currently in beta. These include translating texts, triggering emails, and so on. Basically, it can be a useful tool for developers who want a standard, ready-made backend to build their app on.
When Should You Use Firebase?
As an app development platform, there are certain reasons you might want to use Firebase. It comes in handy when you want to share preferences across multiple clients, or to easily allocate data for each user in such services as browser history, etc. Other scenarios include:
- When your app has minimal integration with third-party players or legacy systems – so long as there is no heavy data processing
- When you’re writing a new app from scratch. Firebase gets the basics out of the way, and offers easy storage of dynamic content
- When you have a short development time for the app and want easy creation of prototypes
- When you need easy integration with other Google services such as Google Ads, Ad Map, Play Store, etc.
What Are Firebase’s Shortcomings?
Again, this is fine for beginner developers, or those only interested in having a basic, functional app. But for developers who want more of a bespoke app experience, or who have a large app with more than 100,000 users, Firebase becomes problematic.
Data Hosting and Migration
With Firebase, data is hosted on servers owned by Google, meaning you will be unable to export your app’s user data. To do so, you must contact Firebase and request to have the data migrated. This is at best inconvenient, and may cause issues for those concerned with ownership and agency over data. Security rules are also limited, meaning Firebase is not optimal for building enterprise platforms over.
Data migration is also a pain point. The sort of process that would be easy with, say, an SQL database becomes difficult with Firebase. App are only able to send limited queries to obtain structured data. Moreover, data synchronization is a time-consuming process. NBN Minds advises:
“If your data model needs something more than a single join query, never choose firebase.”
Anyone with any experience with Firebase will agree: if your app needs to perform any sort of deep or complex querying, DO NOT use Firebase as a backend. Even a simple function like reversing the order of elements in a dataset requires complicated circumnavigating. Overly complex queries will likely result in inconsistencies.
What’s more, Peter de Croos points out that relational queries are a no-go:
“You can either query all of the elements that have the same sub-element (and you know how Firebase queries are now) or store an ID and have it somewhere else, necessitating setting up two different listeners and performing the join yourself on the client. Neither is going to be NICE by any sense of the word.”
Other Tools and Services
When it comes to integrating with microservices, using Firebase will slow down the process. Because it caches data in its memory, unused references will not be released.
What’s more, Firebase doesn’t support Business Intelligence tools. This means developers building on the platform will have a difficult time using certain BI services.
How Does OpenBack Compare as a Mobile Engagement Platform?
If you are a user of Firebase, you can use its cloud messaging service (FCM) at no additional cost. However, as is often the case, when you trust your mobile engagement to a platform that bundles push notifications together with many other services, the end result can suffer.
FCM’s inadequacies around sending push notifications lie in their basic architecture. That is, their model is build around the Google cloud servers, which all Firebase notifications have to go through. This is problematic for two reasons.
First, no matter how reliable FCM claims their notification system is, messages are not going to reach their destination in perfect real-time. As is the case with any process that involves a third party (the other two parties being the app backend and the individual users who are receiving notifications), sending the push token out of its way to a cloud server is going to result in something of a time lag.
Moreover, with Firebase continuously syncing data between its servers and users’ devices, this opens questions about the vulnerability of data to breaches. The Firebase database can be accessed by a simple API, with the onus on developers to provide security. In 2017, a staggering amount of data was found to be leaking from apps using Firebase.
OpenBack improves on the inefficiencies and vulnerabilities of FCM by removing the need for the third-party server all together. Using a patent-pending edge computing technique, OpenBack uses device-side metrics and data triggers to check when to send a push notification. This means push notifications take the most direct route to their destination, with no lag time spent in third-party servers. What’s more, user data stays on the device. So there’s no risk to data privacy due to vulnerabilities on the backend.
Find out more details about OpenBack’s innovative approach to push notification reliability, and download our whitepaper here!