Ejja-Ha-Nieklu / ejja-ha-nieklu

🌽 🍠 "Ejja Ħa Nieklu" is Maltese for "Let's Eat."
http://ejja-ha-nieklu.herokuapp.com
0 stars 4 forks source link

Multitenancy support #25

Open camilleriluke opened 8 years ago

camilleriluke commented 8 years ago

Motivation

Currently the whole application supports one client (which is all the users). All orders are shared with all the users of the application. This might have been good enough till now, at the same time it believe that there is potential to scale this concept.

The idea is allow clients (companies) to create a realm in which all the orders are shared only within that particular realm.

Suggestion

How we do this is up to discussion, but here are a couple of suggestions I have.

KPull commented 8 years ago

Can you explain a bit in more detail what this is about?

camilleriluke commented 8 years ago

Updated issue description

KPull commented 8 years ago

We can do the following right now without code changes: Have a NodeJS instance for each different tenant we want. Then, using a different startup script, we configure each instance to use a different database (possible on the same Mongo instance). Finally, for the subdomain, we'll need some DNS trickery (with optional port redirection if the NodeJS instance is on the same computer) or maybe a gateway tool.

Additional ideas: We can then create a separate application (which we'll call the "registration" tool) which does all the above automatically. In this way, EĦN would need very minimal code changes and concern itself with organising food orders. Also, the "registration" application can be kept secret if we really want to and have people pay for their deployments.

KPull commented 8 years ago

You can take this even a step further and have the "Registration" application not even be tied down to EĦN. You'll be able to deploy any number of instance of any NodeJS apps hint hint.

camilleriluke commented 8 years ago

Have a NodeJS instance for each different tenant we want

The idea is not to have multiple instances (less instances less maintenance, less deployments), but rather one instance which can hold multiple clients.

Then, using a different startup script, we configure each instance to use a different database (possible on the same Mongo instance)

Configuring different database is an option (however we need to check the support for this with the provider), also we can consider having different set of collections for each tenant

Finally, for the subdomain, we'll need some DNS trickery

I believe that this can easily be achieved with either haproxy or a simple nginx proxy which will redirect to EHN.com/cactuscorp-uid/common/url

Also, the "registration" application can be kept secret if we really want to and have people pay for their deployments.

One of the goals of this project is to run it as an open source, we need to keep in mind that all the code base is publicly available and therefore almost nothing can be kept secret :v: