I have been asked to develop an app with backend similar to Firebase by Google real time database and auth. Do you know any Firebae alternative?

I wouldnt really trust anythjng like firebase other than firebase. Unless I rolled my own.

I would even understand if people were hesitant to use firebase.

Parse had big budget backing with facebook but it was killed rather suddenly. There was a real time db called rethinkDB. That is open source but no longer being actively maintained by the original team.

Fortunately you can roll your own real time db using existing tech. Mongodb + mongoose and websockets can help you with that. For auth just use passport and you are half way there. You wont have serious storage. And some things eould obviously

I wouldnt really trust anythjng like firebase other than firebase. Unless I rolled my own.

I would even understand if people were hesitant to use firebase.

Parse had big budget backing with facebook but it was killed rather suddenly. There was a real time db called rethinkDB. That is open source but no longer being actively maintained by the original team.

Fortunately you can roll your own real time db using existing tech. Mongodb + mongoose and websockets can help you with that. For auth just use passport and you are half way there. You wont have serious storage. And some things eould obviously be missing. But you can do real time db with auth in a few days if you tried.

Here are a couple I know about:

  • Appbase - interface is Elasticsearch-compatible
  • Graphcool - interface is GraphQL-compatible

If you don’t mind hosting yourself, the open source Parse server apparently has realtime updates these days. There’s also GUN.

And if you need more control than any of the realtime BaaS/database systems offer, you can always just use a realtime push provider (e.g. Fanout or Pusher) as a building block along with any backend system.

Even tough Firebase is a feature-rich program and prominent platform, a closed-source framework has disadvantages to open-source players. Here is a list of alternatives to Firebase.

Parse, Back4App, Kuzzle, AWS Amplify, Hoodie

To know more about open source choices to Firebase please read the blog below:

Firebase Open Source | back4app blog

Firebase Alternatives – Top 10 Competitors | back4app blog

EDIT: Have times changed in a year and a half! We recommend that most customers looking for a BaaS install Parse Server on our cloud. We still support our BaaS for existing customers, but being able to deploy Parse on our HIPAA-compliant, HITRUST-certified stack provides better flexibility for customers looking for that type of solution.

Thanks!

———————

Hi, I was A2A, and I also work for Catalyze.

We often get questions about Firebase/Parse often when asking about our services. We have two products at Catalyze, a Backend-as-a-Service (BaaS) which is like Parse and a Platform-as-a-Service (PaaS) wh

EDIT: Have times changed in a year and a half! We recommend that most customers looking for a BaaS install Parse Server on our cloud. We still support our BaaS for existing customers, but being able to deploy Parse on our HIPAA-compliant, HITRUST-certified stack provides better flexibility for customers looking for that type of solution.

Thanks!

———————

Hi, I was A2A, and I also work for Catalyze.

We often get questions about Firebase/Parse often when asking about our services. We have two products at Catalyze, a Backend-as-a-Service (BaaS) which is like Parse and a Platform-as-a-Service (PaaS) which is like Heroku.

You shouldn't store PHI in Firebase. I don't think they'll sign a Business Associates Agreement with you, so that means that you would hold all liability in the event of a data breach of their service. But, if you had a clean segregation of PHI and non-PHI in your data models, you could absolutely store non-PHI in Firebase and PHI in Catalyze products.

Likewise, you could use Catalyze products to effectively replace Firebase. Some of our customers use our Backend-as-a-Service to build and store their application's data models and to manage user provisioning. They then use a PaaS container running a light engine using node or python scripts to manage real-time processing of data like claims or HL7 admissions feeds or to handle sending push notifications based upon that data processing. Since we offer both of these products, there's a pretty tight coupling between these two services.

I know that's not quite as good as Firebase when it comes to real-time data management, but there are some security concerns with multi-device data synchronization and running arbitrary code (like Parse's Cloud Code) in a HIPAA-compliant manner that we want to make sure that we have totally right before we offer those services. As a bunch of programmers building tools for programmers and Digital Health geeks, we're excited to keep working on tools that make it easier to build applications for healthcare and we're releasing new functionality and tools to make that easier every day. We'd love to hear what you're working on! Don't hesitate to shoot me an email or DM me here on Quora -> mark <at> catalyze dot io.

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.

