11–20 of 27 posts
This is quite nice. Before we ( https://www.tesla.im ) switched to Firebase we had (still have) our own realtime system built with NodeJS, Websockets, Amazon SQS (as backup to ensure messages don't get lost) and a RIAK cluster.
This is quite nice. Before we ( https://www.tesla.im ) switched to Firebase we had (still have) our own realtime system built with NodeJS, Websockets, Amazon SQS (as backup to ensure messages don't get lost) and a RIAK cluster.
Just to clarify things a bit; our setup worked fine. The only reason we switched to Firebase was, being a small team, we didnt want to maintain all those servers.
> (As an aside, it seems that it would work most of the time in most of environments that I'd try, but for some reason, it rarely worked in one). So I needed to find a new solution. 'Instead of debugging the one environment, I'll just reimplement the entire service!' Obviously. :-)
Well, it might also have something to do with money or control, as Firebase is SaaS, and this solution is open source software. https://www.firebase.com/pricing.html
Earlier quoted context omitted.
Well, it might also have something to do with money or control, as Firebase is SaaS, and this solution is open source software. https://www.firebase.com/pricing.html
As an aside, what happens with FireBase when you need more than 30GB of storage in a single app?
Earlier quoted context omitted.
As an aside, what happens with FireBase when you need more than 30GB of storage in a single app?
You switch to the Inferno plan (scroll down! :P) and then on to Enterprise plans (or just pay overages, though I'm not sure if they apply to disk?)
Regardless, I still find the potential lock-in costs and issues incurred with a proprietary datastore like FireBase to be a total and complete deal breaker.
For truly production-grade systems, relinquishing control over your data stores does not seem like a viable path to better reliability or control for any business with significantly large swaths of data.
If there were a compatible open-source equivalent with easy import functionality for a FireBase dump, I'd be singing a different tune.
Am I missing or overlooking something here? I get the use case for a small project or app, but for mission-critical production, it doesn't seem like a good idea.
Pretty cool project! I remember the pleasure I got out of (partially) re-implementing the Pusher API. I wonder why real-time features aren't more popular? Real-time order status, live-updating maps, the list goes on!
I don't want to sound negative towards you project, but why not use CouchDB [0], along with TouchDB [1] for mobiles and PouchDB [2] for the browser ? [0] https://couchdb.apache.org/ [1] http://touchdb.org/ [2] http://pouchdb.com/