Should I Use Firebase?

Firebase is a web app development platform created by Google. It lets you develop the whole app on the front-end without any server-side code. At the same time, it does let you set up some server-side logic via Firebase Functions if you need to react to certain events (creation of data or files, login, https requests) so you can send emails or push notifications or process the data after it is written.

It’s easy to start a project with Firebase or add a Firebase to your project. It allows real-time database connection, which means multiple users can see the changes in the data when the data gets created or edited. Data transmission is handled with web sockets so you don’t have to send requests to get new data, you only need to subscribe once.
The same applies for file storage. Quick setup authentication via the major providers (Google, Twitter, Facebook, GitHub). Https by default - secure http traffic without setting up certificates. Any static html/javascript content can be hosted.

• Android
• iOS
• Web - plain JavaScript or using Angular, React, Ember, Polymer, Backbone and other with a firebase library for your framework i.e. angularfire2.
• Other (C , Unity)

Note: not every platform has support for all the features. For example, reactfire currently has bindings for real-time database operations, but not for authentication.

Limited database query language - one can’t set up multiple conditions, there are no grouping or aggregates, no schema requirements. User access rules exist, but they set certain requirements in terms of how the data needs to be organized. Database data types are limited. These currently supported are string, number, boolean, null.

Firebase is already being used by the following companies:
The New York Times, The Economist, Shazam, duolingo, Alibaba, todoist, Viber, TuneIN Radio, Runtastic and others...

We chose to build a simple todo application to see what are the main benefits of Firebase and what are the challenges in building a Firebase app. The idea was that the user opens the web page, adds tasks to the list and then each day gets a notification email with a list of tasks for the day. Additionally, the email contains info about your overdue tasks and a list of tasks you’ve completed the day before. Angular was chosen as the framework - it has a native Firebase library which lets you perform user authentication and access data.

One of the main challenges turned out to be the organization of data in the database. At first, we tried the simplest approach: a collection called todos has objects inside of it, which are stored by user Id as their key, inside of them the tasks are stored with unique Ids as keys. Right now Firebase Database queries are limited - certain query options can’t be combined.

Because of one of the main challenges turned out to be the organization of data in the database. At first, we tried the simplest approach: a collection called todos has objects inside of it, which are stored by user Id as their key, inside of them the tasks are stored with unique Ids as keys. Right now Firebase Database queries are limited - certain query options can’t be combined. Because of this, we had to choose, either we want to order the documents by date or filter them with user’s search query on the database side and perform the other action on the client side.

Later we decided to use the user’s email as the key for their data - and quickly realized that emails can’t be used as keys because they contain dots, so the dots had to be replaced with commas for storage and backward at the stage when the email notifications are sent. This turned out to be a poor decision - in Firebase there is no easy way to restrict user access if the data is stored with anything else other than the user UID.

At some point, we decided to rewrite the code to group the data by date in addition to grouping by the user. Without grouping, everything could have become slow at later stages when there would be a lot of data. Another reason was that with documents grouped by the date it would be much easier to get the data for notification emails - we could just query by date.

In the past, there was a Firebase component called queue that provided intermediate logic for data writes. After the point where users wrote to the queue, some server logic could have been added to process and write the data to the appropriate collection. But this project seems to be no longer maintained and is largely replaced with Firebase Functions. We tried to recreate the queue with Firebase Functions and it could have been done but wouldn’t be pretty.

Firebase Pros and Cons

• used firebase blocks (components);
• auth;
• realtime db;
• functions (backend).

Authentication

Pros

• easy to set up with angular-cli and angularfire2;
• painless authentication with Google;
• db rules: access only when signed in.

Cons

• limited to supported services (Google, Facebook, Twitter, Github, email, phone).

Realtime db

Pros

• auto realtime db connection with angularfire2 (based on sockets)

Cons

• not flexible
• db queries are limited (example: can't use orderBy with one key and equalTo with another key)

Functions

Pros

• more or less any node.js module can be used

Cons

• difficult to debug

Firebase is great for quick projects: it’s easy to set up, fast, in many cases requires only front-end logic. It lets you focus on your app instead of implementing custom authentication, web sockets or database connections. The drawback is that you have to organize your app to be as simple as possible i.e. read and write operations without complicated business logic.

PS. Since the article had been written UKAD teams have started using Firebase for notifications and analytics and we’ve loved it.