Is Firebase a good choice to build a CMS?

In my opinion, many people try to use firebase as their entire database. This is a terrible idea for a number of reasons. I’m a huge fan of firebase, however I try to use it for what it’s intended for - Realtime Data Binding

Auction data, messages, etc are great to store in firebase.

Data that needs to be queried, should be stored in a bucket, queried using Google cloud compute, and it’s result stored in firebase to be bound to the application

Yes.

Firebase is an excellent choice for CMS, having built one myself which is now running on Firebase I can confirm that Firebase has been more than satisfactory.

The real prize with Firebase is the plethora of services you can integrate using the Google Cloud Platform (GCP).

Hope this helps!

in short YES,

Firebase is document database and as such it is best used when you work with documents, in the CMS case documents = pages

Only use that it will get tricky to use is when you have very big number of collections/tables/lists (call them as you want) and each of them will have a lot of data in them, like 10k and up rows/items/lines. And in that situation will get complicated only if you want to have reports generated based on complicated relationships between this collections/tables/lists.

You need to consider the data structure before you doing your project - the free tier is good chun

in short YES,

Firebase is document database and as such it is best used when you work with documents, in the CMS case documents = pages

Only use that it will get tricky to use is when you have very big number of collections/tables/lists (call them as you want) and each of them will have a lot of data in them, like 10k and up rows/items/lines. And in that situation will get complicated only if you want to have reports generated based on complicated relationships between this collections/tables/lists.

You need to consider the data structure before you doing your project - the free tier is good chunk of usage and is relevantly cheep if you end up having thousands of users but you need to be aware of the costs bad design can cost you actual money so put some usage notifications and limits from the start.

if you intend to move data around (restructure, reorganize, export and import) and often you may be better off looking for something else (MS SQL/Oracle/ Postgres) - will get expensive doing it in Firebase (unless google decide to implement some of that functionality in their admin panel)

In short NO

Firebase is a good option but if you want to create a CMS and use it real-world application then consider these below points before starting.

1.Ease of use

Yes, firebase is easy to use no doubt in that. But when using it in a real application than you will face many complications. For Example:

Limited option is available for Firebase. Like if you want to add a search query in the firebase then hard luck doing that as there is no direct way of don't that.

2. Cost
Firebase is lucrative when starting out with its free tier but as your users grow your bill will grow exponentially.

3. You wi

In short NO

Firebase is a good option but if you want to create a CMS and use it real-world application then consider these below points before starting.

1.Ease of use

Yes, firebase is easy to use no doubt in that. But when using it in a real application than you will face many complications. For Example:

Limited option is available for Firebase. Like if you want to add a search query in the firebase then hard luck doing that as there is no direct way of don't that.

2. Cost
Firebase is lucrative when starting out with its free tier but as your users grow your bill will grow exponentially.

3. You will get stuck

It is impossible to switch your firebase backend if need be. Like if you are on a SQL database you can easily switch to any other variant and service providers when you need it. But with firebase, you will get stuck with it.

So in my opinion, if you are making a data-driven app like blogs or tutorials or anything like that then look somewhere else. But if database is a secondary functionality of your software like a photo editor or similar app then you can use firebase.

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution see

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution seems to be to have a second project to use as a development/staging environment. Of course, if you want to have a few development environments plus a staging one before you roll out to production it starts to get messy. Being able to replicate your production environment using docker containers does make life and collaboration easier and you can’t do something like this with Firebase.

Nonetheless, I would not recommend just setting up your own backend and having to do software patches etc as some people imply is the alternative. The alternatives include using more scalable databases such as BigTable or ScyllaDB which can be used as a turnkey solution and then using things such as Cloud Functions, App Engine or Docker containers along with Kubernetes for your backend services. Just make sure that you encapsulate and abstract calls to your queues and databases so that you are not tied up in any one technology.

Of course, there are also very good reasons to use Firebase:

  • Authentication: Firebase takes care of your authentication allowing for different authentication methods that work on all devices. This makes life a lot easier.
  • On(change, add, delete etc.) Events: Realtime database is just amazing for frontend updates. You subscribe to data changes and the moment something changes in the database, your frontend updates instantly.
  • Cost: Especially in the beginning, it costs next to nothing to get started. As your app scales you start to feel the cost but in order to have a system that offers what Firebase offers you will be paying in any case so it is good to be able to start with very low fixed monthly costs and paying based on usage.
  • Speed of Development: Firebase allows you to launch your MVP in no time. It is not the best for large teams and complex projects but for MVPs it is just fantastic.

