Would you go with Meteor or Firebase for the real time feature of your application?
54 votes · Closed
Would you go with Meteor or Firebase for the real time feature of an application
Meteor is a good tool for prototyping or writing very small apps quickly. But has a lot of downsides that I explained here: medium.com/@pierrebaz/why-i-won-t-recommend..
Firebase is composed of many building blocks:
- the free HTTPS hosting & deployment is awesome
- the JS file uploader to Cloud Storage is incredible
- the authentication layer with custom JWT is a must have
- the cloud functions with custom endpoints are the new PaaS
- the realtime database is maybe not what you are looking for: you can't apply complex filters on your queries, thus you have to denormalize your dataset to be able to query it in an efficient way. I would personnaly recommend to use the realtime database for simple use cases (chat...) & to trigger HTTP roundtrips to your real DB for your complex queries.
In a recent project, I use the realtime firebase DB to watch timestamps of updated objects; like a frontside "pub/sub". Simply put: every time the backend updates an object it updates a timestamp in Firebase, and then the connected clients who are watching it know they should trigger an HTTP roundtrip.
I'd go with GraphQL subscriptions and web sockets. I personally think Meteor is great for quick prototyping, but it's not suitable for production environments. Firebase would be a great alternative, but I think GraphQL subscriptions give you more control.
GraphQL allows third-party developers to tailor their requests, which is great for saving roundtrips, but leaves the hard work to the backend developers writing resolvers.
Resolvers create dynamic DB queries, which introduces a lot of edge cases / bugs / security issues and bottlenecks.
Unless you are a B2C giant like Twitter or Facebook, GraphQL is 100% BAD for your stack.
Regarding Meteor, I share your opinion.