If you're building an app that requires multiple users to communicate with each other or access a shared pool of data, back-ends are pretty crucial. Since you were using Wampserver I'll assume you have a MySQL database, and you're running PHP. There's nothing conceptually wrong with the way your system is implemented right now, I wouldn't know the details, and you can scale fairly easily because pretty much every web host supports MySQL and PHP. So a simple option would be to buy some server space and host your database there.

However, you have a few other options, and yeah, Parse and Firebase

If you're building an app that requires multiple users to communicate with each other or access a shared pool of data, back-ends are pretty crucial. Since you were using Wampserver I'll assume you have a MySQL database, and you're running PHP. There's nothing conceptually wrong with the way your system is implemented right now, I wouldn't know the details, and you can scale fairly easily because pretty much every web host supports MySQL and PHP. So a simple option would be to buy some server space and host your database there.

However, you have a few other options, and yeah, Parse and Firebase are among the best. I'll also add another service I've extensively used called App42. All these services are called Backend-as-a-Service (BaaS). Their primary objective is to eliminate the need for you to host your own back-ends, and most of them provide value added features, that way, all you have to worry about is Android, you don't need to know how to build and scale databases, all you create is the server-side logic, and you can argue that it makes you more productive since you don't have to build from scratch.

One great thing about using a BaaS is that if you make an Android app that uses data from the BaaS, you can just as easily make an iOS app or a web app that uses that same data.

So where do you start? Well I believe you can build anything you want to on any of the three, for both mobile and web. Firebase is the fastest, but it doesn't really give you more than a place to store and retrieve your data in real time. App42 is the most robust and has the most value addition, meaning you can easily implement a ton of features without having to write the code yourself, but it's not as fast as Firebase, and relatively falls short when it comes to offline caching and a few other tiny things. Parse doesn't really have that many flaws either. They're all awesome and free to begin with.

All this is nit-picking really and you should check them out and decide for yourself what's best for you. Hope this helps.

EDIT: Ignore the others and just start with Firebase. It's really powerful and robust now.

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 :(.

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

Which kind of app you are talking about?

Firebase Database is really great for real-time apps as the database itself is real-time. We can store data in json format in the form of keys and values. We can easily design nested databases using child. The storing and retrieving process is also very simple and handy. We just need to set a database reference and then can easily get or set value at that place.

I have used Firebase Realtime Database recently in my college project where I had to make a e banking app (net banking app) having features like Balance Inquiry, Fund Transfer, Mini Statement whic

Which kind of app you are talking about?

Firebase Database is really great for real-time apps as the database itself is real-time. We can store data in json format in the form of keys and values. We can easily design nested databases using child. The storing and retrieving process is also very simple and handy. We just need to set a database reference and then can easily get or set value at that place.

I have used Firebase Realtime Database recently in my college project where I had to make a e banking app (net banking app) having features like Balance Inquiry, Fund Transfer, Mini Statement which must work in real time. The integration and implementation are quite easy and I must recommend this to everyone who want to use a Online Database but doesn’t wan’t to get into too much SQL and PHP.

Depends on your needs. Firebase has some awesome features, like FCM and Crashlytics. However, in terms of a database, I would say it’s good for smaller projects, MVP’s or just starting out. Any real time project will probably want to use something more dynamic and customizable like Redis or some tools in AWS.

However, I would say Firebase is a great place to start and has some awesome queries (although once you get into them, they’re very limited without extra functions added).

If you don’t have access to any source code or any sort of data on the backend, there really is no way to tell. One giveaway might be that it is “realtime” but a ton of apps feature realtime data without using Firebase, so that is more of a “best guess” situation.

You could always just email the team that runs the app and ask, worst thing that can happen is they will say no!

Here are some open source alternatives to Firebase:

  1. Back4App
  2. Parse
  3. Kuzzle
  4. AWS Amplify
  5. Cloudboost

For more information, please read the article below:

Firebase Open Source