It totally depends and in most cases you don’t even need to pick one or the other. Firebase is really flexible and can be tacked onto just about any app with a little javascript, or used as a stand-alone solution.

For a simple application where you’re serving static web assets (HTML and JS) and just need an easy way to store and access data and certain other assets (JSON, Images, etc…) Firebase is all you need. No point in wasting valuable dev time implementing your own solution.

If you need some custom back end logic, you can use node.js for that. While you cannot host a node app on Firebase, t

It totally depends and in most cases you don’t even need to pick one or the other. Firebase is really flexible and can be tacked onto just about any app with a little javascript, or used as a stand-alone solution.

For a simple application where you’re serving static web assets (HTML and JS) and just need an easy way to store and access data and certain other assets (JSON, Images, etc…) Firebase is all you need. No point in wasting valuable dev time implementing your own solution.

If you need some custom back end logic, you can use node.js for that. While you cannot host a node app on Firebase, there are countless cheap/free and easy ways to host a node app on the web (like Heroku).

As long as the other requirements are still met by Firebase you won’t need much node code and you’ll have a few options for implementation.

You can host your site entirely on a service like Heroku and then tap Firebase strictly as a data source, or you can host your app on Firebase and create a listener service in Node (hosted separately on something like Heroku) that will react to changes in your Firebase data in real time, performing external operations or further manipulating the Firebase data. You can also make API calls to that node app from your Firebase-hosted SPA. This is a nice, modular, loosely-coupled architecture that makes it pretty easy to swap out any one part for different technology. You could even put the Node API on one server, and the Firebase-reactor Node app on another server, and keep everything totally decoupled. You could even tack on a SQL based back-end without giving up any of that.

The only really solid reason for opting out of Firebase entirely and doing your own thing in Node is if the data architecture and security rules in Firebase don’t meet your needs. Say you’re working with corporate legacy applications that don’t play nice with Firebase, or your data is already out there in another tool, or you simply need the power of SQL for complex queries and data sorting, then you might not want to mess with Firebase at all UNLESS you have specific needs for the real-time database nature of Firebase. You can still tack on some Firebase functionality even if the rest of your architecture is based on SQL and other stuff. Say for instance you want to implement a simple messaging service inside your app… You can just use Firebase for that without interfering with your other stuff since it’s all just front-end code.

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perf

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perfect solution? It’s supported by google. It’s super super easy to use. It’s well documented. Any more questions?

You can build whatever app (prototype) with Firebase in no time. It might not scale, but this is not what’s it about. You just want to master front-end stuff, don’t you? Right.

Eventually your MVP might get traction. What are you going to do? Well, if it’s going to get “a lot” of traction, you can pay someone to build a scalable backend for you. If not, scalability will never be an issue. You just don’t have to care about it!

Build whatever you like. Focus on the things you love to do. Firebase let’s you do exactly this. Keep it going, cheers.

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser,

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser, back-office, and mobile consumer can update a data simultaneously without the problem of synchronization. As soon as data is updated, added, inserted, or deleted all update are automatically pushed to the client via API.
  2. Speed of Development - Google Firebase Database is NoSQL database with out of the box API connectors and wrappers for query purposes. As a result, rather than building REST API just like the traditional way of connecting thin client to database, with Firebase, a company can simply use their SDK to do the same purpose. As a result, business would be able to cut their development time by removing the API development component. Less scope, means less development cost as well.
  3. Realtime update - The old ways of doing things is that a client connected to database need batch update to get new sets of data. It is an inefficient architecture, imagine a program has to read 1 million records every fifteen (15) minutes with or without update. With Google Firebase Database, a client can be automatically triggered for refresh via Callback as soon as an update is made in the database. With thus technology, developers are assured to only get a new sets of data as needed basis. Here is the actual demo of realtime database update (See video below). As soon as data is changed in database, the LED’s state connected to Raspberry devices instantaneously changes status.
  4. Free- Developers and business owners can create two projects in Firebase for free. This means organization need not to buy premium license during R&D stage. It gives developers and decision makers enough time to learn and evaluate the technology.
  5. Authentication - It comes with a builtin authentication module. Supports gmail, Facebook, Twitter, and basic username and password login support. Integrating this module in your app is easy through their SDK.
  6. Rich API Document - The Firebase SDK is well documented and has lots of example over the web. On our case, we were able to try the SDK for NodeJS. Other Platform supported are IOS, Android, Java, and JS.

