Why I won’t recommend Meteor anymore

A little bit about Meteor

Meteor is a full-stack JS framework (client+server) which is composed of cutting-edge libraries like:

• Blaze: rendering (HTML with Handlebars syntax) & reactive engine (with Tracker) with virtual DOM
• DDP: socket based messaging protocol to make your app talk live with your server in both directions and avoid writing API endpoints
• minimongo: client-side database with a MongoDB API to cache and query data for your views

It also allows you to write sync NodeJS code on the server-side thanks to Fibers (avoid callback hell) and update your view in live when the database state changes.

Meteor brings the best UX with minimum efforts, and it’s like magic.

The downsides of the magic

The easier it is to start with a full-stack framework, the faster you hit a wall when your app becomes more specific.

Authentication

To authenticate a user on your app, Meteor provides an “Account” package that handles things over DDP, security, sessions revocation, reset password, links etc…

This lib is well done, but:

You can’t authenticate a user if the client is not talking over DDP which is really bad when you want to provide API endpoints to your customers.

App shutdown

There is also no mechanism to do a graceful shutdown of the server.

If you have transactions running when you restart your server, you are dead.

Subscriptions scalability

To access your data on the client-side, you have to subscribe to your MongoDB collection. The Meteor server then tails the MongoDB oplog to detect changes and pushes the new data to the client.

It works, but it’s not clear what would happen if you observe too much collections/fields at the same time and you have a heavy write load.

How much CPU would it takes to observe thousands of writes per second ?

Server-side rendering for SEO

Actually server-side rendering is not officially supported, you can use a community package but it’s still a hacky way.

Do we need that much magic ?

What makes Meteor cool is the way the view updates itself live and you get rid of HTTP roundtrips to receive fresh data.

But few applications components really need live updates via socket, if you don’t write a messaging app it’s ok to refresh your view every 15 secs via an HTTP roundtrip.

Meteor is sitting on the fence. When you don’t need live updates, Meteor is overkill. But if you build a messaging app that needs live update, then Meteor is too constrained and has too much overhead, and you need a more specific stack.

Similar UX without Meteor

Rendering

The Blaze rendering engine can be replaced by React, which also is a better way to tie logic with the view, is going native on iOS and can render HTML on server-side for SEO.

Live updates

Components of your app which really need live updates can use a Sockjs implementation with a scalable pubsub engine like Kafka, Google Pubsub, AWS SQS etc…

Advantages

• You choose your authentication strategy
• Your server can gracefully restart
• You are not tied to MongoDB
• You can change your frontend or backend technology easily in the future

Conclusion

Meteor is a great framework for web developpers who want a state-of-the-art UX but don’t care much about data integrity and don’t want to create their own stack.

But if your app needs to expose API endpoints with authentication, don’t mess running transactions when restarting the server and be more resilient to embrace incoming technologies (like React Native, new databases…), you will be stuck with Meteor.

Special thanks to @ngrilly for typos verification and writting recommendations.

Thanks to @arunoda some reactions to this article are discussed in the Meteor forum.