Could I use a cloud database like Firebase instead of making my own backend?

Yes you could, and almost certainly should, use a cloud database like the Realtime Database or Cloud Firestore instead of building your own database from scratch.

However, you’ll need somewhere to put the logic for accessing this data. You could:

  1. Use Firebase cloud functions. I have no experience using these, but have seen them around in the docs.
  2. Set up a web server or Kubernetes cluster that receives HTTP requests, performs CRUD (create, read, update and delete) operations on the database and sends a corresponding response to the client.
  3. Embed the logic for CRUD operations in your client applica

Yes you could, and almost certainly should, use a cloud database like the Realtime Database or Cloud Firestore instead of building your own database from scratch.

However, you’ll need somewhere to put the logic for accessing this data. You could:

  1. Use Firebase cloud functions. I have no experience using these, but have seen them around in the docs.
  2. Set up a web server or Kubernetes cluster that receives HTTP requests, performs CRUD (create, read, update and delete) operations on the database and sends a corresponding response to the client.
  3. Embed the logic for CRUD operations in your client application. It seems like Firebase almost wants users to do this, but it has risks and might not be the most efficient route either.

Firebase databases offer great realtime functionality, other databases like Amazon RDS are good for other things. You might even want to use multiple databases for separate things. Instacart uses both of the above. Choose the right way of accessing whatever database you land on for your use case.

Well sure you could use a cloud based database. But you’d still need some sort of a backend… A program would need to run somewhere to control access to the database for storing and retrieving the data.

Your specific application architecture would determine the needs, a Linux instance running MySQL and a webserver would be one possibility. But you could also use a AWS system using S3 served webpages, RDS database and Lambda for providing an API to the data.

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.

Interesting question!

So let me ask you a question: why would you use a real time database of you weren't planning to make use of the advantages sockets were going to give you?

Using the functions to fetch records eliminates the advantage of the instant data updates.

Remember that NoSQL databases have very low cost and ultra fast read operations. They're bad at assembling data relationships and their write operations are slower than their SQL counterparts. However, if you're smart with indexing you can make some relationships easier to find.

If you need real time updates to the front end as your r

Interesting question!

So let me ask you a question: why would you use a real time database of you weren't planning to make use of the advantages sockets were going to give you?

Using the functions to fetch records eliminates the advantage of the instant data updates.

Remember that NoSQL databases have very low cost and ultra fast read operations. They're bad at assembling data relationships and their write operations are slower than their SQL counterparts. However, if you're smart with indexing you can make some relationships easier to find.

If you need real time updates to the front end as your records change or fast read operations for a high volume read application, firebase is exactly what you want.

The only possible reason I can imagine to use cloud functions is is if you want to gather record sets for analytical reasons later.

However, I'd suggest firing up an SQL database with a cloud function that runs a pivot query to normalize your data. Then pull your analytics from the SQL database if you think that the analytics portion is going to be / grow into any significant — size / complexity wise — feature of the app.

I'm aware the above sounds a bit overkill, but keep in mind that NoSQL permits rapid iterations on the Dev side without needing your DBA, a business case, a butt load of approvals, and finally a change ticket. Separating the concerns in this way makes your app agile while still managing the slow methodical changes in your analytics as an independent set of features that can be cut in when the table structures have changed.

I hope this helps. Happy coding.

In a general sense, Firebase Realtime Database can be used while offline. However, the expectation is that the app is supposed to be connected most of the time, and changes to the database that happen while offline will be synchronized when it has connectivity. 100% offline use is not really a supported use case, because the canonical data store is on the server.

The local copy of the database is limited to (10MB, at least on Android this is the case). If you intend to write to the database beyond this limit while offline, it will evict part of your cached data to make room for whatever you’re

In a general sense, Firebase Realtime Database can be used while offline. However, the expectation is that the app is supposed to be connected most of the time, and changes to the database that happen while offline will be synchronized when it has connectivity. 100% offline use is not really a supported use case, because the canonical data store is on the server.

The local copy of the database is limited to (10MB, at least on Android this is the case). If you intend to write to the database beyond this limit while offline, it will evict part of your cached data to make room for whatever you’re adding. Then, you will no longer be able to read those evicted values until the app goes back online. Worse, managing a growing list of writes to apply when back online is taxing on the app, so you don’t want to plan a lot of writes while offline.

Also, if you have permissions or validations defined for your database, these can only be checked on the server. So, if you’re doing offline writing to your local cache and you no longer have an active listener, you may never know if those writes fail.

Because of these caveats, it’s better not to think of Firebase Realtime Database as an “offline” database. It’s better to think of it as a “synchronized” database that actively syncs to the server while connectivity is present.

I’ve been using Firebase for 6–8 months. The features which firebase provides are simply superb. I believe Google provides more and more updates for it.

In 2018 I/O event Google introduced #ML kit which provides image recognition and face recognition, you just need to create an account and attach your app to the firebase and it’s API’s.

Coming to the point, Firebase realtime database is widely used but I recommend you to use FireStore instead of Firebase realtime database as it provides many features compared to firebase.

*One of the major improvement is in queries field. Writing queries in fireb

I’ve been using Firebase for 6–8 months. The features which firebase provides are simply superb. I believe Google provides more and more updates for it.

In 2018 I/O event Google introduced #ML kit which provides image recognition and face recognition, you just need to create an account and attach your app to the firebase and it’s API’s.

Coming to the point, Firebase realtime database is widely used but I recommend you to use FireStore instead of Firebase realtime database as it provides many features compared to firebase.

*One of the major improvement is in queries field. Writing queries in firebase is difficult, but it is easy in firestore. You can directly sort the data in the website itself.

*Firestore is not as pricey as firebase.

*Unlike Firebase, Firestore has Collections,Documents for better understanding and queries.

*But one thing which frustrates me is methods to access them, don’t get me wrong the documentation(Add Firebase to Your Android Project | Firebase) provided is crystal clear and live projects in GitHub( firebase/FirebaseUI-Android) are clear, but these methods keep on changing for every update and irony is the old methods do not work sometimes :(.

Angular js, typescript.

For my little time in software development ,I've also realised that other server languages such as php can be given the power to perform No-SQL transactions . This is possible by using decoding and encoding functions .

For example ,JSON file can be fetched into an array and converted to sql compatible data where else in the other side ,mysql structure can be decoded and stored as a JSON file.

Encoding functuins lets you fetch data in a format you desire.

The code below illustrates an API that fetches data from a http JSON format decodes it and encodes it .

  1. data: {
  2. authenticat

Angular js, typescript.

For my little time in software development ,I've also realised that other server languages such as php can be given the power to perform No-SQL transactions . This is possible by using decoding and encoding functions .

For example ,JSON file can be fetched into an array and converted to sql compatible data where else in the other side ,mysql structure can be decoded and stored as a JSON file.

Encoding functuins lets you fetch data in a format you desire.

The code below illustrates an API that fetches data from a http JSON format decodes it and encodes it .

  1. data: {
  2. authenticate: true
  3. }
  4. })
  5. page-inscriptionnewsletter.php
  6. <?php /* Template Name: Inscription newsletter mobile */ ?> <?php get_template_part('templates/header'); ?>
  7. <?php if (have_posts()) : ?>
  8. <?php while (have_posts()) : the_post(); ?>
  9. <h1 class="title-post"><?php the_title(); ?></h1>
  10. <?php the_breadcrumb(); ?>
  11. <div class="content-post">
  12. <?php
  13. $data = json_decode(file_get_contents("php://input"));
  14. $email = mysql_real_escape_string($data->email);
  15. $qry = 'INSERT INTO lcdjwp_newsletter (email) values ("'.$email.'")';
  16. $qry_res = mysql_query($qry);
  17. if ($qry_res) {
  18. $arr = array('msg' => "Email Created Successfully!!!", 'error' => '');
  19. $jsn = json_encode($arr);
  20. print_r($jsn);
  21. } else {
  22. $arr = array('msg' => "", 'error' => 'Error In inserting');
  23. $jsn = json_encode($arr);
  24. print_r($jsn);
  25. }
  26. ?>

Regards.

You should define what you intend to do with them, first.

