Is Meteor suitable for large applications?

I don't want to keep you in the dark for too long, so here is the long story short:

Meteor is more than suitable for large applications.

Examples like MaestroQA, aleno and many more can prove this. There is no technical or fundamental reason why you can't make an extensive application using Meteor.

If so, why can you find on the Internet many voices that Meteor is unsuitable for such use cases?

In my opinion, this belief stems mainly from one of two causes:

Let's dissect both of them separately.

This is simply not true but instead a very popular myth. Where did it come from?

I think the myth arose because, unfortunately, it is quite easy to write an app using Meteor in a way so that it won't scale.

This is not due to the framework's limitations nor strictly a tool's fault. You can also write an inefficient app using C or C++. Still, it does not mean that those are inefficient, "not scalable" languages. It is up to the developer to leverage each solution's possibilities and make maximum out of it, depending on the situation.

Why is it so easy to write code that does not scale using Meteor?

One reason could be that Meteor is often targeted toward beginning developers and MVPs. It has a very gentle learning curve, and the tutorials/guidelines you meet at the beginning of the adventure focus on easy-to-write code and simple cases. And those may not scale so well later. Even though there are efficient alternatives, they are often skipped due to simplicity.

Another even more important factor is unrealistic expectations. If you upload to MiniMongo 50MB of live data through dozens of real-time subscriptions, you will have a hard time if thousands of people try to visit your app at the same time. But no framework/solution can handle something like that out-of-the-box. Yet still, people expect that those nice real-time features that work great on a small scale will do the same on a huge scale. And at the same time, nobody even expects such results from alternative solutions.

But you can write applications in an educated way, using fewer bells and whistles that Meteor gives you. Maybe not all subscriptions must be real-time. Probably fetching static data via methods is enough for a significant part of your app. You can go with Meteor very far when you know the opportunity costs of technical decisions and have specific traffic targets you want to achieve.

There is however one notable exception - the limits of MongoDB itself. Since Meteor does not support sharding, we are limited by the replica set members limit. Fortunately, this is more than sufficient in practice, even for very large apps. And at this scale, you would have probably dropped the default MongoDB oplog in favor of a Redis-based alternative, which could also solve the sharding issue in the future.

Ok, this one is most often true. While writing apps based on Meteor as services or microservices is possible, this is rarely done in the wild.

This is not always a problem, though. We would need to enter the monolith vs. microservices discourse, and I don't want to sidetrack too much. But my key takeaway is that many apps use microservices without really needing them. And many of the now-famous microservice-based applications started as a monolith. And they would never grow to what they are today if they didn't do so.

Building your app and core product as a monolith is not a downside. Most often is the opposite. You can save yourself data consistency and many DevOps problems.

Yes, there is a scale at which using microservices would probably be a better choice. But I'm convinced that most people who think they need microservices are not there yet, and would be better with a monolith.

Check out this and this article if you want to read more or need to make an informed decision about whether you actually need microservices or not.

So to wrap up: Meteor's curse is that it works so well for small apps that people expect it to perform precisely the same for large ones without any changes or considerations. But that is simply not true regardless of what technology you will use.

Maybe Meteor should do a better job of preventing developers from shooting themselves in the foot? In my opinion, this should not be at the expense of the fantastic developer experience. Instead, it could explain more about the costs of each decision. Bells and whistles will always come with a price, and it should be a conscious decision whether to pay it or not.

If in doubt, you can always use help from Meteor consultants at Vazco. We have been working with Meteor for 10 years and have made many large apps in the process. We are happy to share that knowledge and help anyone who wants to give it a go in a larger application.