Let’s face it, the majority of apps need backend. In this post you will learn how to use Firebase in mobile applications.
We live in a modern world where mobile has a very important role in our everyday lives. If you don’t believe – take a look at people on the streets and see how many of them are using mobile devices.
I’m also one of them and I cannot lie about it – you’re probably one of them too.
For many of us, mobile became a day-to-day life aspect, so natural that sometimes it’s easy to forget how it actually works. So let’s do a quick recap.
Nowadays, mobile doesn’t exist without a backend. That’s pretty much a fact.
Sure, you can point at some applications which are backendless, but these are a minority. Even if you would like to create a simple implementation of tick-tack-toe game, you would probably still require a backend to provide your app with some multiplayer gameplay feature or a board for your scores.
So let’s be honest – it is really important. More than that, a dedicated backend, created specifically for your mobile application is a real treasure for every mobile developer. But what if for some reason you can’t have it?
Luckily, there are some alternatives.
There is a friendly term called Mobile Backend as a Service (MBaaS). Usually, services from this group have a couple of features in common. Let’s take a look at the most popular aspects. This include:
Parse used to be one of the most popular mobile backend services. Unfortunately, on 28th January 2016 Facebook announced that they’re shutting down their product.
Here, at Whalla Labs we’ve decided to take a look at some alternatives or services which provide at least similar functionality. And now we’re going to discuss one of them. This service is called Firebase.
First of all, Firebase is not an MBaaS. Firebase is a service founded in 2011 and acquired by Google in 2014.
It is a powerful platform for creating mobile and web applications, product classified as Backend as a Service solution (which is actually a superset of MBaaS). It is not so mobile-oriented as Parse and that actually hints that Firebase may not necessarily be a good alternative for your mobile, Parse-powered application.
But what makes Firebase interesting? And what actually does it have to offer? Well, entire service focuses on three key features we’re going to discuss one by one:
It is also easy to deploy, so you can initialize a Firebase app directly from your terminal. Preparing your app and deploying your content into the external server is just a matter of few terminal commands.
Firebase hosting is also scalable. It’s based on an expanded Content Delivery Network (CDN) which has multiple points of presence around the world. No matter where you are, you can address a server with a cached copy of your content nearby. Additionally, copies of the data are stored on Solid State Drives. That makes the read/response times much shorter and content available for you in no time.
Another great feature of static content is out-of-the-box encryption. Data from your app is transferred through Secure Socket Layer. You don’t even need your own SSL certificate – Firebase provides trustworthy, signed certificate for you in your current subscription plan.
Let’s focus on an aspect important for many mobile apps which is user authentication. There are some different methods of handling authentication in Firebase.
One of them is authentication via email and password. Sounds simple, doesn’t it? And Firebase actually makes it simple as it sounds.
All you have to do is to enable this method in your app dashboard and you’re ready to go. Firebase mobile SDK (available for both iOS and Android) already provides you with some methods for handling user authentication on mobile. There’s no need to implement any networking code on the side of your app, you also don’t need to worry about password encryption. Mobile SDK handles that automatically for you.
But what if have you already built a user management system? Good news is you can still integrate it with your mobile app.
Firebase provides web developers with external libraries which can be used with existing backend solution. These libraries generate secure JSON Web Tokens (JWTs) for existing users and the same tokens are used for authentication on the side of mobile SDK. Libraries for existing session management services support most popular web development platforms including Go, Java, .NET, Node.js, Perl, PHP, Python and Ruby. This set of various technologies easily covers the majority of different backend solutions.
That all sounds great, but what about some external providers? If you want to authenticate a user using his Facebook account there’s also a solution for you.
Firebase includes support for third-party authentication providers like Facebook, Google, Twitter and GitHub. Configuration is pretty similar to user/password authentication – all you have to do is enable support for an external provider in your app dashboard and add your external application identifier with application secret.
After that, you’re all set for development – which thanks to supporting for external providers on the side of mobile SDK is also a lot easier.
And that would be pretty much it if we didn’t have one more feature to discuss – probably the most important one: a realtime database.
But what does realtime mean in this context? Well, to get a better understanding of that let’s discuss Firebase architecture first.
Most backend solutions are built on a three-tier architecture. There is a client layer: a UI-oriented application – web, desktop or mobile. In the middle, we have a business layer which is usually a web service hosted on a dedicated server and responsible for data processing and validation.
Business layer provides an interface between client and data source – that is in most cases a database engine performing read, write, delete and update operations on raw data.
Firebase is based on so-called two-tier architecture. That’s an approach used in client-server solutions which provide direct communication between client layer and data source. These elements are tightly coupled, but the greatest benefit coming from this pattern is faster response time. And that’s crucial in terms of aspects we’re about to talk about now.
Let’s take another look at one thing which is common for most backend services. Retrieving some data is based on a request-response model.As you have probably guessed, Firebase handles that a bit differently.
It’s actually focused on observer patterns used for constant data synchronization. And that actually leads to the most important factor: one change on the side of the backend is immediately reflected on the side of all client devices, without a need of sending another request (unless you really want it).
Think about it this way: you can forget about pull to refresh or any other form of refreshing your data.
If your data gets altered you will see the results on the side of your client application in milliseconds. And there is no need for any user interaction to achieve that.That’s what realtime means.
That’s what realtime means.
So let’s talk about what’s underneath the platform.
First of all, Firebase uses a NoSQL JSON database engine. If you’re a software developer, there’s a really high chance you’re already familiar with this data exchanging format. On the architectural side, NoSQL databases are common in many web & mobile solutions thanks to their responsiveness and scalability.
Communication between database and client application is handled via web sockets. That’s actually one of the tricks Firebase uses to provide the realtime functionality to developers and end users. Of course, such approach forces you to handle your mobile application code more efficiently.
If you’re interested how to do that take a look at our presentation – we discussed this matter during Poznan iOS Developers Meetup.
A pretty interesting thing we haven’t mentioned before is that Firebase allows your mobile app to work both online and offline. This is achieved by caching your data in a convenient way – mobile SDK creates a buffer in volatile memory (up to 10 MB) to keep an exact copy of the data you’ve already synchronized.
Thanks to that buffer you don’t have to worry about losing your Internet connection – even if you lose it, your app will stay responsive. And if think that using volatile memory is not enough, you can always enable persistency and save the data additionally to your device’s disk. All changes made offline will be correctly synchronized after your Internet connection is restored.
There’s also one more thing – if you’re worried about data safety and integrity because of the fact Firebase uses two-tier backend architecture we have a good news for you.
Every separate node in your JSON tree can be configured for read, write and validation rules thanks to expression based rules language. That allows you to limit read and write rights to match specified criteria (for example: only for a specific user) and validate any input to keep your data integral.
At the end of the day, would you like other users to modify your own profile? Of course not, and that’s what expression rules are for.
As you might have already noticed there are some major differences between Parse and Firebase.
The first one is purely a mobile-oriented solution with some features like push notifications or app analytics which are missing in Firebase. Sure, there are some aspects which are common to both platforms but comparing them is like comparing apples to oranges.
Does your application need a solution like Firebase?
It depends on what you want to achieve. If you’re highly focused on realtime data synchronization, user authentication and ease of use it may be a good choice for your app.
If you’re building a mobile messaging app there’s a pretty high chance Firebase could be a way to go, but if its features are not necessary for you, you may want to start looking for some alternatives.
We’re happy to discuss any Firebase-related aspects so feel free to post your comments or questions below. You can also join our newsletter to receive more articles like this in the future.