Live data from Hacker News

Why I’m dumping Firebase for Web

lugassy.net

1–10 of 123 posts

Re: Why I’m dumping Firebase for Web

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

Re: Why I’m dumping Firebase for Web

#6
post #2

What are you moving to as an alternative?

I think AWS is the all-purpose fallback. It has some turnkey solutions for some problems of various quality, but you can always just use EC2 with custom code. S3 is a miraculous product. Lambdas are pretty cool. You can try your hand with DynamoDB, but RDS is there for you too. There's generally much less lock-in.

Re: Why I’m dumping Firebase for Web

#8
post #6
post #2

What are you moving to as an alternative?

I think AWS is the all-purpose fallback. It has some turnkey solutions for some problems of various quality, but you can always just use EC2 with custom code. S3 is a miraculous product. Lambdas are pretty cool. You can try your hand with DynamoDB, but RDS is there for you too. There's generally much less lock-in.

I've thought about Cloud Functions but Lambda may be better.

Re: Why I’m dumping Firebase for Web

#9

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 reasons for this. Both SC and Deepstream used to support HTTP long polling fallbacks via engine.io in the past but both projects independently decided to stop doing it after years of experimentation and feedback.

Now that WebSockets are well supported in all major web browsers and HTTPS has become even more prevalent (so corporate proxies are no longer a problem), the extra load balancing complexity, performance costs and the DoS vulnerabilities of long polling are no longer worth it.

Post reply on HN