But Does Meteor Scale?

announce
24

You would need to jump through some hoops to make the reactivity more fine-grained in this instance, since those are all passed in as one data context object to the child template. Splitting up the helpers wouldn’t …help.

One way to do that would be to make the properties of the data context functions instead of properties, or make that data context object a reactive dict, which will make each property individually reactive.

@tmeasday, what do you think? In this case, would it be worth it to split these data sources up to avoid extra recalculations?

By the way, I think this is off-topic, since scaling usually refers to the server side. Perhaps we should start a new thread about Blaze reactivity management.

1 Like
25

Yeah, trying to get around to those when I can. Maybe in March, haha.

26

any plans to add a section on scaling to meteor guide?

27

We’re publishing a blog post about it soon, hopefully that can be followed by a contribution to the guide. If someone has some content we should include right away, I’d be happy to start a new article and add that in there today!

3 Likes
28

No need, I already wrote a blog post that covers what you need: Building your own Meteor Galaxy hosting setup with Digital Ocean. Even gave a talk about it: Build your own Galaxy hosting for Meteor.js - Crater Conf - YouTube

29

So to scale a meteor app, one must build their own galaxy hosting setup? That’s kind of a bummer.

Maybe worth a change of title if the main goal of the article is to show how to scale a meteor app? If I was looking for info on how to scale meteor, I wouldn’t click that article title.

30

Yeah, the article I was talking about that we are going to post soon is about how to use various mongo server-side options to reduce CPU usage on your Meteor server.

3 Likes
31

This is what I need.

32

Here you go: Using MongoDB aggregations to power a Meteor.js publication. I should really write up the post about a running job that updates stats in a compiled collection from aggregations too, quite handy for speeding up data that needs aggregated for reporting.

1 Like
33

An entire article on scaling meteor would be great… the mongo-side of things. It sounds like subs-manager would also be helpful… Use global subscriptions for increased ui-speed?

an entire section of the guide on scaling would be huge (and probably diffuse a lot of concern about meteor)

34

Given the recent roadmap and focus on Apollo, I am not sure we will see such an article. I think DDP has a shorter shelf-life moving forward with MDG.

1 Like
35

this is a good point

36

I want that rite nau!

37

I feel that this question directly implies several additional questions:

  1. how does meteor scale
  2. what options do I have to scale

Indeed, with the sudden retirement of the author/maintainer of both Cluster and mup/mupx one may have additional concerns when even asked about initial production deployments.
The offerings were always somewhat implicitly pointing towards the need for the community to step-up and create solutions.

The documentation suggests a vanilla node js deployment with solutions from that ecosystem for keeping the application running upon system restart or crash.

We had the free Meteor hosting platform until a year ago or so available with an easy “meteor deploy” CLI

We have Galaxy taking on the enterprise side (worth noting that one needs an external Mongo provider and features like IP Whitelisting, such as Atlas offers, are still not supported) also providing similar ease in deployment and scaling with a dial (turn it up for more) and no downtime
(can anyone confirm no downtime with either scaling or code deploys?)

We have unmaintained mup and mupx solutions, which have forked in many directions due to differences in production best-practice ideals and the inevitabilities of SSL/TLS, load-balancing, and reverse proxies.
Cluster integrates with these to some extent.
Docker having been added into the mix has proven controversial, to say the least.
Missing dependencies and the lack of general Docker foo universally, have resulted in mysterious docker image fetishization… (blame should also lie with Node, it’s versioning and breaking changes, and the great leap forward we took with the last meteor version in node and mongo versioning…)

We have pm2 based solutions, but this basically papers over a vanilla node install IIRC…

The agnostic front that MDG seeks to maintain regarding deployment and scaling options is often misinterpreted for a happy conflict of interest in which users are funneled towards Galaxy… (all the magic of the platform and build tool = lots of stuff going on under the hood)

I may be paraphrasing very badly here: feel free to correct as appropriate:
The general issue with mere horizontal scaling is shared state solved by “sticky sessions” “session affinity” and other means of keeping people on the particular box they were on, whilst sharing the load as best as possible.

Cluster was a breath of fresh air, and now…
I haven’t been able to use it in production except for worker auto scaling, due to issues I experience with DNS load-balancing and removal of any of the cluster nodes from DNS resulting in total system failure etc… I’m probably being dumb and not noticing some quorum even/odd issue, but the support isn’t there and the community will move on, as it never really was an active participant but was rather handed a magical gift by a really smart guy who has since moved on…
A project is more than just code. Code doesn’t die or go away. Projects do, as people route around them and their relevance fades (He’s also a flow-router co-author, pun intended)
Brilliance is often succeeded by relevant mediocrity. It’s unfortunate. It’s life.

What I really wish to ask is:
What are some clear paths to deploying and scaling an app with minimal downtime, expenditure, and hair-pulling?

2 Likes
38

Have you looked at Phusion Passenger yet?

39

This topic should probably be updated based upon the new work by @diaconutheodor , no?

40

Yeah if someone can post some links to more recent discussions I’d like to close this thread since it’s almost a year old.

41

It may be a year old, but the arguments @vectorselector is raising are pretty valid, IMHO. I am also quite puzzled about the current situation, given that the key maintainers of mup(x) and cluster are not part of the community anymore.

The solutions Arunoda and his team offered were just awesome, and they worked together more or less out-of-the-box. I get the strong feeling that Meteor’s fragmentation starts to get to a point where it’s a huge number of puzzle-pieces I have to put together, just in good old MEAN stack. I doubt this will really bring Meteor forward.

And yes, I know that I might as well use Galaxy for hosting, but the fragmentation goes far beyond pure hosting. I had lots of a-ha moments just recently when I tried to achieve something and learned that this would require me to replace a vital part of my stack.

42

I completely agree, I just think they would be much better raised in a new thread rather than attaching to this super old one.

3 Likes
43

Yep, you’re right :slight_smile: