Why I’m dumping Firebase for Web • Hacker News Board

Re: Why I’m dumping Firebase for Web

#91

Post by HeshamA » Wed, Aug 09, 2017, 1:14 PM UTC

amelius wrote: post #76

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…

I'm curious, what DB tool will you now consider using instead?

Same here. I've started a prototype using firebase, however, I'm concerned about issues like this and the fact that sometime in the future I get a shutdown notice and I will have to migrate.

I can roll my own using Rails but I'm trying to avoid that.

Re: Why I’m dumping Firebase for Web

#92

Post by afro88 » Wed, Aug 09, 2017, 1:15 PM UTC

Most of the database concerns have been addressed in other blog posts etc. If you need relational data, don't use firebase. Period. Where you need "anything beside a simple key lookup" for the majority of your queries, go elsewhere. That's the first rule of Firebase.

The second rule of Firebase is structure your data and populate it in a way that makes it simple to fetch with a simple key lookup.

Re: Why I’m dumping Firebase for Web

#93

Post by luord » Wed, Aug 09, 2017, 1:28 PM UTC

The stack he describes at the end is pretty similar to mine (only Python instead of Node and PostgreSQL instead of MySQL); although I actually don't have a problem with firebase.

Re: Why I’m dumping Firebase for Web

#94

Post by CaveTech » Wed, Aug 09, 2017, 1:28 PM UTC

mluggy wrote: post #88

TeMPOraL wrote: post #86

Earlier quoted context omitted.

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

When was that announced?

You basically have 2 weeks to implement user management functionality? An acquisition so hot they basically say fuck you to all customers. Amazing.

Re: Why I’m dumping Firebase for Web

#95

Post by briffle » Wed, Aug 09, 2017, 1:32 PM UTC

calpaterson wrote: post #47

saganus wrote: post #41

Earlier quoted context omitted.

Wow. Running a query takes down the db? That sounds like a major problem. How can that happen? Maybe returning incorrect or incomplete results due to sharding... But taking the db down? That's very... Unexpected.

Never used firebase but for what it's worth you can take down most databases with a bad enough query.

In the RDBMS world, you can take down pretty much any database by giving someone in accounting a copy of Crystal Reports :)

Re: Why I’m dumping Firebase for Web

#96

Post by TeMPOraL » Wed, Aug 09, 2017, 1:42 PM UTC

CaveTech wrote: post #94

mluggy wrote: post #88

Earlier quoted context omitted.

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/

When was that announced? You basically have 2 weeks to implement user management functionality? An acquisition so hot they basically say fuck you to all customers. Amazing.

The announcement post[0] seems to be from March, which would give one about 4.5 months to migrate.

--

[0] - https://stormpath.com/blog/stormpaths-new-path

Re: Why I’m dumping Firebase for Web

#97

Post by dozzie » Wed, Aug 09, 2017, 1:55 PM UTC

aamederen wrote: post #63

Firebase taught me, for a B2B2C kind of app: 1) Relational databases are more flexible: you model your data according to the actual "relations" between them, instead of how you want to query them. This makes it easier to add new views/queries to your application. 2) Joins are necessary 3) In a very short time, you need complex authentication logic and it is very hard to do it without looking at the requested (and rel…

> 2) Joins are necessary

> 4) Moving more logic from servers to clients forces you to be more careful [...]

Back to the very old architecture of client-server-database instead of client-database that was proven dumb long time ago. The client-server-database architecture was happily ditched by the crowd that builds dynamic websites and calls them "web applications", so now everybody rediscovers that it actually is a poor idea for client to talk to database directly.

Re: Why I’m dumping Firebase for Web

#98

Post by tomcam » Wed, Aug 09, 2017, 2:28 PM UTC

forgottenacc57 wrote: post #78

halfnibble wrote: post #21

Nothing beats Django and the Django Rest Framework. In my opinion, it's easier to code a RESTful API in Django than to configure a 3rd party service.

Try Falcon.

Looks interesting. What back end do you use?

Re: Why I’m dumping Firebase for Web

#99

Post by wolco » Wed, Aug 09, 2017, 2:33 PM UTC

It sounds like the company is growing up. Firebase is great for simple use cases but has too many limitations for most cases.

Re: Why I’m dumping Firebase for Web

#100

Post by vram22 » Wed, Aug 09, 2017, 2:34 PM UTC

briffle wrote: post #95

calpaterson wrote: post #47

Earlier quoted context omitted.

Never used firebase but for what it's worth you can take down most databases with a bad enough query.

In the RDBMS world, you can take down pretty much any database by giving someone in accounting a copy of Crystal Reports :)

How, specifically? Something like a very complex query joining too many tables, or maybe a full Cartesian product of n > 2 tables?