I haven’t thought that for a second. I’m here to stay.
3 Likes
100 concurrent users tops? That can only mean you have no idea what you’re doing, for 2 reasons:
- There’s an array of factors that determine the number of concurrent connections you can handle - the app itself doesn’t monolithically determine your ability to scale. 100 is just a random number you chose, right?
- I’m terribly inexperienced with deployment, but have managed to scale a reasonably interactive app to 400 concurrent users using Digital Ocean and Compose.io. This is without clusters (only one of 4 cores utilized), and some pretty faulty design patterns I haven’t been able to fix yet.
EDIT: we barely crashed at 600 
and had to take down the server for a while
do you have any idea what kind of things OPLOG does to your app servers when you scale out? I am talking about real time apps here and i replying to someone who thinks MGD can scale out mongo to millions of users real time
600 users all real time single box ? cool, how much real time do you actually have ?
yea, it’s not data heavy at all 
and can’t say all 600 were interacting. That being said, you’re absolutely right about oplog tailing, but it’s not like we’re going to be stuck with that forever.
Progress on graphQL and Meteor’s data layer will eventually make way for something better. I’m also excited about RethinkDB coming to Windows soon!
I believe MDG announced they would emphasis professional use more in 2016, and that the data-layer is going to be reworked??? Correct me if I’m wrong
i have no idea what they are gona do actually, my point is tho, if you’re app is not real time, then why not go for node.js backend for more flexable data backend? If you need alottt of real time, node.js is definitely not the job for it. That leaves meteor only good for prototyping, because of its fast start. But having to wait 30 sec between file saves is not saving people any time even for small projects
Please, tell me more 
I can’t say I agree, but then again - I don’t really know that much yet anyways.
This also depends on a lot of factors. I’m getting ~5-15, depending on project size.
I think this is where the term “There are Rails developers and Ruby developers” because people get so dependent on packages that they can’t code in Ruby well.
I think there’s a lot Meteor can learn from Rails, especially in package choices (different DBs view layers, etc…), as well as thinking about tradeoffs… adding gem install some-hairball saves you time now but makes it hard later.
I totally agree… I’m getting fairly ‘JS fatigued’ myself and I love to tinker.
You make me worry. I am developing an app for which I am expecting way more than 100 CC users. Does that mean that I have effectively chosen the wrong framework?!
how much of that is pub/sub ? you can hold way more if you only use methods
I’m using pub/subs on each page, but typically only about 1-2 subs per page (using template-based subscriptions).
What are the most important load factors for the server? The number of users, the number of pub/subs per users, the number of concurrent pub/subs per user, the amount of data sent with each sub…?
Do you happen know any good tutorial on how to make your app scalable without loosing reactivity?
You can have way more than 100 users on one Meteor server, you just have to be careful with your publications. Unfortunately we don’t have clear documentation right now on what is and is not performant, but hopefully we will soon.
5 Likes
That’s what I was going to ask, I barely use pub/sub at all unless it’s an obvious use case, both for performance and security. Also I find “methods” is a better way to encapsulate and even document what I’m doing. For instance I’m on the fence about mongo vs mysql in the future of my app due to the extensive need for relationships on fairly large datasets. This approach makes that switch relatively straight forward if I ever need to.
As an aside in all this debate on platform, I’m trying to use Angular2 and finding it quite enjoyable. I have the luxury of using what I like. Blaze is certainly easier but as the application grows and I have to bring more developers in I know there are a lot of Angular developers out there. React seems more limited to find. Also I’m finding Angular2 to perform better than React so that has been on my mind lately.
I’m still new enough with Angular2 that I certainly can’t make general statements about which is better but I’m very happy with it so far. In every non-meteor/ non-react forum I visit it sounds like Angular is the more popular choice but here it’s third or fourth. It’s a really interesting challenge to figure out which and I look forward to learning more from all of you along the way.
As for why use Meteor? I agree with the comments made on this but I don’t think I have heard the obvious issue of writing code once and running in two places. This is not trivial to me. The less code you write the better for maintenance and cost and quality. While you could do this with other packaging solutions I haven’t run across any this intuitive and straight-forward
I know everyone says “choose the one platform/library that’s best for you” but the reality is there will be winners and losers over time and if you pick a “loser” what that means is you will be stuck with less support and less options for rapid development and will be forced to switch.
That’s fine on new work but I have applications I have supported for 10+ years. You don’t get to just restart every time the wind blows. Heck I have an iOS native app I wrote in 2008, still selling on the app store today with zero changes until now when I’m introducing some new features which is doable because of Apple’s support of the platform and the community around it. So these discussions are important to me and choices do matter so I don’t view any logical fact-based argument as right or wrong and I really appreciate the dialog so thank you!
1 Like
Looking forward to this documentation! I think it is urgently needed. When I started with Meteor, I was not aware of the bottlenecks it has (e.g. oplog tailing), and from the tutorials I got the impression that it is pretty ok to use pub/subs heavily. It’s just too tempting 
It would be great if the Meteor guide would take a more “realistic” point of view in this respect, to prevent that developers fall into the performance trap.
Anyway: Could you give please me some first hints what you mean by “being careful with publications”?
3 Likes
Yes, majority of the apps there do not need pub/sub for most of their stuff, even the so called “real time” apps. The only true real real real time apps is only something like messsaging (think WhatsApp). When you need something like that you would want to look for platforms dedicated to real time huge concurrency(elixir/erlang).
But that truly begs the question, that in 2016, if you dont need full real time, if you are using methods over pubsub, if you are using deperate view layer(react, angular) for front end, then why is meteor the right choice besides it is easy to do meteor install?
When meteor started, the landscape was different, nothing was as easy to make as a meteor app, no one had hot reload, no one compiled sass automatically for you without a build tool, no one has pub/sub, etcc…
Now many years later the choices are there because for each of the thing meteor was good, at, there is a group of people dedicated to solve those problems on (npm).
The biggest value proposition for meteor right now is that it is a coherent javascript developing experience. No spending a long time trying to duck tap things together from npm. While also letting you choosing w.e you like from the wider ecosystem.
Thats why I think they are doing a good job with 1.3 module/npm support and the new meteor guide.
But how much of that value(easy to setup and get a project going) is going to matter vs doing it yourself in the future, we have to wait to see.
edit: RethinkDB support is coming i think, that would eliminate a lot of bottleneck with oplog, but still you wont want to use too much real time.
2 Likes
Now that is surprising. I thought pub/sub is what Meteor brings to the table as a core, super duper important feature.
It sure is! Hang tight, we are working on a plan to make this part of Meteor much much more awesome soon, and a big part of that is making performance much easier to optimize and understand.
Data loading is definitely Meteor’s number one feature in my mind, and it’s the thing I’m working on full-time after the Meteor Guide.
20 Likes
Great post and I agree with your points. Also, from a mobile perspective, with Ionic adopting Angular 2 - Angular will make a lot more sense in the greater job market. If MEAN.JS and MEAN.IO adopt Angular 2, you’ll see this penetrate the enterprise a lot more than React imo. Right now adopting React seems like you’ve to glue a lot of different pieces together, much like the npm ecosystem. Wasn’t this what drove people to Meteor in the first place, an all-in-one-solution?
Best news of the day!
4 Likes
you can’t just nonchalantly drop that and not expand upon it! 
4 Likes