Over the last few months I’ve been experimenting with different stacks for web/mobile development. My goal was to “break free” from depending on Meteor to get things done by becoming fluent in other technologies. However, my conclusion after this process is: Meteor is really hard to replace. So I’d like to summarize my thoughts on this to maybe help people and businesses who are facing the “should I stay or should I go” dilemma with Meteor right now.
Technologies I experimented in this period:
- Apollo + REST (Express and Koa)
Why Meteor is really hard to replace:
We’re in 2019. Private space travels, flying cars and virtual currencies are a reality - so should we still need to struggle to create a simple user accounts system?! The amount of code necessary to get something close to Meteor’s account system up and running on any of the technologies mentioned above is overwhelming - think about all the security, back and front-end aspects involved. Things may look quite easy when you’re thinking about login/signup. But when you add email verification, reset password, enrollment links, social signup and all the hooks to the mixture… oh boy.
I was doing quite well in Firebase until I realized it doesn’t have a full-text search mechanism. What I can achieve in 30 minutes and $0 with the awesome easy:search package on Meteor took me 3 days and $29 / month to get with Algolia + Firebase. Meteor’s pub/subs are awesome to help you filter search results the right way (optimizing performance) - and have no real peer elsewhere.
3) Mongo Integration
Meteor is by nature integrated with Mongo. You can write Mongo code almost exactly as it is in the official documentation. If you switch to Firebase’s Firestore, you will have to use their own Mongo-style syntax… which imposes a lot of restrictions (on querying / mutating) and is overall less clean and intuitive. Firestore also doesn’t have any specific Schema tool (like simpl-schema for Meteor). If you switch to REST with Mongoose, you get your powers back - but at the cost of complexity and lots of wiring around (remember, server and client are in a serious relationship in Meteor, but are not more than acquaintances in REST).
4) Comfy Back-end
In Firebase, you get a “serverless” environment where all your back-end code needs to be written in “cloud functions”. This may be an interesting approach for larger, microservice-based apps, but it imposes a structural restriction that gets quite annoying if your app has a lot going on behind the curtains. In REST, you have all the freedom you want - but at the cost of countless endpoints and plumbing operations. A simple “update this document” method in Meteor can become quite horrifying in REST if you need authentication, error handling and additional features.
Meteor may be too opinionated for projects that have really specific back-end needs and rely heavily on fine-tuning details for performance. Is this your case? If it’s not, then don’t waste time reinventing the wheel just because it looks fancier!
Meteor apps can be really fast if done correctly (controlling real-time data, optimizing methods, using a good front-end library etc.). If your app is slow (and you don’t have a million active users doing heavy stuff on it right now), there is probably room for optimization!
I believe that Meteor is the direction in which dev tech should go. Less time spent doing things that are basically the same for every project (accounts, security, routes, data plumbing) and a solid environment to host your business logic.
That’s it! Would love to hear your opinion on that