What problems could arise as the app scales? What could be possible drawbacks of doubling down on Meteor?
Great question! I decided to survey the community and see what opinions are out there. I conducted this survey in December of 2014.
Summary: Despite concerns, the overwhelming mood of opinions regarding the use of Meteor in production is positive. It is not recommended for handling millions of concurrent queries (like Twitter.com).
One of the more comprehensive treatments of scaling Meteor is Arunoda Susiripala's article Does Meteor Scale? and his follow-on article How to Scale Meteor?. He addresses specific issues and concludes elsewhere, "Yes. It scales well, but it does not scale to millions of concurrent requests (awesome+scary moment). But for a medium size app, Meteor is superb."
The one dissenting opinion I found was Nelson Correia's, that Meteor is a nightmare to scale, and while I'm grateful that he shared his experience his specific points didn't scare me.
There is interesting reading in Scaling Meteor: The Challenges of Real-time Apps.
Josh Owens proclaims, "I've been very pleased with how the scaling of Meteor.js works out" and Brent Abrahams exudes, "Despite the challenges with scaling, at present, I don’t think I’ll be building a web app again without using Meteor. The development process was just too sweet. What would otherwise take months-to-years to develop can be put together in a matter of weeks." in Meteor in Production - A Case Study.
I saw a strong concern about using MongoDB (Meteor's chosen database) for, well, anything, in Sarah Mei's Why You Should Never Use MongoDB. My interpretation is that she's really making a case against using any NoSQL database when there's a requirement for making high-performance queries against relational data. To an extent I can agree with that—it's important to use the right tool for the job—and to decide whether the best kind of database to use is relational, document based (NoSQL), or graph. However, there is an opinion that in the world of big data RDBMS does not perform as well as NoSQL and is on the way out.
This concern raised a question for me: If I decided in the future of my Meteor app that I'd like to use a relational database, is that option available to me? Stephen Pope says "yes" in his article Can Meteor and MySQL play nicely together?.
There was a minor concern expressed by Josh Owens about the lack of built-in server-side rendering:
... if you are looking to build an app that serves the same content to multiple people then you might hit a disadvantage because there is no easy way to do server-side rendering. Server side rendering is important to do things like caching the page in vanish or nginx, which makes it much easier to scale a web app.
Arunoda Susiripala comes to the rescue with his Server Side Rendering for Meteor.
Building on the concern above is that websites built with Meteor won't be readable by search engine crawlers (such as Google's) and thus not rank well. The solution is to add the spiderable package. Manuel Schoebel writes, "It is possible to use Meteor and get ranked on google and if you use the mechanisms of Meteor correctly, it is really easy and comfortable."
Varun Vachhar laments that Meteor's client side framework is less desirable than AngularJS:
The client side still relies on old - annoying - ways to build apps. Want to attach a click function to a button...give it a id, use jquery to find that id and then attach a click handler. Whereas, with Angular you just use the ng-click directive and place it in the markup itself. Meteor's Iron router is horrible compared to ui-router. And so on...
In an ideal world I would love to use Meteor as the backend and Angular for the client side.
Zefei Xuan agrees: "Meteor, especially its frontend engine, isn’t production ready yet, and AngularJS is currently the best at this." His approach is to use both, which he claims "has been a godsend" in The Wonderful Duo — Using Meteor and AngularJS Together. There's also a Meteor package to help out with this integration.
Is Meteor production ready yet? Here are some effusive opinions:
We've been doing all new dev with Meteor at my company for over a year. My company ships tens of thousands of orders to tens of thousands of people in 80 countries and we are running mission-critical, revenue generating web applications on Meteor--for since version 0.6. ... For me it's blows frameworks like ROR out of the sky. Meteor is a work of great genius.
We at Differential have been building Meteor apps for startup and enterprise clients for the last 18 months. Meteor is most definitely production-ready.
To pick one example of many, check out Respondly - gorgeous, built entirely on Meteor, and used by great companies like Stripe and Slack to manage their Twitter presence.
At Fingent ( Fingent Corporation) , we have used Meteor for mid sized enterprise projects. So far, these apps have worked very well in production ( reliability, scalability and security).
The answer, as always, is “it depends”. Meteor can certainly be used for real-world apps. Telescope and Sidebar (which is based on Telescope) are perfect examples of it. But Meteor can’t be used for all real-world apps just yet. Meteor doesn’t have server-side rendering yet, so it’s not ideal for sites that need to load very fast (like e-commerce sites) or work on underpowered devices (like older mobile phones).
A Quora question lists over 20 startup companies using Meteor in production.
Meteor is now at version 1.0 and is being used happily by many companies in production. My survey was not exhaustive but I didn't find any conclusive evidence that choosing Meteor for a long-term project will paint anyone into a corner. My recommendation: If you don't need to handle massive traffic nor lean heavily on high-performance queries of relational data then give Meteor a try for one of your next projects and enjoy its many benefits.