As for the Disadvantage

  1. No Data Explorer - This issue is more for developers. The Firebase Database does not provide an online tool to allow developers search for a data inside a node. It has a manual tree like data explorer but becomes complicated or difficult to traverse as dataset goes bigger.
  2. No built-in Authorization - One of Firebase strong point is it’s authentication module. However; it could had been better if it is shipped with a pre-created framework for authorization. To date, developers has to secure data and forms by manually coding the roles for a specific users.

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds. Provide collaborative and immersive experiences without thinking about networking code.

  • Offline

Firebase apps remain responsive even when offline because the Firebase Realtime Database SDK persists your data to disk. Once connectivity is reestablished, the client device receives any changes it missed, synchronizing it with the current server state.

  • Accessible from Client Devices

The Firebase Realtime Database can be accessed directly from a mobile device or web browser; there’s no need for an application server. Security and data validation are available through the Firebase Realtime Database Security Rules, expression-based rules that are executed when data is read or written.

  • Scale across multiple databases

With Firebase Realtime Database on the Blaze pricing plan, you can support your app's data needs at scale by splitting your data across multiple database instances in the same Firebase project. Streamline authentication with Firebase Authentication on your project and authenticate users across your database instances. Control access to the data in each database with custom Firebase Realtime Database Rules for each database instance.

Real World Usage

I've personally used Firebase in number of applications and it is very fluid in its working. It is highly efficient if you want a real-time database that is synced across every client.

Other useful features of Firebase includes -

  1. Cloud Messaging (FCM)
  2. Authentication
  3. Cloud Firestore
  4. Storage
  5. Hosting
  6. Cloud Functions
  7. Crashalytics
  8. Performance Monitoring
  9. Test Lab
  10. Crash Reporting
  11. Predictions
  12. Remote Config
  13. Dynamic Links
  14. App Indexing
  15. AdWords
  16. AdMob

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for co

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for complex stuff is simply not a viable option.

If you’re making something cool that just needs a fast, reliable database, user authentication and usage tracking, then Firebase is a great way to go. If you’re building something that has complex back-end business rules then you’re going to run into difficulties.

You can totally combine it with a custom application of course, store your data in Firebase and have a middleware layer that does the business logic, but for most business cases this isn’t really a good compromise.

I’ve used Firebase in production with a small MVP and for lots of smaller side projects. Here is a quick and dirty list of the good/bad:

Good

  1. Easy to get started with great API docs and rock solid SDKs
  2. 3-way data binding if you use AngularFire
  3. Addition of Google Cloud services (file storage, notifications, analytics) makes those things easier as well.
  4. Very fast client-side (if you can avoid downloading excess data)
  5. Dead simple auth module that makes me less nervous about a hack b/c Google
  6. Support for a server side SDK allows you to still use the data to render pages on the server
  7. I don’t have to worry

I’ve used Firebase in production with a small MVP and for lots of smaller side projects. Here is a quick and dirty list of the good/bad:

Good

  1. Easy to get started with great API docs and rock solid SDKs
  2. 3-way data binding if you use AngularFire
  3. Addition of Google Cloud services (file storage, notifications, analytics) makes those things easier as well.
  4. Very fast client-side (if you can avoid downloading excess data)
  5. Dead simple auth module that makes me less nervous about a hack b/c Google
  6. Support for a server side SDK allows you to still use the data to render pages on the server
  7. I don’t have to worry about managing a DB, DB server, or backups!

Bad

  1. There is a serious lack of query power with the SDK. If you are doing any kind of data analytics, stick with SQL
  2. Lack of control over user emails/passwords (this could also be a good thing as well)
  3. In some ways, harder to structure modular code. A lot of the Firebase stuff ends up becoming spaghetti code wrapped in a method. It works, but it is not as elegant as it could be with a REST Api.

Overall, I’ve had good experiences with Firebase and would use it again to bootstrap a product. I’ll update this post when my current project grows so large that I have to migrate off of Firebase, and then we’ll see how easy that is : )