Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-tenancy makeLunch #4

Open
richsilv opened this issue Jul 14, 2015 · 6 comments
Open

Multi-tenancy makeLunch #4

richsilv opened this issue Jul 14, 2015 · 6 comments

Comments

@richsilv
Copy link

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
Copy link

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
Copy link
Author

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 [email protected]
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
Copy link

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
Copy link
Author

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 [email protected]
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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants