Loopback: Multitenancy for loopback

[nitaigf]

Bug or feature request

• [ ] Bug
• [x] Feature request
  

  Description of feature (or steps to reproduce if bug)

It would be interesting the possibility of creating datasources single or multiple tenants on the same database, this way would be possible to situations such as:

• A single application for multiple companies, where each tenant would be the set of tables relating to the modules contracted by each company, without interference in the others.
• Access to more than one tenant at the same time - one public and one's own company.

In the case of postgresql you can define a schema is a tenant, but in the case of mysql has to be a bank for tenant. Therefore, this functionality would affect the existing connectors.

Expected result

The operating result could be similar to the GEM Apartment Rails.
https://github.com/influitive/apartment

Another nice example is the Oracle 12c - http://www.oracle.com/technetwork/database/multitenant/overview/index.html

Or App Engine Java for Google Cloud - https://cloud.google.com/appengine/docs/java/multitenancy/?csw=1

Additional information (Node.js version, LoopBack version, etc)

Node 6.9.1
Strongloop 6.0.3 / Api Connect 2.3.10
Strong-PM 5.2.3

[superkhau]

There is some WIP that has been delayed for awhile at https://github.com/strongloop/loopback-multitenancy

[nitaigf]

I read that also has another POC project here in strongloop - https://github.com/strongloop/loopback-multitenant-poc which deals with the same subject. I'll see them, but would like an official version :-)

@superkhau I thank you very much for the tip and I will study it for sure.

Some articles I found very interesting about it are these:

• https://www.ibm.com/blogs/bluemix/2016/07/building-smarter-supply-chain-developer-journey-loopback/
• https://github.com/stavinski/loopback-example-multitenancy (by @stavinski)
• https://github.com/strongloop/loopback/issues/1279 (response from @chadjoseph)
• https://github.com/paulomcnally/loopback-example-multitenant (by @paulomcnally)
• and of course https://libraries.io/github/strongloop/loopback-multitenancy (by you @superkhau)

[nitaigf]

For those who are new like me on the subject, but need this functionality, read on:

• https://msdn.microsoft.com/en-us/library/aa479086.aspx
• https://en.wikipedia.org/wiki/Multitenancy

[nitaigf]

Some friends have told me can do multi-tenant on loopback (as in the examples cited above and @superkhau contribution) but always lose something, be the explorer, such as integration with the ARC or other great features of this loopback environment.

As already mentioned before, I am new to Node, Express, Loopback, but I want to learn from this process and maybe one day to contribute to the community that is very active in this project.

I would like to know the opinion of @ritch, @tj, @ry, @bnoordhuis, @isaacs, @seanbrookes, @anthonyettinger, @raymondfeng, @1602 and @bajtos on the subject, as they are also closely linked with projects like strongloop, loopback, express and node. In addition to the expertise they have in this ecosystem.

[stefanomartins]

Searching the Internet for that feature, I saw some posts that recommended the use of several Docker containers, one for each tenant. Personally, I don't believe that's manageable, and walks away from the concept of multitenancy. The multitenancy feature on StrongLoop would be a great addition to the project.

Best regards!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joincamp]

Thought I'd add my two cents here so I can share the strategy that has been successful for us:

For any model that should be seen only from one organization's perspective, we have a mixin that hooks everything.

• before **: determine the user's organization from a signed cookie or the database, and add it to ctx.args.options.organizationId so it is available in hooks
• observe access: set the query filter _.set(ctx, ['query', 'where', 'organizationId'], organizationId)
• observe before delete: same as access
• observe before save: if a new object, set the organizationId from our context into the data being saved. This keeps people from writing data outside of their organization.
  (ctx.options.organizationId). If an existing object, check whether the user's organization is the same as the object.

The before save is the hairy part of it, and required a lot of checks to be set up before I was confident that a user couldn't do anything outside of their org.

We also do some role checking, where a super user just calls next() right away, etc.

I'm ambivalent about the quality of this solution, but it does work and the performance implications aren't terrible. The security implications are probably fairly severe however, and I wouldn't trust it in the wild without some serious engineering.

[drmikecrowe]

@joincamp -- we're interested in a similar solution. Could you share a gist of the relevant code for illustration?

[joincamp]

@drmikecrowe Can we talk outside of here? I wouldn't consider my solution "community-ready", so I'd prefer to share in private.

[drmikecrowe]

@joincamp Got it, thanks many

[jeff3yan]

@joincamp I'd be really interested to take a look at your implementation too

[igbenic]

I created a POC with tenant with multiple users, each tenant with it's users per database. I ran a test with 10 tenants, each with one user, each user created one new Note model instance. Loopback(node in general) seems to prioritize queuing requests over handling them as it's non locking, and I think this is the main problem when dynamically switching data source with attachTo. Resulting Note model instances were all over the place. I assume they were saved in the currently active datasource on Note model and the correct datasource where the Note should've been saved is long gone when the request is actually being handled.

I'm still looking for a feasable solution, is it possible to setup loopback to handle per request datasource? Maybe a custom connector with connection options when executing a query?

[igbenic]

If anyone is interested, it's possible to create multitenancy using schemas in postgres that does not fail concurrency tests. I check for access token on each request and fetch tenants schema name from a single master DB. When I have the schema name it's attached to ctx.options and ctx.args, in this way I can read options.schema in execute function in sql connector and switch "public" schema in sql statement with it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

[hoangtrongphuc]

@joincamp Can you send me your code about this issue ?

[joincamp]

@hoangtrongphuc Sure, I invited you to my repo.

[hoangtrongphuc]

I'm not get any notify about your repo, you can send me : dr.[email protected]

[paulomcnally]

This script allow multitenant (postgre schema based).

http://subdomain.domain.com => set subdomain schema in every model. Need edit model-config.json to add "tenant": true

{
  ...
  "MyModel": {
    "dataSource": "db",
    "public": true,
    "tenant": true
  },
  ...
}

https://gist.github.com/paulomcnally/0fea84f0c5ed7fce70fd26d134c65c5f

[sacarino]

@joincamp, does the offer to share your concept still hold? Would be interested to see what you came up with vs. what we bolted together here.