Live data from Hacker News

Why I’m dumping Firebase for Web

lugassy.net

121–123 of 123 posts

Re: Why I’m dumping Firebase for Web

#121
A great blog post.

I feel that Firebase has a lot of services - and one should seriously consider what you are getting for the cost too.

Firebase Authentication - Basically free. You can pay for something like Auth0 and use the Firebase Admin SDK to add Firebase Users on authentication through Auth0 then let that service be your source of truth. Alternatively, you can spin up your own auth service on a firebase function using Passport.js and, again, roll your own solution.

Firebase Hosting - Pretty solid. Nothing crazy great and nothing crazy bad. Easy to deploy and host static files to the edges.

Firebase Database - What firebase needs is a proper NoSQL, but you can get that in the Google Cloud Services. As a Real-time layer for clients, it is pretty good. Not so great if your corporation is on AWS. But, there are options (like deepstream.io) that might require a bit more setup work. How long until every cloud provider has a real-time data layer offering though? Firebase won't hold this space forever.

Firebase Functions - Now, there are a number of comparisons around the functions vs AWS, Azure, etc.. Functions are what they are and they all perform better/worse in various ways. Deploying Firebase Functions is WAY easier than spinning up Lambdas. That said, The Serverless framework makes that much easier too... Serverless actually supports many cloud providers.

If you want to have a real-time app, Firebase, Deepstream, SocketCluster, etc... None of those should probably be your "core" database anyway. They are all great data-sync solutions.

I think that people using Firebase should be aware of growth paths and if they think they will need a feature, build for it. Abstract your code so you can move away from Firebase or extend it with other services. Treat the Firebase Database as the handy real-time layer, but consider storing your data in a proper database elsewhere.

Remember, you can do a complex query in another database and then use the ID results to point the client to Firebase records to sync to (for instance). This, of course, applies to other solutions too. Heck, Deepstream provides RPC calls so you can make those queries then subscribe to your results (if you need real-time results).

Re: Why I’m dumping Firebase for Web

#122

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…

on rereading my comment, I realize I was ambiguous. I meant that phoenix channels was the only multiclustering solution or websockets that has long polling support.

I can definitely appreciate the additional complexity of supporting the fallback. I imagine that elixir's OTP and STM functionality lowers the bar for handling the extra state management across multiple nodes.

Re: Why I’m dumping Firebase for Web

#123

Earlier quoted context omitted.

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

Nah, just query for as many levels as you think you might need up front.
Post reply on HN