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

51–60 of 123 posts

Re: Why I’m dumping Firebase for Web

#51

Post by nagyf »

nagyf wrote: post #48
daurnimator wrote: post #18

Has anyone here used gun extensively? https://github.com/amark/gun it seems to position itself as a competitor to firebase, and wouldn't have many of the issues mentioned in the OP

Looks interesting, anyone has experience with it?

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.

Re: Why I’m dumping Firebase for Web

#52

Post by penagwin »

maktouch wrote: post #17
pier25 wrote: post #14

Earlier quoted context omitted.

GraphQL requires you to know upfront what you want to receive. You can't for example receive data for a menu with submenus with undetermined level of depth. You can hack your way around the problem, but it's ugly. Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company?

> Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company? http://graphql.org/learn/schema/#interfaces searchPersonOrCompany(name: "abc") { ... on User { first_name last_name } ... on Company { business_name } } As for the undetermined depths problem -- I agree to an extent…

Are you saying to request each level as needed? That's a lot of round trips, especially if levels need to be opened on mouseover or something.

Re: Why I’m dumping Firebase for Web

#53

Post by asadlionpk »

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.

You are right. But we usually have multiple ways to query our data in a DB. Not many ways to do that with the limited Firebase API.

Re: Why I’m dumping Firebase for Web

#54

Post by BrandiATMuhkuh »

I'm using (for amy.ac a math tutoring platform) Firebase now since about 10 month and I'm quite happy with it (now). After about ~3 month I became pretty tired of it since I came from a SQL background and I had no way of dealing with fancy queries. At this stage I almost switched to Deepstream (Sorry deepstream but non of your examples worked, so no Deepstream for me. Also I need todo my own load balancing, etc.).

Why I still use firebase has 2 major reasons. 1) Cloud Functions 2) Using Firebase-DB as my model and never query anythings from firebase. 3) I really don't want to touch docker/aws/load balancing/etc.

In my case, the client simply listens/writes to a particular model (DB-path). A cloud function will wake up, manipulate the model and falls a sleep.

That pretty much means, every view-model a user can see is pre-calculated and stored in the DB.

Re: Why I’m dumping Firebase for Web

#55

Post by mrath »

jondubois wrote: post #9
cultofmetatron wrote: post #4

http://phoenixframework.org/ actually has a built in websocket layer called channels. (its the inspiration for action cable and django channels) . Unlike deepstream, or socketcluster, it has a longpolling fallback as well as multi node clustering. Its a shame more people don't realize what a gold mine of a piece of technology it is.

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.

Re: Why I’m dumping Firebase for Web

#57

Post by dsun176 »

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…

I never heard of deepstream. But now I hate if for spamming the product camouflaged as opinion. Both on the medium article and here.

Re: Why I’m dumping Firebase for Web

#58

Post by dsun180 »

nagyf wrote: post #51
nagyf wrote: post #48

Earlier quoted context omitted.

Looks interesting, anyone has experience with it?

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

Re: Why I’m dumping Firebase for Web

#59

Post by pjc50 »

asadlionpk wrote: post #43
superfrank wrote: post #42

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.

Hmm. Congratulations, you've nerd-sniped me this morning!

This sounds like a classic use case for a streaming parser. The data is a mile wide and an inch deep, so at any point the memory requirements should not be too high.

What do you want to do when you've parsed it? Insert it into a real database? Iterate over it? Would simply turning it into a list of user IDs one per line suffice?

Re: Why I’m dumping Firebase for Web

#60

Post by [deleted] »

asadlionpk wrote: post #43
superfrank wrote: post #42

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.

[deleted]
Post reply on HN