3 ms·
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
by jondubois 10y ago
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.
- marktangotango 10y agoPoint noted.
- shshhdhs 10y agoWhat is spa hosting?
- paublyrne 10y agoI'm not sure that posting a marketing blurb about your product on every other vaguely related Hacker News post does your product any favours.
- tetrep 10y agore: 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?
- ericmsimons 10y agoFor 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.
- cheriot 10y ago> 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?