4 ms·

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 an

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. Further, the claim about no user data export isn't true - see this comment for more details: https://news.ycombinator.com/item?id=12526840 https://news.ycombinator.com/item?id=12526840 Happy to answer any q's from my experience building apps with firebase

dfischer 10y ago
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.
- subpixel 10y ago
  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.
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 ago
  Point noted.
  - shshhdhs 10y ago
    What is spa hosting?
    - angersock 10y ago
      Single Page App, most likely.
    - nevir 10y ago
      It'd better include complimentary bath salts.
  - paublyrne 10y ago
    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.
  - tetrep 10y ago
    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?
- ericmsimons 10y ago
  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.
officialchicken 10y ago
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?
- IanCal 10y ago
  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/ 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.

dfischer 10y ago

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.

subpixel 10y ago
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.

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 ago
Point noted.
- shshhdhs 10y ago
  What is spa hosting?
  - angersock 10y ago
    Single Page App, most likely.
  - nevir 10y ago
    It'd better include complimentary bath salts.
- paublyrne 10y ago
  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.
- tetrep 10y ago
  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?
ericmsimons 10y ago
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.

officialchicken 10y ago

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?

IanCal 10y ago
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/ 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.