Multi-tenancy makeLunch

[richsilv]

Allow multiple makelunch instances to exist concurrently, with users able to correspond to an eater in several different instances.

Rather than filtering data at the app level, we should have one central app handling login and recording where a user has eater docs relating to them (e.g. mobile.makelunch.com). This then sets the DDP connection to the subdomain relating to the chosen eater (e.g. tableflip.makelunch.com), from which all the relevant eater data is gathered.

The only complication is that we would also need a full webapp to be server from the subdomains (e.g. tableflip.makelunch.com) for web users, meaning that we'd need a reverse DDP connection back to the central app to allow the user to log in.

[liamwooding]

Seems like a complicated approach? If we do the filtering server-side then it shouldn't place any extra strain on the client, we could have named collections for each sub-Makelunch and connect to them based on our current route, like:

Meals = Meteor.subscribe('meals-' + router.subdomain)

[richsilv]

Agreed that it's way more complex in the short term, but what happens when
MakeLunch gets huge? All sorts of scaling problems are resolved by having
separate instances.

I'm not suggesting this will seriously happen, but it seems worthwhile to
build it on that basis as I think it's a better model for clients. FWIW,
we essentially applied your approach to Jimmy Tidey's LocalNets project and
it worked very well (with ~10 concurrent instances).

On Tue, Jul 14, 2015 at 10:39 AM, Liam Wooding notifications@github.com
wrote:

Seems like a complicated approach? If we do the filtering server-side then
it shouldn't place any extra strain on the client, we could have named
collections for each sub-Makelunch and connect to them based on our current
route, like:

Meals = Meteor.subscribe('meals-' + router.subdomain)

—
Reply to this email directly or view it on GitHub
#4 (comment).

[liamwooding]

Your way's definitely better when it gets large-scale, but I'm uneasy with the idea of spinning up a new server for every instance when each instance will have at most <100 total users. I feel that we should be working on the assumption that Meteor can handle being a webserver. My approach is probably naive but I'd still rather limit it to one instance and look at spinning up more when we get into the thousands of users.

[richsilv]

Doesn't need to be a new server, just a new instance, so we can have plenty
of instances per server.

However, you do raise a good point - is it worth running several Meteor
processes on the same server when each has minimal traffic? The overhead
seems pretty massive.

On Tue, Jul 14, 2015 at 10:54 AM, Liam Wooding notifications@github.com
wrote:

Your way's definitely better when it gets large-scale, but I'm uneasy with
the idea of spinning up a new server for every instance when each instance
will have at most <100 total users. I feel that we should be working on the
assumption that Meteor can handle being a webserver. My approach is
probably naive but I'd still rather limit it to one instance and look at
spinning up more when we get into the thousands of users.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[liamwooding]

Yeah that's what I'm thinking - save the planet and all that. I think that Meteor is designed to be a webserver and we should treat it as such, and if it really can't handle thousands of users then we should look at a different tech. Seems like we should do a bit of reading around this as, like many Meteor things, the solution is probably not intuitive.

[liamwooding]

And yeah, I was saying server when I meant instance.