Reasons not to use Firebase(crisp.im)
crisp.im
Reasons not to use Firebase
https://crisp.im/blog/why-you-should-never-use-firebase-realtime-database/
106 comments
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.
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.
For sure. My point here is not that firebase is the end all be all, but that when you choose to rely on a technology/PaaS you need to do your own due diligence. Every person, project, company, etc has their own requirements and ability to make certain types of trade offs.
If one fails to do their proper due diligence, then they'll end up in a similar situation to OP. And that's okay, it happens to all of us every now and then. But when you screw up that decision despite there being ample documentation, blogs, and known limitations readily available to you with a few Google searches, then IMO it's inappropriate to write a slam piece against the technology/PaaS like OP did.
If one fails to do their proper due diligence, then they'll end up in a similar situation to OP. And that's okay, it happens to all of us every now and then. But when you screw up that decision despite there being ample documentation, blogs, and known limitations readily available to you with a few Google searches, then IMO it's inappropriate to write a slam piece against the technology/PaaS like OP did.
> you could just have easily have achieved the same result by just using plain Socket.io or a similar library
Is this an easier problem than I think it is? Is there a well known path for scaling socket connections and synchronizing data across clients?
I suspect most cases where devs talk about a messaging problem, it's really a data synchronization problem. I'm starting to suspect the sweet spot for Firebase in a large application is as a cache and communication mechanism rather than the primary datastore. Is that along the lines of what you're seeing?
Firebase has a few subtleties, but its API footprint is small for a datastore. How much sympathy do we need to have for people that use a tool without reading the docs first?
"free them from having to manage a backend" For a certain class of mobile apps it does. If we want the marketing material to apply to every customer, what PaaS or SaaS company will be left standing?
Is this an easier problem than I think it is? Is there a well known path for scaling socket connections and synchronizing data across clients?
I suspect most cases where devs talk about a messaging problem, it's really a data synchronization problem. I'm starting to suspect the sweet spot for Firebase in a large application is as a cache and communication mechanism rather than the primary datastore. Is that along the lines of what you're seeing?
Firebase has a few subtleties, but its API footprint is small for a datastore. How much sympathy do we need to have for people that use a tool without reading the docs first?
"free them from having to manage a backend" For a certain class of mobile apps it does. If we want the marketing material to apply to every customer, what PaaS or SaaS company will be left standing?
Point noted.
I'm not sure that posting a marketing blurb about your product on every other vaguely related Hacker News post does your product any favours.
re: downvotes
i would assume most downvotes come from the context free buzzword bingo ad you just copy/pasted.
while alternative products are often great to suggest in threads, said suggestions usually at least attempt to alleviate some of the stated problems with the other product.
There's a nice list of issues in the parent post, which ones does your product solve, and how/why does it solve them?
i would assume most downvotes come from the context free buzzword bingo ad you just copy/pasted.
while alternative products are often great to suggest in threads, said suggestions usually at least attempt to alleviate some of the stated problems with the other product.
There's a nice list of issues in the parent post, which ones does your product solve, and how/why does it solve them?
Agreed - the user_ids and team_ids example was a personal flag for me based on my experience with nosql.
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.
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.
The Firebase docs don't recommend join tables - their relationship examples are like this (apologies for formatting):
"groups": { "techpioneers": { "name": "Historical Tech Pioneers", "members": { "alovelace": true, "ghopper": true, "eclarke": true } }
The docs also contain examples of how to manage removing both sides of these sorts of relationships using promises.
Still - I think using Firebase for your 'full stack' isn't a wise plan for the long term if your app is pushing the limits of what Firebase is good at.
"groups": { "techpioneers": { "name": "Historical Tech Pioneers", "members": { "alovelace": true, "ghopper": true, "eclarke": true } }
The docs also contain examples of how to manage removing both sides of these sorts of relationships using promises.
Still - I think using Firebase for your 'full stack' isn't a wise plan for the long term if your app is pushing the limits of what Firebase is good at.
There are many cloud-based (DO/AWS/GAE) small-ish servers available for $60/yr or less.
How do you manage the large price gradient jump from free to $1200/yr?
How do you manage the large price gradient jump from free to $1200/yr?
Where are you getting a jump like that? The monthly plan is $25/mo ($300/year) and there's a pay as you go option.
https://firebase.google.com/pricing/
Edit - Ah I see in the article. I mean, there's a pricing calculator right there on the page, if they knew they were going to be transferring 100G+. Not sure how they managed 100G for a dashboard though.
https://firebase.google.com/pricing/
Edit - Ah I see in the article. I mean, there's a pricing calculator right there on the page, if they knew they were going to be transferring 100G+. Not sure how they managed 100G for a dashboard though.
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.
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.
This kind of reminds me of those "we used MongoDB to build our social network and it sucks" articles from a couple of years ago.
I'm amazed at how many people have that attitude about things they just didn't know how to use
It eventually becomes a reputation and perception problem. For example, I've been happily using MongoDB for years now. The problems I've had with it are either:
1. Problems that I can solve by doing enough research up-front (how to model my data, enforcing constraints on my collections, testing something on small datasets first). 2. Problems I would have had on other systems (crashes where I didn't backup data, slow queries, etc.)
I love PostgreSQL, and I keep getting amazed by it as I dig deeper into it. I've however chosen to rather learn, and not have unhealthy biases towards and against certain tools and technologies.
I could say the same about the effort I put into most other tools that I rely on.
1. Problems that I can solve by doing enough research up-front (how to model my data, enforcing constraints on my collections, testing something on small datasets first). 2. Problems I would have had on other systems (crashes where I didn't backup data, slow queries, etc.)
I love PostgreSQL, and I keep getting amazed by it as I dig deeper into it. I've however chosen to rather learn, and not have unhealthy biases towards and against certain tools and technologies.
I could say the same about the effort I put into most other tools that I rely on.
That's one of the best reasons not to use people in your next project.
Man that sounds perfect :)
I worked with several Firebase apps, worked with Firebase protocol to make my own server. It's why we started with Firebase.
I really understand how to use it, how it's works (including server side, internal protocol).
Many people here talk about our example about relationships and we wanted to explain it to beginners, with a simple relation.
In our case, we had many relations, many data.
I really understand how to use it, how it's works (including server side, internal protocol).
Many people here talk about our example about relationships and we wanted to explain it to beginners, with a simple relation.
In our case, we had many relations, many data.
People have to learn sometime. Not everyone is a grizzled old veteran.
In my experience senior people tend to do this as much if not more than everyone else, though.
[deleted]
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.
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.
[Firebase founder]
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
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
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.
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.
Is there a good example of how to handle auth with a Couch/PouchDB setup? I'm a big fan of PouchDB.
I used nolanlawson's pouchdb-authentication which covers instructions and wrappers setup for http/cookie based couchdb auth. For oauth I'm not sure what people use..
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.
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.
> 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.
Have you had to scale anything like they describe? Prototype is one thing. They already said it got them of the ground quickly.
Their statements contradict the docs without explanation and are not internally consistent. It sounds more like engineers scapegoating a tool than a well thought out critique.
It seems none of the problems raised are actually caused by Firebase, but the design decisions they've made.
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."
"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.
Apple cannot see what you are typing, their autocomplete is entirely on-device. 3rd party keyboards can, if you allow it.
I didn't downvote you, but thought it'd be better to make it clear what the person was referring to. The scenario mentioned was chatting with customer service on a website (like chatting with Apple customer care on Apple's website, foe example), where any message you type or edit would be seen by the customer service agent while you type, even if you didn't hit Enter or click on Send. This is not related in any way to the autocomplete feature on Apple's iOS keyboard or about what third party keyboards on iOS can do.
Thanks, i realised my mistake when it was too late.
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?
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.
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.
In an ideal world, VPSes are a commodity. But, as someone who's currently trying to evaluate switching part of our backend from OpenStack and DigitalOcean to AWS, it's not anywhere near as simple as it could be. Everyone is still platform locked to a greater or lesser degree, and those platform-specific tweaks and quirks oftentimes don't come up til you actually start trying to run a transition.
Give it a couple of years and BAAS will be a commodity...
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".
"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".
> Server-less doesn't mean pricing-less
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.
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).
Crisp is sweet btw, I use it daily. Good job.
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
The example about active users was more about KPIs, and not connected users. You can't perform a map/reduce operation.
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.
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?
Horizon uses RethinkDB, you can still build around RethinkDB directly.
You wouldn't run into password issues, since Horizon doesn't yet support password authentication.
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.
[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
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
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.
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.
Hello,
Firebase YouTuber, Slacker, AngularFire contributor, and Stackoverflower here. Feel free to ping me personally in the Slack channel (davideast) of via email ([email protected]) to talk more about all of these problems you've hit. We work hard to make sure people get their questions answered so I'd love to have a discussion with you.
Firebase YouTuber, Slacker, AngularFire contributor, and Stackoverflower here. Feel free to ping me personally in the Slack channel (davideast) of via email ([email protected]) to talk more about all of these problems you've hit. We work hard to make sure people get their questions answered so I'd love to have a discussion with you.
I think Firebase is a pretty cool guy. Eh helps you develop high-quality apps, grow your user base, earn more money and doesn’t afraid of anything.
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 :)
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?
If so, that's scary. Really, really scary.
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.
Firebase engineer here:
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/).
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/).
We used Firebase ACL to prevent from that.
Our backend were already splited.
Our backend were already splited.
Ok, so Firebase already has a way to make sure clients can only look at/update data they're authorized to do so?
What about business rules? Is there a way to enforce that, for example, when one product is ordered an additional item is automatically added to a shopping cart (e.g., if I buy a computer, my province requires a recycling fee be paid too)?
Or does this get beyond what Firebase is meant for?
What about business rules? Is there a way to enforce that, for example, when one product is ordered an additional item is automatically added to a shopping cart (e.g., if I buy a computer, my province requires a recycling fee be paid too)?
Or does this get beyond what Firebase is meant for?
The rules for the Firebase Database allow read & write access as well as validation. It may not handle every possible case of business logic, but it's a very powerful tool.
A common pattern is to have a server process running that watches parts of the firebase tree and then runs business logic in response to changes.
It's described as client - db - server rather than client - server - db. I believe there are also Firebase queue and task abstractions that make it fairly easy to map a write to a 'backend handler'.
It's described as client - db - server rather than client - server - db. I believe there are also Firebase queue and task abstractions that make it fairly easy to map a write to a 'backend handler'.
Surprised that nobody has mentioned it since we're here, but the Hacker News API is powered by Firebase: https://github.com/HackerNews/API
What u could do is run a simple nodejs server using firebase API and
Save data to a db, (rethinkdb) from day one! (Backup)
For Android/ios clients there is data persistence for minimising data usage.
Saving user details as Json will help u export user details too
For Android/ios clients there is data persistence for minimising data usage.
Saving user details as Json will help u export user details too
How would you guarantee consistency between firebase and rethinkdb?
Because nodejs SDK for firebase is real-time. Additions deletions etc are real-time.
It will work as long as your server is running.
It will work as long as your server is running.
No consistency issues "as long as your server is running" is not a good plan for backups. Also "real-time" has many meanings, and the one you mean does not bring consistency guarantees. Actually, (I may be wrong on this) I don't think that any usage of "real-time" has anything to do with consistency.
As for actual data backup , firebase offers this in the standard plan. But real-time to consistency is bit of a gray zone.
I was just rehashing something the firebase team built . Streaming data import something .
Firebase team says they have something in the pipeline , I hope they release it soon.
I was just rehashing something the firebase team built . Streaming data import something .
Firebase team says they have something in the pipeline , I hope they release it soon.
[deleted]
Firebase is the only service that provides a nice client-side abstraction for a real-time database. (Fine there's also Meteor and Horizon.io by RethinkDB.)
I highly recommend it for the reading side of things. I agree that writing from the client to Firebase is highly problematic so I use a client -> API server -> other DB -> Firebase architecture.
My architecture also gets around the fact that Firebase is hard to query.
I highly recommend it for the reading side of things. I agree that writing from the client to Firebase is highly problematic so I use a client -> API server -> other DB -> Firebase architecture.
My architecture also gets around the fact that Firebase is hard to query.
It seems like parse server on digital ocean is the way to go for simple self hosted back end as a service these days.
I learn swift and ios development for a couple weeks now. I am backend engineer and devops for 5yrs and firebase looks very attractive.
I know how hard and time consuming it is to build backend properly and firebase looks like a big shortcut.
Do you know some applied design patterns in swift for quick firebase replacement?
I know how hard and time consuming it is to build backend properly and firebase looks like a big shortcut.
Do you know some applied design patterns in swift for quick firebase replacement?
It's less about patterns for swift and more about how you model your data and what your needs are. There is no simple answer.
Until earlier this year I used Parse + Firebase, and the combination was absolutely heavenly. Parse for all of the standard stuff and a tight Firebase integration whenever I had a real-time component. Needless to say the FB announcement really upset me a great deal.
[Former Parse engineer, current Firebase engineer]. Sorry to hear that. We were all upset by the shutdown announcement. I've been trying to help a few people with migrations. Hopefully github.com/firebase/parse-migration-tools can help if you'd like to migrate any of your Parse data to Firebase.
I'm checking it our right now and it does look like it could be really useful! Thank you so much
Was in the same boat about 2 years ago, was creating a mobile app that was a calendar + real time chat/location sharing. Used Parse and Firebase and it was really great but never got to scale to know how it would have held up.
One of the reason I can't use Firebase for a mobile app is its SDK for Android relies on Google Play Services. And that app needs to target China market. And most Android phone in China has no Google Play.
And again, premature optimization is the root of all evil. Most of similar stories began with the choice of going fully no-sql and later missing the simplicity of RDBMS in handling complex schemas.
> … it's not possible to export your users data. You can't export emails, password hashes.
Could someone provide details on email/password export from Firebase? This limitation seems very critical.
Could someone provide details on email/password export from Firebase? This limitation seems very critical.
They'll export your user data (including hashed passwords) with a written email request to them. I did this a few years back and it was super simple. It sounds like OP wants a button to click that will immediately throw a CSV at you, which (for obvious security related reasons) is a really poor idea.
In general most of OP's complaints are inaccurate- it sounds like they just didn't fully read the docs before building their app.
In general most of OP's complaints are inaccurate- it sounds like they just didn't fully read the docs before building their app.
If your users' data is hosted by some cloud provider, making regular backups (at least nightly, ideally more frequent) independently of that cloud provider is common practice.
Otherwise you can end up like Code Spaces, who lost their users' data and all their backups at the same time.
Otherwise you can end up like Code Spaces, who lost their users' data and all their backups at the same time.
It's half-true that you can't export emails. You can't do it directly, but if you save each email address on the user during account creation, then you're covered.
It's not documented, but apparently you can request the password hashes as well.
Firebase's querying methods are also severely limited. Yes, you can be smart about how you structure your data to overcome some of these limitations, but I've noticed that many db operations that are typically simple and inexpensive tend to require trickery and gymnastics with firebase.
I think my least favorite part of my experience with firebase has been the use of their security rules. First off, the "bolt" compiler is really bad, but necessary to avoid writing a huge mess of json. Often times, it compiles your security rules into a single line of json, and then checks for errors, giving you an unhelpful message that the compilation failed on line 1, column 32,513.
The security rules are not only cumbersome to write, and in a language you have to learn specifically for firebase, but also completely different when using the firebase database and firebase storage. For storage, you have a new language and new syntax to learn.
Moreover, it's pretty common that you'll update the schema for some object in the database and then be faced with a "Permission denied" error on all future writes. It's impossible to put the application into dev mode to get a more helpful error message saying which specific field the write failed on. And even with lots of tests, it is really scary deploying changes to the security rules to production in a way I just haven't felt using other dbs.
Come to think of it, that's not the worst part. For me, it's been their support. I really think they use some kind of generic answer bank to generate the bulk of their responses. Half the time the response doesn't even make sense in the context of the request I send. Something like "I'm getting X error message when I try Y using Z setup" will get a response like "Could you send a screenshot of the error message?" -- where the error message was copied and pasted verbatim into the original email. I suppose they hope I'll just give up after so much time wasted on the issue?
After using firebase for over a year, I'd wholeheartedly advise steering clear of it for anything other than prototypes and hackathon projects.
It's not documented, but apparently you can request the password hashes as well.
Firebase's querying methods are also severely limited. Yes, you can be smart about how you structure your data to overcome some of these limitations, but I've noticed that many db operations that are typically simple and inexpensive tend to require trickery and gymnastics with firebase.
I think my least favorite part of my experience with firebase has been the use of their security rules. First off, the "bolt" compiler is really bad, but necessary to avoid writing a huge mess of json. Often times, it compiles your security rules into a single line of json, and then checks for errors, giving you an unhelpful message that the compilation failed on line 1, column 32,513.
The security rules are not only cumbersome to write, and in a language you have to learn specifically for firebase, but also completely different when using the firebase database and firebase storage. For storage, you have a new language and new syntax to learn.
Moreover, it's pretty common that you'll update the schema for some object in the database and then be faced with a "Permission denied" error on all future writes. It's impossible to put the application into dev mode to get a more helpful error message saying which specific field the write failed on. And even with lots of tests, it is really scary deploying changes to the security rules to production in a way I just haven't felt using other dbs.
Come to think of it, that's not the worst part. For me, it's been their support. I really think they use some kind of generic answer bank to generate the bulk of their responses. Half the time the response doesn't even make sense in the context of the request I send. Something like "I'm getting X error message when I try Y using Z setup" will get a response like "Could you send a screenshot of the error message?" -- where the error message was copied and pasted verbatim into the original email. I suppose they hope I'll just give up after so much time wasted on the issue?
After using firebase for over a year, I'd wholeheartedly advise steering clear of it for anything other than prototypes and hackathon projects.
I'd love some more feedback on the Rules (disclosure, I'm an engineer on that team).
JSON was originally picked since it felt closely aligned with Firebase (JSON data => JSON rules), but as we started building more into them (indices, etc.), and as people started writing more complex rules (even internally), things started getting really clunky. Blaze (https://github.com/firebase/blaze_compiler) and Bolt (https://github.com/firebase/bolt) were attempts to 1) add a less verbose syntax to rules, 2) add new features that promote code reuse (like functions), and 3) get feedback on the direction developers would like to see our authorization product move.
The new Firebase Storage Security Rules are the next iteration of that. They provide a non-JSON (though unfortunately non-standard) DSL with strong types, more functionality, functions, and some other cool things (like giving you actual row/col numbers for failures). We think it's an improvement on the JSON rules, but still think there's a lot left to do. Resolving the difference between the two languages is one of my goals, and I'm looking in to what it would take to update the Database to handle the Storage rules language so there's consistency across products.
Unfortunately, when it comes to building a custom DSL, it's hard to pick some standard. 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/), but I don't think there's a good standard out there. We picked XACML (https://en.wikipedia.org/wiki/XACML) as the basis for Storage Security Rules, but any other feedback on this would be much appreciated.
We've considered non-code ways of doing this (like Blockly [https://developers.google.com/blockly/]), but don't have any concrete plans around those.
As for verbose debug info, we used to support a "debug" parameter in our tokens (https://www.firebase.com/docs/web/guide/login/custom.html#se...) which would return the rule that failed (basically the output of the simulator, which told you exactly what happened where). I'm looking into adding that back, since I agree that it's pretty useful. If you haven't seen the database Security Rules Simulator (which shows this info) you should definitely check it out. Targaryen (https://github.com/goldibex/targaryen) is a similar concept that you might like (unfortunately only works on the database).
As for your second comment on support. The short answer is that I agree with you--since acquisition (and post I/O in particular), support has suffered (in terms of measurable things like response time as well as intangibles like response quality). I think there are a few reasons for this:
1. As a startup, you should optimize for an amazing support experience since at the expense of scalability. Everyone at Firebase was on a support rotation, and if customers had issues with the product, they talked directly with the engineer who built it and provided direct feedback and had their issue answered. It was a tradeoff (products were built slower), but it was incredibly important to is (engineers knew how the product was being used).
Now that we're more than just the original Firebase features, it's much harder to have every engineer doing support, and it's actually much less valuable to have them doing this now. A lot of the value of engineers triaging front line support for a more mature product has been removed--many of the cases we get are "RTFM" plain and simple, or the error message sent tells you exactly what the problem is (or there's a stack overflow post that details the exact problem that we've already answered). When cases get interesting, they get escalated to the engineer who built the feature. It's the people equivalent of load balancing, but unfortunately the routing isn't perfect ;)
Which is a great seque to the other half of the problem...
2. Unlike technology, scaling people based processes turns out to be really hard. Technology usually scales horizontally pretty easily, people don't. You can provision new machines in minutes, but training people takes years. We've spent a lot of time teaching our new support team what Firebase is, how Firebase is generally used, and what problems people run into. We've built playbooks for each feature, created canned responses, and generally tried to build infrastructure to make knowledge available as best we can.
I don't claim that these things have solved the problem, as when you're constantly working on new features, that also means the knowledge created and processes put in place have to be passed down to all of those locations. With any documentation or institutional knowledge, it's hard to ensure everything is up to date and people are all on the same page.
That said, the base line of "not asking for an error when the error is right there" is occasionally not there, and I'm working with the support team leads to combat this (as well as generally improve the experience). If I could wave a magic wand and change one thing about our current support it would be for people to adopt a distinct personality vs a script based system--even if they ask a dumb question and admit it, it's better than following a script and sounding tone deaf. If you could wave a magic wand and change one thing, what would you change?
Feel free to email me mcdonald at firebase dot com (or answer here), I'd love to hear feedback on rules, support, or Firebase in general.
JSON was originally picked since it felt closely aligned with Firebase (JSON data => JSON rules), but as we started building more into them (indices, etc.), and as people started writing more complex rules (even internally), things started getting really clunky. Blaze (https://github.com/firebase/blaze_compiler) and Bolt (https://github.com/firebase/bolt) were attempts to 1) add a less verbose syntax to rules, 2) add new features that promote code reuse (like functions), and 3) get feedback on the direction developers would like to see our authorization product move.
The new Firebase Storage Security Rules are the next iteration of that. They provide a non-JSON (though unfortunately non-standard) DSL with strong types, more functionality, functions, and some other cool things (like giving you actual row/col numbers for failures). We think it's an improvement on the JSON rules, but still think there's a lot left to do. Resolving the difference between the two languages is one of my goals, and I'm looking in to what it would take to update the Database to handle the Storage rules language so there's consistency across products.
Unfortunately, when it comes to building a custom DSL, it's hard to pick some standard. 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/), but I don't think there's a good standard out there. We picked XACML (https://en.wikipedia.org/wiki/XACML) as the basis for Storage Security Rules, but any other feedback on this would be much appreciated.
We've considered non-code ways of doing this (like Blockly [https://developers.google.com/blockly/]), but don't have any concrete plans around those.
As for verbose debug info, we used to support a "debug" parameter in our tokens (https://www.firebase.com/docs/web/guide/login/custom.html#se...) which would return the rule that failed (basically the output of the simulator, which told you exactly what happened where). I'm looking into adding that back, since I agree that it's pretty useful. If you haven't seen the database Security Rules Simulator (which shows this info) you should definitely check it out. Targaryen (https://github.com/goldibex/targaryen) is a similar concept that you might like (unfortunately only works on the database).
As for your second comment on support. The short answer is that I agree with you--since acquisition (and post I/O in particular), support has suffered (in terms of measurable things like response time as well as intangibles like response quality). I think there are a few reasons for this:
1. As a startup, you should optimize for an amazing support experience since at the expense of scalability. Everyone at Firebase was on a support rotation, and if customers had issues with the product, they talked directly with the engineer who built it and provided direct feedback and had their issue answered. It was a tradeoff (products were built slower), but it was incredibly important to is (engineers knew how the product was being used).
Now that we're more than just the original Firebase features, it's much harder to have every engineer doing support, and it's actually much less valuable to have them doing this now. A lot of the value of engineers triaging front line support for a more mature product has been removed--many of the cases we get are "RTFM" plain and simple, or the error message sent tells you exactly what the problem is (or there's a stack overflow post that details the exact problem that we've already answered). When cases get interesting, they get escalated to the engineer who built the feature. It's the people equivalent of load balancing, but unfortunately the routing isn't perfect ;)
Which is a great seque to the other half of the problem...
2. Unlike technology, scaling people based processes turns out to be really hard. Technology usually scales horizontally pretty easily, people don't. You can provision new machines in minutes, but training people takes years. We've spent a lot of time teaching our new support team what Firebase is, how Firebase is generally used, and what problems people run into. We've built playbooks for each feature, created canned responses, and generally tried to build infrastructure to make knowledge available as best we can.
I don't claim that these things have solved the problem, as when you're constantly working on new features, that also means the knowledge created and processes put in place have to be passed down to all of those locations. With any documentation or institutional knowledge, it's hard to ensure everything is up to date and people are all on the same page.
That said, the base line of "not asking for an error when the error is right there" is occasionally not there, and I'm working with the support team leads to combat this (as well as generally improve the experience). If I could wave a magic wand and change one thing about our current support it would be for people to adopt a distinct personality vs a script based system--even if they ask a dumb question and admit it, it's better than following a script and sounding tone deaf. If you could wave a magic wand and change one thing, what would you change?
Feel free to email me mcdonald at firebase dot com (or answer here), I'd love to hear feedback on rules, support, or Firebase in general.
If you are still looking for feedback on the rules, here's what I've got:
1. Allow errors to be source mapped back to the language they were written in originally (bolt/blaze/json). Proper line numbers should be in the error messages, and if that's too much to ask for, then at least don't minify the JSON down to 1 line.
2. Bring back debug mode!
3. Make it possible to see, when changing a schema through the rules, what existing data that was writable will no longer be writable because it needs to be updated to match the new schema. (In dev mode, not so important. In production, this would be my number 1 concern.)
4. Stick to one language for all of the rules. I don't see any reason storage rules couldn't also use Bolt.
5. Allow imports. My rules file was getting long, so I eventually decided to split it logically and concatenate before compiling, but that's far from ideal.
6. Within the firebase console, allow us to see the details of incoming requests (including auth data) as they happen. And whether they're going to get a "Permission denied" error or not. It doesn't need to be a permanent log or anything like that, but maybe something you can enable for a few minutes while debugging. The simulator sort of helps, but it's so limited. There's nothing that compares to real logging when you're trying to figure out what's going wrong.
And as an aside, looking at the "legacy" docs again brings back good memories. I enjoyed firebase way more before the Google transition. In addition to having better support the docs were friendlier, and that made a big difference.
1. Allow errors to be source mapped back to the language they were written in originally (bolt/blaze/json). Proper line numbers should be in the error messages, and if that's too much to ask for, then at least don't minify the JSON down to 1 line.
2. Bring back debug mode!
3. Make it possible to see, when changing a schema through the rules, what existing data that was writable will no longer be writable because it needs to be updated to match the new schema. (In dev mode, not so important. In production, this would be my number 1 concern.)
4. Stick to one language for all of the rules. I don't see any reason storage rules couldn't also use Bolt.
5. Allow imports. My rules file was getting long, so I eventually decided to split it logically and concatenate before compiling, but that's far from ideal.
6. Within the firebase console, allow us to see the details of incoming requests (including auth data) as they happen. And whether they're going to get a "Permission denied" error or not. It doesn't need to be a permanent log or anything like that, but maybe something you can enable for a few minutes while debugging. The simulator sort of helps, but it's so limited. There's nothing that compares to real logging when you're trying to figure out what's going wrong.
And as an aside, looking at the "legacy" docs again brings back good memories. I enjoyed firebase way more before the Google transition. In addition to having better support the docs were friendlier, and that made a big difference.
Yes. I checked yesterday before releasing the article. It's still not possible.
https://groups.google.com/forum/#!topic/firebase-talk/zQW-zV...
Literally took me 5 seconds of Googling.
Literally took me 5 seconds of Googling.
Thanks. We updated the blog post.
Why would you use Firebase as main database for your data? That decision alone is extremely silly!
Its a DaaS. That's literally what it's for. That's like saying, why would you use the cloud? That's silly. Host it in your closet like we all did in the 90's, because that never caused any problems... Or what, use firebase only for chat data? So when you leave the company, some junior has to figure out 10 different places that the data is coming from when his boss starts breathing down his neck? Sounds like a freakin nightmare. There's nothing wrong with trying to keep things simple.
That worked really well for them! They obviously stored data in Firebase that did not belong in there. I have nothing against Firebase, but it's not meant to store all your app's data!
You guys should try out / check out http://gun.js.org/ then, it is a completely free and Open Source alternative that addresses many of the concerns in your post:
3) Pricing. Since it is Open Source you can run it on your own infrastructure, so you can control how much money you spend and you are not vendor locked in to premiums.
4) By default, gun only downloads 1 layer deep for every item you request instead of the entire subtree. This is great because it keeps things snappy fast and bandwidth light but still gives you control of when and how to load it.
5) You might not like us here, because we also support offline-first changes. However everything runs through a conflict resolution algorithm such that data is strongly Eventually Consistent. Check out the 1 minute demo videos in the repo https://github.com/amark/gun .
7) Relations are marvelous! Because gun is a graph database, you get relations as well as documents! As well as key/value, table, and other structures.
9) Own your data. Yeah, not a problem here since everything is Open Source. You run gun where you want to, and it simplifies the devops for you. So it is almost like having your own self-hosted DBaaS!
10) Because of the graph structure, you can do any custom query logic through conditional traversals (javascript is the query language). However, we do plan on supporting SQL and MongoDB Query spec coming up in the future - but not yet.
Happy to answer any questions and support you guys. Sorry that Firebase didn't work out for you, and congrats on your growth!
3) Pricing. Since it is Open Source you can run it on your own infrastructure, so you can control how much money you spend and you are not vendor locked in to premiums.
4) By default, gun only downloads 1 layer deep for every item you request instead of the entire subtree. This is great because it keeps things snappy fast and bandwidth light but still gives you control of when and how to load it.
5) You might not like us here, because we also support offline-first changes. However everything runs through a conflict resolution algorithm such that data is strongly Eventually Consistent. Check out the 1 minute demo videos in the repo https://github.com/amark/gun .
7) Relations are marvelous! Because gun is a graph database, you get relations as well as documents! As well as key/value, table, and other structures.
9) Own your data. Yeah, not a problem here since everything is Open Source. You run gun where you want to, and it simplifies the devops for you. So it is almost like having your own self-hosted DBaaS!
10) Because of the graph structure, you can do any custom query logic through conditional traversals (javascript is the query language). However, we do plan on supporting SQL and MongoDB Query spec coming up in the future - but not yet.
Happy to answer any questions and support you guys. Sorry that Firebase didn't work out for you, and congrats on your growth!
I don't know why you're being downvoted, because gun is, in my opinion, the closest alternative to a self-hosted firebase
Thanks, I really appreciate that. Being Open Source is rough, because people still judge you as "selling", despite the fact that everything is free and MIT licensed. Personally, it often causes depression, but I always pull through knowing/hoping that ultimately more lives will be impacted for the better.
So thank you for the encouragement, it really helps and I hope it sends a message to others whom might have projects of their own - don't let the negativity get you down. Thanks for being that reminder.
So thank you for the encouragement, it really helps and I hope it sends a message to others whom might have projects of their own - don't let the negativity get you down. Thanks for being that reminder.
CouchDB might be even closer. (Although it might be more accurate to say that Firebase is a non-self-hosted clone of Couch...)
Couch and Pouch really got a lot of things correct back in the day. However, Firebase runs off of MongoDB internally and as a result the realtime sync of Firebase is quite distinct from Couch/Pouch. Firebase is ultimately the centralized authority, while with Couch you can have more of a Master-Master setup (which is a good thing).
The RethinkDB team made Horizon (http://horizon.io), which is basically a self hosted firebase.
I think Horizon is very interesting, but keep in mind it's still very early. As they mentioned on the blog "Horizon is still under heavy active development. In response to user feedback and lessons we learned from building our own applications with Horizon, we’re revisiting many of our early architectural decisions. You can expect to see a fair amount of churn in the coming months as we continue to overhaul key parts of the Horizon stack."
Is there a guide for handling things like auth and permissions with gun?
Right now the standard way is to have a server that you proxy writes (the same setup you would have with Postges or Mongo) to, so I would refer you to things like Passport and stuff.
We plan on adding our own system, however it will be based on a fully P2P setup. Where every user has public/private keys and the server does not have access to that private key. We have a couple prototypes but we aren't security experts so we want to be careful and get some auditing before we publish it as a tool.
Finally, if you just want to control request/response, then there is a generic callback for that that gives you the ability to reject requests. See https://github.com/amark/gun/blob/master/examples/express-au... as an example, note that we may be changing this in the future though.
We plan on adding our own system, however it will be based on a fully P2P setup. Where every user has public/private keys and the server does not have access to that private key. We have a couple prototypes but we aren't security experts so we want to be careful and get some auditing before we publish it as a tool.
Finally, if you just want to control request/response, then there is a generic callback for that that gives you the ability to reject requests. See https://github.com/amark/gun/blob/master/examples/express-au... as an example, note that we may be changing this in the future though.
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