What is firebase and how to use it with web apps

What is Firebase?

Firebase is a light version of Google Cloud. You get essential cloud functionalities for app developers well packed and served through web based admin panel, CLI and specific lang packages. In most projects I prefer to work with Firebase rather than AWS. The reason is simplicity. Working with full cloud potential that is offered by AWS, Google Cloud or Azure is rarely needed for most app developers. That's why Google wisely gets what you need in most scenarios and offers it in firebase. If you find that you need more cloud solutions that are not included in firebase just get them from Google Cloud as these two are connected, it's simple as that.

On top of that it's totally free for big quota actions and doesn't need an attached credit card. In the last section of this post I cover how to get a premium plan for 0$ and be on the safe side with your budget if you plan to heavily use firebase.

What does firebase have to offer app developers?

• Authentication system
• NoSQL database
• Storage
• Hosting
• Cloud functions
• Machine learning models

Additionally you can utilize robust Analytics and Performance tests. If you develop a mobile app there are even more options you can use like tracking issues, distributing your software, implementing ads and many more.

The last thing worth mentioning is a growing section of extensions that works seamlessly with different parts of firebase. One of them is Email Trigger which enables your app sending emails using serverless architecture.

How can web apps benefit from using firebase?

• Reduce all hardware cost even to 0 and still have a powerful web app. For example A cloud guru is mainly deployed in the cloud and pays nothing for most of their architecture
• Gain a solid security of your database and bulletproof access to the app
• Build APIs and deploy them in minutes
• Host your static files in one of the biggest CDN
• Utilize modern backend framework like Express.js in the cloud

When to avoid Firebase?

Can't imagine a web app where all firebase components just won't work out. But there are scenarios when you should avoid specific functionalities.

• When database performance is the key factor. Firestore will never match a database deployed on your own server
• Avoid functions if you have complex, resource heavy computations to execute
• If you need a real ACID as there is only a simple NoSQL database
• You perform advanced database queries (there are no such)

Setting up a firebase project

The beauty of Firebase is the way it can be integrated into your project. It really doesn't matter what kind of application you develop and what parts of it you want to delegate to the cloud. It will work out in monolith, microservices, server, serverless, static, SSR and mobile apps as well. But before you start your integration you have to set up your first project in the firebase panel.

Requirements

• Google account
• any website or web app to work on (can be local hosted)

There are three simple steps which help you get through, enabling Google Analytics is optional and you can add it later.

Frontend vs backend implementation

After creating a project you can follow the basic implementation for the web. It boils down to registering your app name and adding SDK as a JavaScript library in your frontend.

Default implementation

This kind of integration is a good starting point if you just want to try out firebase but there are plenty of other possibilities as to how you can add it to your project. A better idea for modern web apps utilizing WebPack, Rollup or any other bundler is to go for firebase node modules which will work out not only in Vue, Angular or React projects. 

Is firebase frontend integration secure?

It depends. Using a frontend implementation you are exposing your API keys and other vital config like database address, project id and so on. A big misconception is belief that it can harm your security because anyone can intercept and read this data as they are inserted in js files. It's true that it can be easily done. But the idea of passing these credentials is meant for configuring your frontend package for easier use and analytics identification and they really shouldn't be considered as secret. The whole bunch of these keys is not enough to make any interaction with your firebase. So initially your app is secure.

But when you start using specific components like databases or storage you will encounter the necessity to manage access to them (by default they are blocked for outer use.) And this is a time when your security evaporates in a second. For example giving writing access for all unauthenticated users to your firestore database with exposed database address on the frontend can lead to disaster.

To sum up the app, frontend implementation with exposed API keys is secure but if it lasts depends on your access granting policy.

Do I need backend integration?

To use the full potential of firebase you should refer to the backend. This unnecessarily means that you need your own server. Practically anything for the web apps can be delegated to the firebase functions that work in serverless architecture (more on that in the next paragraph). If you decide to use the backend you will gain access to the firebase admin package which can do practically anything with your firebase modules. When using your own servers you will have to use an API service key which is secret and has to be secured. You can generate plenty of these keys with different roles (privileges) and use them in different parts of your backend. Notice that managing access to your components using specific keys ensures more solid security because of granular access from the backend.

What type of implementation is better?

It mostly depends on what kind of app you develop and the skills of involved people in the project. Definitely the most secure and performant will be the sole backend implementation even for sleeveless apps (firebase functions). On the other hand if your app is mainly frontend based there is no need to complicate things more than they should to be and I would stick with the frontend firebase library. For bigger projects you can also mix both types of implementation if it would help your team.

Firebase functions

A cool thing about firebase functions is that you develop them totally separately from your web app and there is no such thing as frontend or backend integration. Functions can basically work as a part or the whole of your backend though. They start their execution in a response to triggers or HTTP API calls. In order to use them I recommend firebase CLI.

Firebase hosting

You have a variety of options on how to use the firebase hosting. If you want to go fully serverless this is an ideal option because you can easily deploy your whole web app and get decent performance at no cost at all. If you use your own servers you can still pick any static assets and deploy them in the hosting, gaining some performance and unloading your own machines. Either case just initiated google hosting using firebase CLI and choosing hosting project option. This has to be done in the root of your web app.

Blaze plan - get it fo free and don't go bankrupt

By default after setting up your project you land on a free Spark plan. It has quite big quotas for all of the goodies available in Firebase and in most cases that should be enough for your app at least at the beginning. Obviously payable plans give your the possibility to operate after you use up your free tier limits for the current month but it's not the only difference so it's worth considering them earlier.

Why is it worth switching to Blaze plan?

• still has a free trier but with much higher quotas
• you can combine any external API's in functions
• whole spectrum of locations for your hosted files
• get access to all firebase extensions
• you can get all premiums from Blaze by setting up your budget to 0 (read below)

You don't wanna be a bankrupt developer

In Firebase there are no such things like budget limits and many inexperienced developers and victims of hackers attacks ended up with huge bills from Google to pay. But there is a solution. At the beginning of this article I mentioned that if you lack some functionality you can get it from the older brother - Google Cloud and this is such a case. If you switched to a premium plan go to the GC console and select a firebase project (as these two platforms are connected your project is already there). Find the billing section and then select or create a new billing account.

Finally go to the Budgets & alerts (side menu) and set your maximum amount to spend in the month span.

If you encounter problems in the billing set up I recommend Google docs related to set budgets and budgets alarms docs.