Your data sits on a server where every read and write must first pass through a gatekeeper service that looks at the rules you’ve written and matches/validates that read or write against them first before allowing it. So it’s trivial to secure data against unauthorized users and it’s also trivial to secure it against even yourself from deleting it, if you desire to do so.
But! It is not secure unless you write these rules! This is very important to understand when working with Firebase.
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.
AWS is extremely secure. Their compliance with a wide range of domestic and international security standards is certified by independent auditors on a regular basis.
Compliance Programs - Amazon Web Services (AWS)
Customers hosting applications at AWS share responsibility for security and privacy at AWS. For example, AWS ensures that unauthorized entities and persons will not access data stored at AWS by their customers, however their customers have the ability to authorize any entities and persons they choose to access data and to limit the data to which they have access. Furthermore, AWS customers are responsible for building their applications and associated infrastructure to be secure and resistant to being compromised by malicious actors via exploits such as SQL injection, AWS provides myriad services, documentation, and white papers to assist application developers in making secure, cloud-hosted applications
Bottom line, AWS is very secure (enough to be used by NASDAQ, DoD, & financial institutions). However the security and privacy of your data stored at AWS is only as secure and private as the policies of the application provider with whom you entrust your data and how thoroughly they adhere to AWS best practices.
I am currently working as a firebase security consultant. When firebase first started being used, I hacked apart just about every implementation I found, giving myself top scores in the games, even coding fun ways of messing with people in their real time interaction apps.
It is not trivial to secure a firebase app after it has been developed, unless it is a very simple app; however developing from the ground up with security in mind, you can indeed develop a secure service without too much headache.
Depending on what you need to accomplish, you may or may not need an actual server to proxy certain requests through.
In my current case I am working on an app that even connects to amazon web services for uploading pictures directly so it never has to touch our servers... firebase is great for implementing third parties authentication gateways so that you can use firebase user auth, or if you must a custom firebase auth in order to secure your app.
It is definitely possible to develop a secure service on top of firebase and I prefer to use firebase for any app requiring realtime interaction.
When you want to be vendor independent. And if you plan your app to last more then 5 years. If your app will be used to store some data for years and some business will rely on you than you should not use firebase, why? Look what happebed to Parse, google have a long list of closed projects and nobody can say for how long firebase will last. You shold consider what is better: invest now in independent solution, or invest later to move all the apps related to your new backend and backend itself to another platform. If your solution is “made fast, fast forgotten”, or safety of the data not really a big matter for your users then firebase is very good solution.
I don’t know if they will be watching it, but seeing as how they own the servers + databases they DO have the access.
But I guess worrying about that is like your users worrying about you watching their data since you are the developer of the app.
No, your data is not shared with anyone. Google has to support Android community and while Firebase Cloud Message supports both iOS and Android, I am sure Google has Android developers in mind when creating Firebase Cloud Message.
Absolultely. You should go with Firebase! Unless Firebase does not meet your project's requirements...