Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m dumping Firebase for Web

lugassy.net

Post reply on HN
Print view View original

31–40 of 123 posts

Re: Why I’m dumping Firebase for Web

#31

Post by teen »

superfrank wrote: post #24

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…

same thing bit me. also the onDisconnect events are not guaranteed to fire, so you get orphaned stale data everywhere, and need to run manual clean up scripts.

Re: Why I’m dumping Firebase for Web

#32

Post by grahamperich »

cakedoggie wrote: post #30
superfrank wrote: post #24

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…

> at 100k concurrent users That is a huge number of concurrent users though.

The risk of building on a platform that you know has that hard cap isn't worth it for many ventures though

Re: Why I’m dumping Firebase for Web

#33

Post by vbsteven »

vgchh wrote: post #20

I stopped using firebase DB about a year back. Now I prefer: 1) API backend using Google Cloud Endpoints deployed in GKE. Still using firebase Auth. 2) React SPA served from firebase hosting. Using FirebaseAuthUI One thing I continue to be astonished about is how difficult it remains to build a real apps (ssl, auth, persistence, packaging, deployment) as a one person team.

Keep your stack simpler with an integrated framework instead of going for the latest fancy cloud-everything tech and it is a lot easier building/deploying as a one man team.

What is wrong with a simple rails/spring/django project hosted on heroku/elasticbeanstalk? Ssl, auth, persistence, packaging and deployment are all covered and easy.

Of you want a bit more control you can swap heroku/eb for a vps and use ansible for deloyment which is my preferred method for one person projects

Re: Why I’m dumping Firebase for Web

#34

Post by mluggy »

srcreigh wrote: post #26

I love Firebase, I think it's a great tool. I actually gave a talk about Firebase when I was an intern at Google in 2015. I've liked it for a while. I think it's a simple model that actually lets you build most things very quickly and in a fun way (since it's all real-time). Here's my response to some of your points Only easy if you implement FirebaseAuthUI, which has a UI that is out of context and intolerable if yo…

1. I agree Firebase is great for Hackatons. 2. Iterating multiple records is a pain and the indexing firebase provides is not very helpful. 3. By caching computation I mean getting raw data from the database processed and digested (i.e converting a costly top 10 to an html fragment you can use later). 4. Storing records with firebase-admin is like a super-user, it ignores all security AND validation rules. 5. Cloud functions are not cool.

Re: Why I’m dumping Firebase for Web

#35

Post by mluggy »

evan_ wrote: post #16

I never actually deployed this, so I don't know how it would have worked with lots of users, but when I was writing a game that required "secret sauce" my plan was to have a "server" connect as a privileged user- clients would submit their proposed moves to a write-only queue that was only readable to the "server" which would do a rules-check and update the game state as necessary.

yes, since you don't trust your users you have to get sensitive processes (like promotions, unlocks, rewards) on a separate server process or cloud function. this kinda defeats the purpose of serverless.

Re: Why I’m dumping Firebase for Web

#36

Post by skrebbel »

superfrank wrote: post #24

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…

> The problem I have is that someone took this cool project and basically lied to the public about its capabilities.

Oh come on, it was a startup. The same people who made the tool told the lies (if that's what they were). Now under Google, this is still the case - the original founders now lead the Firebase department if I'm not mistaken. I'm pretty sure they have influence over the marketing messages.

Re: Why I’m dumping Firebase for Web

#37

Post by asadlionpk »

superfrank wrote: post #24

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…

That's not the only limit btw. If any node (say "/users/") crosses 'some' number of subnodes ("/users/a", "users/b") then you cannot do any queries on the node itself. Like I cannot get even get the IDs of the subnodes ("a","b",...).

I also got similar advice to shard my users or something.

So right now, we have crossed that limit and are unable to know how many users are on our system. Their server just fails and takes down the DB for 10 or so mins if I do that query.

Firebase is good for MVPs and prototypes but not at all scalable.

Re: Why I’m dumping Firebase for Web

#38

Post by asadlionpk »

wolframhempel wrote: post #28

(deepstream employee here) despite its flaws, Firebase has some great ideas, e.g. its permission language that strongly inspired us when building https://deepstreamhub.com/ . But there are some aspects, many mentioned by the OP that send us down a different route: - Serverless is a great goal, but only works for low complexity apps. We've designed deepstream explicitly not to take the server away, but as a layer that…

As a firebase user, what would be the easiest path to map my multi-nested firebase DB (like 'chatrooms/room1/msgs/msg1`) structure to deepstream?

Since I think DS doesn't support more than one level of nested data. Is there an easy way?

Re: Why I’m dumping Firebase for Web

#39

Post by kylehotchkiss »

I'm fine in general with Firebase, but feel like its overhyped. It's nice to get little cloud functions, onWrite database hooks, and somewhat realtime data, but if a competitor rose up and took at stab at frequently noted pain points, they could probably grab market share pretty easily.

My pain points:

Cloud functions debugger = -1.

Can't tell you how much fretting I have dealt with using async.each and some buffer overflows or some other low level Node.js error that never makes it to the debugger. And the debugger isn't a plaintext log. It's a tacky UI where each line is an element, the "logs" are 600px high, and whenever you scroll a little you lose your spot on longer JSON logs.

I also strongly, strongly dislike how easy it is to accidentally delete data from storage. That red X icon is wayyy to easy to accidentally click and daily backups only don't give you wiggle room to recover on heavily used apps. This makes it sadly difficult to use their database view to present quick things to others without building a UX for it.

Let's not talk about how setting a field to `new Date()` just loses the value entirely instead of throwing an error or defaulting to ServerTime.

Re: Why I’m dumping Firebase for Web

#40

Post by superfrank »

cakedoggie wrote: post #30
superfrank wrote: post #24

I have had so many issues with Firebase, but the one that really pisses me off the most is that they used to advertise things like "scale worldwide to millions of users" and "Unlimited Connections" but then cap you at 100k concurrent users (10k initially and will gradually bump you up to 100k). When we got in contact with them about this they were nice enough to explain that we could create another database and shard…

> at 100k concurrent users That is a huge number of concurrent users though.

Depends on your perspective, but it doesn't matter as it's not the unlimited they advertised.

Our app has multiple millions of users and we wanted to add a small feature which we were going to use Firebase to back. We ended up having to go back to the drawing board when we started a gradual roll out and hit that limit pretty quickly.

Post reply on HN