search

tableflip / makelunch

:hocho: Who's cooking?
1 stars 1 forks source link

Multi-tenancy makeLunch #4

Open richsilv opened 9 years ago

richsilv commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/tableflip/makelunch/issues/4#issuecomment-121180989.

liamwooding commented 9 years ago

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 commented 9 years ago

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 https://github.com/tableflip/makelunch/issues/4#issuecomment-121186985.

liamwooding commented 9 years ago

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 commented 9 years ago

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