23 ms·
From my experience (a.k.a tried and failed..), I'd rather take a bit more time to glue a few amazing open-source tools together than to use an "all-in-one" fram
by d0m 9y ago
From my experience (a.k.a tried and failed..), I'd rather take a bit more time to glue a few amazing open-source tools together than to use an "all-in-one" framework that will screw me down the road.
Over the years, I've built the equivalent of those real-time systems using postgres, redis, rabbitmq and node that can scale horizontally. It's obviously longer than using firebase, but at least I know what's going on under the hood, I can easily optimize and debug it, I can add any missing features or switch any tools (I.e. can easily switch off postgres to something else if I needed it).
It's for the same reasons that I use React on the front-end. It's great for the view layer, but I still get to pick and use great libraries for the rest of the app (in-memory database, state management, routing, etc etc.) I can easily switch off React to something else because the surface API that I'm using is extremely small.
I would still use meteor or any of the competitors for a hackathon or prototype, but never for a long-term project. YMMV