OP's problems seem to largely stem from not understanding how to properly use firebase. Virtually all of the "problems" they ran into are covered in the docs and could've been avoided.
While I'm sure that Firebase offers a solution to every problem mentioned. I think the real issue here is that by the time you figure out all the little details of how to customize Firebase to work exactly how you want it, you could just have easily have achieved the same result by just using plain Socket.io or a similar library - And the solution would be simpler, cheaper and more maintainable. I think that's the essence of what the author is saying.
The author did not mention this, but I've also heard a complaint that while Firebase's automatic conflict resolution is good for some use cases, that it's not all cases and that often you need to do the conflict resolution yourself.
Firebase does offer a solution for that, but again, I'm not convinced that this solution simplifies things when you consider the big picture - Conflict resolution is still going to be difficult regardless of whether you use Firebase or not.
Firebase solves the basic use case very well but then the work of customizing/fine-tuning it to make it behave exactly the way you want is just as hard, if not harder than just doing everything from scratch without Firebase.
I think Firebase is good for MVPs and it's also good for some types of simple apps, but I've seen several large apps using it and they ended up having to manage their own backend on the side anyway.
Firebase did not "free them from having to manage a backend" - With Firebase, not only do those companies still need to manage their own backends on the side; they also have to manage how Firebase interacts with that backend.
Firebase is great for a couple of use cases - not for an entire SaaS app.
Would I use Firebase as a replacement for a relational DB in a traditional SaaS app? No. However, if I had to add real time chat to an app that had no other real time components I'd probably use it.
I agree with many of the author's critiques of the platform in general, hence my suggestion at using it sparingly when you fully understand the cost benefit analysis. If used correctly (real time features that don't involve mission critical data) Firebase is a game changer.
I was playing around with Firebase a bit during the last few days.
My biggest complaint so far: they haven't made the unminified source for the JS client available! You go on npm and you get the minified source. How is that acceptable? Heck, it's completely pointless too, because if I really wanted to "steal" the source I could prettify it and clean it up. It'd take a bit of effort, but it doesn't protect or hide anything. The reason why I wanted to use firebase was so I could hack up something quick. But as I was wiring stuff up, I got confused with their docs and figured I'd take a look at the source... Only to find a minified mess.
On top of that, they're not developing the project in the open. There's no public repo, so you can't contribute. I tweeted at them earlier today; hopefully it's an oversight and they fix it.
Otherwise, it's unlikely I'll consider ever using firebase for anything, if they continue with these anti-developer practices.
FWIW the 2.x JS SDK was available unminified (see: https://cdn.firebase.com/js/client/2.4.2/firebase-debug.js). With our expansion launch at Google I/O we had to upgrade our serving infra -- along with virtually everything else -- and haven't added the capability back in to 3.x yet.
The closed source SDKs feedback is something we hear frequently. Unfortunately I can't give you anything better than 'hang tight' at the moment.
Being 'anti-developer' is the antithesis of the Firebase ethos. We strive to be as developer friendly as we can. There are areas where we're not doing a good enough job right now and we're actively working to get better.
I evaluated firebase and it convinced me to use couchdb+pouchdb. The things firebase improved were nice but not worth it and ultimately running our own DBs in European providers without external auth was less stressful for legal and estimating costs, performance, etc.
For the criticisms not related to SaaS, some of them look like familiar debates, and I'd say a drawback of using noSQL is that I have something that looks ready faster but then I need to consciously hold it back from production until I've thought through structural problems which I would have worked out first in SQL.
There's so many red flags in this article I'm not sure what I can really take away from it.
> These things may still be "hacked" using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.
So don't hack it and don't repeat it. Do it once on your server.
> You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.
So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple.
> dealing with relations with Firebase is pain in the ass.
> Want to build an API for your product? It's impossible.
WTF?
> old-fashioned SQL Database, which overs 90% of our data storage needs... For the 10% part, we decided to use MongoDB to store messages and conversations at scale.
So no ONE datastore that you could find solves your problems well, but Firebase sucks because it didn't?
Sorry, I've been building a prototype with Firebase lately and this article goes beyond unhelpful into the land of complete nonsense. If someone has run into these issues, I'd love to dig into specifics.
This seems too broad a statement to be useful. What about the memory leaks, for example? Or the lack of complex querying? Obviously one design decision was to use Firebase at all, instead of the architecture they moved to.
Can you be more specific about where you think they went wrong?
Is no one else a little alarmed by the language used on their home page? Does anyone know whether or not this is a legal privacy concern?
"Crisp discovers every tiny detail on each visitor you chat with. From geolocation to device information, to full name and social profiles (LinkedIn and more). Crisp also discovers the company of the visitor. Are my visitors aware of this feature? Your visitors cannot see that you know so much about them."
"MagicType lets you view messages as they are typed. ... Visitors are not aware of MagicType, and cannot see what you type in response. Only you can see this."
The "MagicType" feature is actually very standard in the online customer service industry. If you've ever talked with Apple customer service, they could see what you were typing as you were typing it.
This seems like 94% "why not to use nosql as your main data store", 4% "why to be wary of building your product on PaaS/DBaaS/IaaS services without analyzing the costs and limitations, and 2% "make sure to read the docs".
I'm not really seeing anything Firebase specific?
> you can't deal easily with data-migration like you can do with a simple SQL database [...] Relations are marvelous
Yeah, maybe you should have used a relational DB as the primary datastore for your relational data?
Reason #1 to use Firebase (or any other reliable BAAS): it is the next logical step of cloud computing.
If you've been around long enough, you probably had to convince the IT manager of one of your corp clients that it was a better idea to host the company's website on a hosting provider's server rather than in-house. Didn't you?
The argument of shouldn't trust your data to a BAAS provider is just silly: where's your data when you rent a VPS and mount your own back-end?
Maybe Firebase was not the right choice for this particular product, but don't trash it for it.
For me, the only missing feature is full-text search, yet the workaround is not as painful.
VPSes are a commodity: if your provider turns out to be crap or puts up prices, you can just switch to another provider. Services like Firebase are not; switching requires rewriting your application. This makes them more attractive for the company selling them but a bigger risk for their customers.
All of these sounds like surmountable engineering challenges that one should have weighed when evaluating the data layer.
"You don't own your data" is downright false -- you own it, you just don't host it. But do you ever really host it these days? Unless you're running it on your own hardware in your own facilities, probably not. So what the author should say is "migrating is expensive because we chose to build on top of a SaaS product using a proprietary API and we're surprised by this because we didn't plan any further than a single 3 week sprint".
Well of course not, although that would be wonderful.
> Your can't perform operations to get active users
Something like this would do it, right:
var refUserOnline= db.ref('/.info/connected');
refUserOnline.on('value', function(snapshot) {
if (snapshot.val()) {
var sessionRef = refUserSessions.push();
sessionRef.child('began').set(firebase.database.ServerValue.TIMESTAMP); // set UUID too
sessionRef.child('began').onDisconnect().remove();
}
});
> Paying 100$ per month for something you can do on a 5$ DigitalOcean server is something that make you thinking twice about server-less magic-less.
I pay Firebase a handful of dollars every month and they handle user auth, hosting, CDN and data. Three or four overheads I no longer need to worry about. Having used Digitalocean and Stormpath (yikes) in the past, I'm happy to have my eggs in one rather than multiple baskets.
Yeah it cost me a few hours on Stackoverflow after bumping into some of the problems you describe but the path from idea to working app is so short with Firebase - and the cognitive load typically inherent with managing multiple services, so small - that it's worth learning the 'Firebase way' of dealing with data (which is mostly just the NoSQL way).
Not to mention security, backups, upgrading all the software used, supporting new technologies as they're made avail, sdks across many platforms, etc. the $5/mo hides the true costs of development and ops
Does anyone have experience with Feathersjs as an alternative? http://feathersjs.com
It looks very similar to Firebase, but free, open source, and one advantage over others is being able to use several databases through various ORM's, so you could mix and match, for example, Postgres and DynamoDB as desired.
Must be using Node.js, though these days I think you might even be able to use Koa or Hapi in addition to default Express.
The greatest danger i see with this kind of technology is for beginners, that think nosql means you don't have to be proficient with normalization, transaction, or sql basic language structure, before you decide to go with a nosql db.
We're currently building a MVP using http://horizon.io/, which is a self-hosted Firebase alternative. Reading this makes me a bit worried that we will run in to the same problems as the author. Anyone with experience in production apps built on Horizon who has some knowledge about these concerns?
From my understanding you can setup Horizon with your custom Node.js backend. So you're in control of your data and can manage your custom business logic
Firebase engineer here. I hope you've been in touch with our support team and I'm sorry to see you've had so much trouble. You point out some genuine limitations with our product. We have some great improvements in the pipeline and I'm sorry that they came too late for you. In case others have had similar experience, it's worth mentioning that some of these seem fixable by structuring your data differently[1].
Specifically, complaints 2-4 sound like they all arose from nesting all of your data in one tree[1] and using a query for all children[2]. This means you'll load too much data in every request, which will slow down your microservices and cause a large bill for unnecessary outbound traffic.
#5 has two possible solutions. Either use the push() message to avoid any conflicts in the data you're writing or the transaction() method to manage the conflicts in an online-only mode. push() requires some work to recompose something from a series of changes, but has the advantage of being offline-compatible.
Regarding #6, I agree we can better support data migrations (we're looking into it). If your problem is as simple as the one listed, I'd really recommend checking out a library like lodash[3]. The ugly if statement could have been
if(_.has(user, 'new_subdocument.new_property')) {
/* do stuff */
}
or even:
var thing = _.get(user, 'new_subdocument.new_property', default);
// always do something with thing; we just added an in-memory
// value that we would have made a data migration for in the
// past.
Finally, regarding queues, are you referring to firebase-queue?[4] This is an open-sourced part of our internal infrastructure. There are currently 16 issues open, but they seem to be mostly feature requests. If you've found bugs we'd love some repo steps.
I hope that helps. We're always listening on [email protected], stackoverflow.com, and our slack channel.
I have been using Firebase for two months now and it is a total nightmare to me. The support is awful.
1) I don't get answers on Stackoverflow.
2) I have stopped using your slack as it's close to impossible to get any answer. It's a complete joke.
3) When I tried to google, I often end up getting the legacy documents which are deprecated
4) There are too many breaking changes between your different versions. This makes it so confusing to use angularfire/firebase and finding deprecated code examples.
5) The youtube videos feels like a huge marketing stunts and you are all busy trying to promote an ever changing/incomplete firebase. 10 month old videos are no longer valid because of breaking changes.
6) The security rules difference between firebase storage & firebase database
7) Querying being such a huge pain. There was an effort made in a 2014 blog post but obviously code is obsolete.
I know in the end. It must be the developer's fault who’s not smart enough for firebase maybe.
Interesting read, although other users have pointed out that some of the problems are solvable.
I started using Firebase in May after the integration with Google Play. I run a public transit app/website (movinggauteng.co.za), and I have a few 'real-time' features such as basic chat and public transit updates/delays during peak periods.
After hours on the Firebase docs, I'm still convinced that I'm better off with my own storage and database. I only use Firebase for Auth, Notifications (at times), Device testing, and almost everything else that doesn't require storing data that I don't already store myself.
I've been a fan of MongoDB from the very start of the project, and I'm still going strong with it. It works great for geospatial queries, and tailing the oplog is awesome.
* When transit notifications are created, I tail the oplog to pick them up, and send them to devices/browsers using Cloud Messaging.
* Send new chat messages to admins
* Sync user information in 'real-time', such as when marking a stop or route as a favourite.
These are things that I could also do with Firebase, but to be honest, I think allowing me to specify security rules in just JSON is a bit too extreme.
Firebase Auth complements my current auth system, because it was better than rolling out my own OAuth impl for Android clients (website is all session-based). Even though I use it, I still store all the user info I need on my side. Firebase Auth is just a 'helper' to authenticate users on mobile.
A lot of people would say "use PostgreSQL and save yourself the hassle". My view is that you should evaluate what your needs are, and use the tools that meet your needs.
I have a project where we're I'm using PostgreSQL and MongoDB together.
I'm storing a lot of financial data in PostgreSQL. I use MongoDB to only store metadata about each running task, I create a Mongo document and pass its ID to all the workers. When each worker completes a part of their task, they send acknowledgement to Mongo. I then pick up that acknowledgement through the oplog, and pipe it to the browser through a socket. Works like magic for me. I could probably do all of that in PostgreSQL, but the combination meets my needs well :)
"Server-less, doesn't mean code-less! This means that all your server logic is now in your web or mobile client."
Does this mean that the web page you serve up contains all of the code to talk to Firebase? Doesn't this mean that all of your clients have unfettered access to the database? Would all of your credentials (e.g., API keys, etc) be baked right into the pages you're serving up?
BaaS (and "serverless" in general) mean that since you don't control your database/storage/servers/etc. you no longer have the ability to implement your own custom Authentication and Authorization.
Firebase solves this by using Firebase Authentication (https://firebase.google.com/docs/auth/) to determine who a user is and Firebase Rules (currently implemented in the Realtime Database [https://firebase.google.com/docs/database/security], which this article mentions, and Firebase Storage [https://firebase.google.com/docs/storage/security]) to determine what a user can do. Yes, they're different languages, and we're working on upgrading the Realtime Database to use the new language syntax (we know it's a pain point, and we plan to address it).
I strongly recommend watching our I/O talk on "The Key to Firebase Security" (https://www.youtube.com/watch?v=xAsvwy1-oxE) which walks through the basics as well as shows the power of our rules system. While you probably can't specify all of your business logic in our Rules languages, you can enforce a vast majority of cases (including building things like per user rate limiting: http://jsfiddle.net/firebase/VBmA5/ and secure client side only trades: http://jsfiddle.net/firebase/j562wj1r/).
[+] [-] ericmsimons|9 years ago|reply
Further, the claim about no user data export isn't true - see this comment for more details: https://news.ycombinator.com/item?id=12526840
Happy to answer any q's from my experience building apps with firebase
[+] [-] jondubois|9 years ago|reply
The author did not mention this, but I've also heard a complaint that while Firebase's automatic conflict resolution is good for some use cases, that it's not all cases and that often you need to do the conflict resolution yourself.
Firebase does offer a solution for that, but again, I'm not convinced that this solution simplifies things when you consider the big picture - Conflict resolution is still going to be difficult regardless of whether you use Firebase or not.
Firebase solves the basic use case very well but then the work of customizing/fine-tuning it to make it behave exactly the way you want is just as hard, if not harder than just doing everything from scratch without Firebase.
I think Firebase is good for MVPs and it's also good for some types of simple apps, but I've seen several large apps using it and they ended up having to manage their own backend on the side anyway.
Firebase did not "free them from having to manage a backend" - With Firebase, not only do those companies still need to manage their own backends on the side; they also have to manage how Firebase interacts with that backend.
[+] [-] dfischer|9 years ago|reply
In that type of scenario I recommend: - memberships collection and model that under a separate domain.
Separation of concerns also seem like they weren't properly handled so it led to cruft.
[+] [-] officialchicken|9 years ago|reply
How do you manage the large price gradient jump from free to $1200/yr?
[+] [-] zallarak|9 years ago|reply
Would I use Firebase as a replacement for a relational DB in a traditional SaaS app? No. However, if I had to add real time chat to an app that had no other real time components I'd probably use it.
I agree with many of the author's critiques of the platform in general, hence my suggestion at using it sparingly when you fully understand the cost benefit analysis. If used correctly (real time features that don't involve mission critical data) Firebase is a game changer.
[+] [-] pavlov|9 years ago|reply
[+] [-] jsmith0295|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] TheAceOfHearts|9 years ago|reply
My biggest complaint so far: they haven't made the unminified source for the JS client available! You go on npm and you get the minified source. How is that acceptable? Heck, it's completely pointless too, because if I really wanted to "steal" the source I could prettify it and clean it up. It'd take a bit of effort, but it doesn't protect or hide anything. The reason why I wanted to use firebase was so I could hack up something quick. But as I was wiring stuff up, I got confused with their docs and figured I'd take a look at the source... Only to find a minified mess.
On top of that, they're not developing the project in the open. There's no public repo, so you can't contribute. I tweeted at them earlier today; hopefully it's an oversight and they fix it.
Otherwise, it's unlikely I'll consider ever using firebase for anything, if they continue with these anti-developer practices.
[+] [-] jamest|9 years ago|reply
We hear you on both counts.
FWIW the 2.x JS SDK was available unminified (see: https://cdn.firebase.com/js/client/2.4.2/firebase-debug.js). With our expansion launch at Google I/O we had to upgrade our serving infra -- along with virtually everything else -- and haven't added the capability back in to 3.x yet.
The closed source SDKs feedback is something we hear frequently. Unfortunately I can't give you anything better than 'hang tight' at the moment.
Being 'anti-developer' is the antithesis of the Firebase ethos. We strive to be as developer friendly as we can. There are areas where we're not doing a good enough job right now and we're actively working to get better.
I hope that helps add some color
[+] [-] languagewars|9 years ago|reply
For the criticisms not related to SaaS, some of them look like familiar debates, and I'd say a drawback of using noSQL is that I have something that looks ready faster but then I need to consciously hold it back from production until I've thought through structural problems which I would have worked out first in SQL.
[+] [-] girvo|9 years ago|reply
[+] [-] cheriot|9 years ago|reply
> These things may still be "hacked" using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.
So don't hack it and don't repeat it. Do it once on your server.
> You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.
So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple.
> dealing with relations with Firebase is pain in the ass.
Why are you using a key/value store?
> it's not possible to export your users data
Are the Firebase docs lying to me? https://firebase.googleblog.com/2015/03/private-backups-for-...
> Complex queries are impossible
It's a key/value store...
> Want to build an API for your product? It's impossible.
WTF?
> old-fashioned SQL Database, which overs 90% of our data storage needs... For the 10% part, we decided to use MongoDB to store messages and conversations at scale.
So no ONE datastore that you could find solves your problems well, but Firebase sucks because it didn't?
Sorry, I've been building a prototype with Firebase lately and this article goes beyond unhelpful into the land of complete nonsense. If someone has run into these issues, I'd love to dig into specifics.
[+] [-] HodGreeley|9 years ago|reply
[+] [-] umurkontaci|9 years ago|reply
[+] [-] HodGreeley|9 years ago|reply
[+] [-] drunkenazi|9 years ago|reply
"Crisp discovers every tiny detail on each visitor you chat with. From geolocation to device information, to full name and social profiles (LinkedIn and more). Crisp also discovers the company of the visitor. Are my visitors aware of this feature? Your visitors cannot see that you know so much about them."
"MagicType lets you view messages as they are typed. ... Visitors are not aware of MagicType, and cannot see what you type in response. Only you can see this."
[+] [-] shahzeb|9 years ago|reply
[+] [-] Lazare|9 years ago|reply
I'm not really seeing anything Firebase specific?
> you can't deal easily with data-migration like you can do with a simple SQL database [...] Relations are marvelous
Yeah, maybe you should have used a relational DB as the primary datastore for your relational data?
[+] [-] bikamonki|9 years ago|reply
If you've been around long enough, you probably had to convince the IT manager of one of your corp clients that it was a better idea to host the company's website on a hosting provider's server rather than in-house. Didn't you?
The argument of shouldn't trust your data to a BAAS provider is just silly: where's your data when you rent a VPS and mount your own back-end?
Maybe Firebase was not the right choice for this particular product, but don't trash it for it.
For me, the only missing feature is full-text search, yet the workaround is not as painful.
[+] [-] makomk|9 years ago|reply
[+] [-] anf|9 years ago|reply
"You don't own your data" is downright false -- you own it, you just don't host it. But do you ever really host it these days? Unless you're running it on your own hardware in your own facilities, probably not. So what the author should say is "migrating is expensive because we chose to build on top of a SaaS product using a proprietary API and we're surprised by this because we didn't plan any further than a single 3 week sprint".
[+] [-] welanes|9 years ago|reply
Well of course not, although that would be wonderful.
> Your can't perform operations to get active users
Something like this would do it, right:
});> Paying 100$ per month for something you can do on a 5$ DigitalOcean server is something that make you thinking twice about server-less magic-less.
I pay Firebase a handful of dollars every month and they handle user auth, hosting, CDN and data. Three or four overheads I no longer need to worry about. Having used Digitalocean and Stormpath (yikes) in the past, I'm happy to have my eggs in one rather than multiple baskets.
Yeah it cost me a few hours on Stackoverflow after bumping into some of the problems you describe but the path from idea to working app is so short with Firebase - and the cognitive load typically inherent with managing multiple services, so small - that it's worth learning the 'Firebase way' of dealing with data (which is mostly just the NoSQL way).
Crisp is sweet btw, I use it daily. Good job.
[+] [-] azinman2|9 years ago|reply
[+] [-] baptistejamin|9 years ago|reply
[+] [-] malloryerik|9 years ago|reply
It looks very similar to Firebase, but free, open source, and one advantage over others is being able to use several databases through various ORM's, so you could mix and match, for example, Postgres and DynamoDB as desired.
Must be using Node.js, though these days I think you might even be able to use Koa or Hapi in addition to default Express.
[+] [-] bsaul|9 years ago|reply
[+] [-] oskarer|9 years ago|reply
[+] [-] diegorbaquero|9 years ago|reply
[+] [-] bdcravens|9 years ago|reply
[+] [-] ranyefet|9 years ago|reply
[+] [-] inlined|9 years ago|reply
Specifically, complaints 2-4 sound like they all arose from nesting all of your data in one tree[1] and using a query for all children[2]. This means you'll load too much data in every request, which will slow down your microservices and cause a large bill for unnecessary outbound traffic.
#5 has two possible solutions. Either use the push() message to avoid any conflicts in the data you're writing or the transaction() method to manage the conflicts in an online-only mode. push() requires some work to recompose something from a series of changes, but has the advantage of being offline-compatible.
Regarding #6, I agree we can better support data migrations (we're looking into it). If your problem is as simple as the one listed, I'd really recommend checking out a library like lodash[3]. The ugly if statement could have been
if(_.has(user, 'new_subdocument.new_property')) { /* do stuff */ }
or even:
var thing = _.get(user, 'new_subdocument.new_property', default); // always do something with thing; we just added an in-memory // value that we would have made a data migration for in the // past.
Finally, regarding queues, are you referring to firebase-queue?[4] This is an open-sourced part of our internal infrastructure. There are currently 16 issues open, but they seem to be mostly feature requests. If you've found bugs we'd love some repo steps.
I hope that helps. We're always listening on [email protected], stackoverflow.com, and our slack channel.
[1]: For a great article, see https://firebase.googleblog.com/2013/04/denormalizing-your-d... or the general Firebase data layout guide at https://firebase.google.com/docs/database/web/structure-data [2]: Try using order + limitToFirst(N) https://firebase.google.com/docs/database/web/retrieve-data#... [3]: https://lodash.com/ [4]: https://github.com/firebase/firebase-queue
[+] [-] KingOfMyRoom|9 years ago|reply
1) I don't get answers on Stackoverflow.
2) I have stopped using your slack as it's close to impossible to get any answer. It's a complete joke.
3) When I tried to google, I often end up getting the legacy documents which are deprecated
4) There are too many breaking changes between your different versions. This makes it so confusing to use angularfire/firebase and finding deprecated code examples.
5) The youtube videos feels like a huge marketing stunts and you are all busy trying to promote an ever changing/incomplete firebase. 10 month old videos are no longer valid because of breaking changes.
6) The security rules difference between firebase storage & firebase database
7) Querying being such a huge pain. There was an effort made in a 2014 blog post but obviously code is obsolete.
I know in the end. It must be the developer's fault who’s not smart enough for firebase maybe.
[+] [-] nevi-me|9 years ago|reply
I started using Firebase in May after the integration with Google Play. I run a public transit app/website (movinggauteng.co.za), and I have a few 'real-time' features such as basic chat and public transit updates/delays during peak periods.
After hours on the Firebase docs, I'm still convinced that I'm better off with my own storage and database. I only use Firebase for Auth, Notifications (at times), Device testing, and almost everything else that doesn't require storing data that I don't already store myself.
I've been a fan of MongoDB from the very start of the project, and I'm still going strong with it. It works great for geospatial queries, and tailing the oplog is awesome.
* When transit notifications are created, I tail the oplog to pick them up, and send them to devices/browsers using Cloud Messaging. * Send new chat messages to admins * Sync user information in 'real-time', such as when marking a stop or route as a favourite.
These are things that I could also do with Firebase, but to be honest, I think allowing me to specify security rules in just JSON is a bit too extreme.
Firebase Auth complements my current auth system, because it was better than rolling out my own OAuth impl for Android clients (website is all session-based). Even though I use it, I still store all the user info I need on my side. Firebase Auth is just a 'helper' to authenticate users on mobile.
A lot of people would say "use PostgreSQL and save yourself the hassle". My view is that you should evaluate what your needs are, and use the tools that meet your needs.
I have a project where we're I'm using PostgreSQL and MongoDB together. I'm storing a lot of financial data in PostgreSQL. I use MongoDB to only store metadata about each running task, I create a Mongo document and pass its ID to all the workers. When each worker completes a part of their task, they send acknowledgement to Mongo. I then pick up that acknowledgement through the oplog, and pipe it to the browser through a socket. Works like magic for me. I could probably do all of that in PostgreSQL, but the combination meets my needs well :)
[+] [-] Mister_Snuggles|9 years ago|reply
Does this mean that the web page you serve up contains all of the code to talk to Firebase? Doesn't this mean that all of your clients have unfettered access to the database? Would all of your credentials (e.g., API keys, etc) be baked right into the pages you're serving up?
If so, that's scary. Really, really scary.
[+] [-] asciimike|9 years ago|reply
BaaS (and "serverless" in general) mean that since you don't control your database/storage/servers/etc. you no longer have the ability to implement your own custom Authentication and Authorization.
Firebase solves this by using Firebase Authentication (https://firebase.google.com/docs/auth/) to determine who a user is and Firebase Rules (currently implemented in the Realtime Database [https://firebase.google.com/docs/database/security], which this article mentions, and Firebase Storage [https://firebase.google.com/docs/storage/security]) to determine what a user can do. Yes, they're different languages, and we're working on upgrading the Realtime Database to use the new language syntax (we know it's a pain point, and we plan to address it).
I strongly recommend watching our I/O talk on "The Key to Firebase Security" (https://www.youtube.com/watch?v=xAsvwy1-oxE) which walks through the basics as well as shows the power of our rules system. While you probably can't specify all of your business logic in our Rules languages, you can enforce a vast majority of cases (including building things like per user rate limiting: http://jsfiddle.net/firebase/VBmA5/ and secure client side only trades: http://jsfiddle.net/firebase/j562wj1r/).
FWIW, this system is not a concept unique to Firebase. Parse has user ACLs (PFACL, PFRole on iOS for instance: https://parseplatform.github.io/docs/ios/guide/#roles), and Horizon has it's own Rules templating system ( http://horizon.io/docs/permissions/).
[+] [-] baptistejamin|9 years ago|reply
Our backend were already splited.
[+] [-] asciimike|9 years ago|reply
[+] [-] harisvs|9 years ago|reply
For Android/ios clients there is data persistence for minimising data usage.
Saving user details as Json will help u export user details too
[+] [-] dfischer|9 years ago|reply