Based on the stage of your product development, size of your user base, quality requirements, and design intention, each product would fill a need that’s going to either help with your goals or not.

Firebase is great for early stage development and getting your product off the ground fast.

Google Cloud Platform/Azure and AWS are supermarkets of your infrastructure needs. Unless you know the landscape of these tools, they’re overwhelming and not helpful. But in the hands of an expert, they are incredibly useful.

Unless you defined what your

You should define what you intend to do with them, first.

Based on the stage of your product development, size of your user base, quality requirements, and design intention, each product would fill a need that’s going to either help with your goals or not.

Firebase is great for early stage development and getting your product off the ground fast.

Google Cloud Platform/Azure and AWS are supermarkets of your infrastructure needs. Unless you know the landscape of these tools, they’re overwhelming and not helpful. But in the hands of an expert, they are incredibly useful.

Unless you defined what your needs were, all of them are going to be probably good or bad for you, but the certainty with which anyone could answer that questions is going to be rather low.

Pro’s:

1. If your app does run of a centralized DB, and is updated by a lot of

users – then it’s more than capable of handling the Real-Time data

updates between devices.

2. Stored in the cloud so readily available everywhere.

3. Cross Platform API (If you are using this DB with an App)

4. They Host the data. -Meaning if you are storing a lot of data, you don’t have to worry about hardware!

Con’s:

1. Unless your app runs of one centralized database updated by a vast quantity of users, it’s a major overkill.

2. Storage format is entirely different to that of SQL, (Firebase uses JSON) so you wouldn’t be

Pro’s:

1. If your app does run of a centralized DB, and is updated by a lot of

users – then it’s more than capable of handling the Real-Time data

updates between devices.

2. Stored in the cloud so readily available everywhere.

3. Cross Platform API (If you are using this DB with an App)

4. They Host the data. -Meaning if you are storing a lot of data, you don’t have to worry about hardware!

Con’s:

1. Unless your app runs of one centralized database updated by a vast quantity of users, it’s a major overkill.

2. Storage format is entirely different to that of SQL, (Firebase uses JSON) so you wouldn’t be able to migrate that easily.

3. Reporting tools won’t be anywhere near the ones of standard SQL.

4. Costs! -Limited to 50 Connections and 100mb of Storage!

5. You don’t host the data, Firebase does. And depending on which server you get put on, viewing there up time there seems to be a lot of disruption lately.

Read more at: What are the advantages and disadvantages of Firebase for a database? - FAQs System

MongoDB vs Firebase. When comparing MongoDB and Firebase, it is important to consider all the factors related to Document database. For an entrepreneur, choosing a technology stack can be a difficult thing. It is necessary to consider the front-end and back-end requirements of your App development. Especially, keen attention should be given to the database, as all the important data, details and documents are stored in it.

Every database provides features and solutions to different problems and needs. You just need to understand the requirements of your application development to choose the per

MongoDB vs Firebase. When comparing MongoDB and Firebase, it is important to consider all the factors related to Document database. For an entrepreneur, choosing a technology stack can be a difficult thing. It is necessary to consider the front-end and back-end requirements of your App development. Especially, keen attention should be given to the database, as all the important data, details and documents are stored in it.

Every database provides features and solutions to different problems and needs. You just need to understand the requirements of your application development to choose the perfect fit. Here are few things to consider when choosing a database for web or app development. First of all, make sure that all the basic requirements of the database are satisfied. Then, list the requirements of your app development and check if that is justified. And compare tools before finalizing one. Here is such a comparison between MongoDB and Firebase.

Read the full article here: MongoDB vs Firebase. Which is Better For Your Business

The answer really depends on the type of project you will develop and your long term goals. Here is what I like regarding each platform:

Back4app

  • It’s a database like interface
  • Works with GraphQL and REST APIs
  • It’s open-source and there is no vendor lock-in
  • Easy of use and low learning curve
  • Several hosting options (AWS, Google Cloud, Azure, etc)
  • More flexible support

Firebase

  • It may be the ideal choice for Realtime database projects
  • ML feature
  • Has a broader range of features
  • It’s owned by Google