Live data from Hacker News

Why I’m dumping Firebase for Web

lugassy.net

81–90 of 123 posts

Re: Why I’m dumping Firebase for Web

#81
post #5
post #2

What are you moving to as an alternative?

I'm not the author, but I moved back to good old REST after flirting a bit with GraphQL.

I've been using graphql recently and I have found it very productive.

Providing a lot of flexibility to the client when querying the server eliminates a lot of server side work that would normally be required in order to implement new user stories.

It does require a bit of a mindset change so I am often having to force myself to try doing things in a different way to my first assumption.

Re: Why I’m dumping Firebase for Web

#82
When marketing interacts with engineering, it never ends well. And serious engineering tech homepage should advertize sincerely the limits and tradeoffs of its tech. That's how engineers work, and it's something sales people will never understand. We trust techs and people because they explain the limits, not in spite of it.

There's no free lunch. Whenever you pick a technology, understand what are the downsides. If you don't see any, then you probably don't know enough. Nosql is cool, unless you start needing transactions or database level data integrity checks ( hints : you always end up needing it at some point). Cloud hosting is cool, until you realize it's way more expensive for your needs, and that network is going to cost you a fortune. Serverless is great, but then what are you going to do to ensure business rules are exactly the same for all your clients, at all times, etc. etc.

Re: Why I’m dumping Firebase for Web

#83

Earlier quoted context omitted.

I had to increase our quota of layer 7 load balancer backends recently on GCP, submitted the request and the quota was increased within minutes. YMMV though, I guess?

The issue is that googles reputation is to avoid all contact. This gives less than zero faith in their commitments to support.

For Firebase it's actually not awful. We have 3 Firebase projects each with their caps raised to 100k concurrent connections, and it was a decent experience. Always the same person handling my support case etcetera, not too bad.

Re: Why I’m dumping Firebase for Web

#84
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…

In my spare time I use asp.net with knockout.js and typescript. Hosting on Azure. With that setup, I can deploy from my editor which is perfect for a one man team.

Re: Why I’m dumping Firebase for Web

#85

(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…

I tried to move away from Firebase to Deepstream a little while ago and sadly, Deepstream lacks the polish that Firebase has. It seems that Firebase is definitely the best solution out there if you truly want to avoid configuring your own servers, scaling and worrying about infrastructure related aspects. I think as long as developers inform themselves of the limitations of Firebase, it's a great product.

Re: Why I’m dumping Firebase for Web

#86

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.

> Oh come on, it was a startup.

And then people are surprised when I advise them to avoid startup products.

It's the classic tragedy of the commons; lying your way into an acquihire is a win for the successful founders, and a loss for the everyone else in the ecosystem, as more and more people grow sick of being played that way.

Re: Why I’m dumping Firebase for Web

#87

Earlier quoted context omitted.

> Their server just fails and takes down the DB for 10 or so mins if I do that query. I don't know if you are aware, but their DB can't handle more than 1000 requests/sec, so if you are iterating through a list of nodes and requesting data for each one you can hit that limit (not a good practice, but sometimes you have to). Additionally, once you hit that limit, the DB slows down but keeps accepting requests meaning,…

Iterating would require me to first get atleast a 'shallow' list of keys for that node. But even that one REST query for shallow list of all keys crashes their server instance. I am not even sure how I should get keys for all my user nodes anymore. I tried doing it from an offline JSON backup they generate. But that one giant 100GB+ JSON is impossible to parse with any available tools.

It's not impossible. You can do it pretty simply using https://pypi.python.org/pypi/ijson

Re: Why I’m dumping Firebase for Web

#88

Earlier quoted context omitted.

> 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.

> Oh come on, it was a startup. And then people are surprised when I advise them to avoid startup products. It's the classic tragedy of the commons; lying your way into an acquihire is a win for the successful founders, and a loss for the everyone else in the ecosystem, as more and more people grow sick of being played that way.

funny how you're right. i just got an api shutdown notice from stormpath (yet another product that supposed to save us developers): https://stormpath.com/

Re: Why I’m dumping Firebase for Web

#89
post #55

Earlier quoted context omitted.

Hi, I'm the main author of SocketCluster. SC does support multi-node clustering; in fact, you can deploy with a single command and scale with a single command. SC has been able to auto-scale on Kubernetes for almost one year now. See https://github.com/SocketCluster/socketcluster/blob/master/s... You're right that neither SC not Deepstream support long polling fallbacks but there are some very good architectural reas…

Corporate proxies are still an issue. Now they have something like SSL inspection proxies. Essentially the proxies can see everything even if it is https. And websockets does not work with these proxies even over https.

These do exist but they are not common; it's an insignificant proportion of users; in a representative sample of all web users, you're probably more likely to encounter users with JavaScript disabled in their browser altogether than users who are being snooped on and restrained by their company in this way.

Also, for these proxies to work, the company has to have access to the user's machine to install their own root CA certificates onto it; so generally, this issue is limited to corporate workstations and not BYO mobile devices and personal devices.

It's only a big problem if you want to support users from a specific company which happens to be a major customer (like a corporate SaaS solution); but if that particular company is such a big user of your product then they can always change their proxy policy to allow WebSockets from your domain.

I think that there are few enough of these companies that they should be the ones to adapt to new technology and not the other way around. It's important for open source projects and companies to set positive standards and not always bend to the will of corporations; especially when it comes to ethically-questionable practices.

You can still offer a REST API without real-time features for those users. The cost of long-polling is that bad. It's very easy to DDoS.

Re: Why I’m dumping Firebase for Web

#90
post #58
post #51

Earlier quoted context omitted.

Well the code itself doesn't look interesting at all, it is ugly as hell. Lacks comments, poorly organized, full of ugly names. e.g.: from chain.js: // TODO: BUG! Handle plural chains by iterating over them. (obj_has(next, 'put')){ // potentially incorrect? if(u !== next.put){ // potentially incorrect? Maybe? A lot of comments like: // ugly hack for now.

Lol. I opened a random src-file and started to wonder wtf this is. Source: https://github.com/amark/gun/blob/master/src/state.js

I can't believe so many js devs have regressed to single-letter variable names. This has been a code smell for generations :(
Post reply on HN