Live data from Hacker News

Why I’m dumping Firebase for Web

lugassy.net

101–110 of 123 posts

Re: Why I’m dumping Firebase for Web

#101
post #59

Earlier quoted context omitted.

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?

Hello. The JSON dump looks something like this: { users: { "userid1": {...}, ... }, ... } I have tried jq stream parser to split the big dump into files like: - users.json - chatrooms.json - ... So I can then work on individual nodes. But jq fails silently after 12-24 hours of processing. I am still researching this in free time. If I can just get the keys (like "userid1") I can do the rest from firebase itself.

I would think something like this would work:

  cat input.json | jq -c --stream '. as $in | select(length == 2 and $in[0][0] == "users") | {}|setpath($in[0][1:]; $in[1])' > users.jsonlines
Output would me a file that looks like this:

  {"userid1":{"name":"user1"}}
  {"userid2":{"name":"user2"}}

Re: Why I’m dumping Firebase for Web

#102
I'm surprised that nobody has mentioned yet how slow Firebase can be. Especially updates via the REST API can take upwards of 1 second. And that is for a really small database of a couple MB at most (and the updated value itself being a tiny string).

I really don't know what they are doing, it seems they have made all the wrong decisions engineering-wise. I sincerely hope some team at Google is really busy right now rewriting everything.

Re: Why I’m dumping Firebase for Web

#103

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.

You misinterpreted my comment on purpose. I didn't say "it was a startup, so it's ok" I said "it was a startup, so the same people who built the service did the marketing".

Also, Google's Firebase acquisition was many things, but not an acquihire.

Re: Why I’m dumping Firebase for Web

#104
post #59

Earlier quoted context omitted.

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?

Hello. The JSON dump looks something like this: { users: { "userid1": {...}, ... }, ... } I have tried jq stream parser to split the big dump into files like: - users.json - chatrooms.json - ... So I can then work on individual nodes. But jq fails silently after 12-24 hours of processing. I am still researching this in free time. If I can just get the keys (like "userid1") I can do the rest from firebase itself.

You could loop through the file counting braces, storing line numbers. Then split the file along those line numbers. The smaller files might not have the exact formatting you need to run through a parser, but you should be able to manually adjust it then, hopefully.

Re: Why I’m dumping Firebase for Web

#105
post #101

Earlier quoted context omitted.

Hello. The JSON dump looks something like this: { users: { "userid1": {...}, ... }, ... } I have tried jq stream parser to split the big dump into files like: - users.json - chatrooms.json - ... So I can then work on individual nodes. But jq fails silently after 12-24 hours of processing. I am still researching this in free time. If I can just get the keys (like "userid1") I can do the rest from firebase itself.

I would think something like this would work: cat input.json | jq -c --stream '. as $in | select(length == 2 and $in[0][0] == "users") | {}|setpath($in[0][1:]; $in[1])' > users.jsonlines Output would me a file that looks like this: {"userid1":{"name":"user1"}} {"userid2":{"name":"user2"}}

I think I have tried something similar. I will try this one too. Thanks a lot!

Re: Why I’m dumping Firebase for Web

#106
post #91
post #76

Earlier quoted context omitted.

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.

good old mysql. it is the cockroach of software.

Re: Why I’m dumping Firebase for Web

#109
I have clients with apps that are pushing the boundaries of Firebase. I have strongly suggested the move to Azure or Amazon "serverless" - Azure Functions or Amazon Lambda. I get strong pushback due to "cost and complexity" concerns. I respond that of course "real" development and operations is going to be more complex and expensive than the "toy" proof-of-concept they build with Firebase. But this has been an issue in my career for decades - users get hooked on on RAD tools (Rapid Application Development) and are then shocked that adding "10% more features" will add 1000% to the cost.

Re: Why I’m dumping Firebase for Web

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

Well today I learned a couple things. Thanks for the example and ideas.
Post reply on HN