Architecting with Loopback
Last updated
Last updated
We define loopback models for achieving multi tenancy, such that every Model
passes through organization model and the data accessible is only specific to particular organization.
We restrict access to all direct methods for each model and only make them accessible through organization model. This way, only org specific data could be returned.
In loopback when you create a model with the model generator, you choose a base model, that is, the model that your model will “extend” and from which it will inherit methods and properties. Read more about models
Since user
model is the most restrictive and protected model, it is difficult to hack into unauthorized data, we chose it to be the base for our organization model.
Also the concept of $owner
ACLs only works for user
models and its inheritors, so that is a huge technical reason for picking this model as well.
Users -> Belongs To
- Organization
Organization -> Has Many
- Users
Products -> Belongs To
- Organization
Organization -> Has Many
- Products
Catalog -> Belongs To
- Organization
Organization -> Has Many
- Catalog
Orders -> Belongs To
- Organization
Organization -> Has Many
- Orders
Create product for Organization
Fetch product for Organization
Following samples will give 401 Authorization Required
error as these should be disabled from the backend.
Create product for Organization
Fetch product for Organization
Why? Remember, earlier we decided to:
restrict access to all direct methods for each model and only make them accessible through organization model. This way, only org specific data can be returned.
To read more about how to disable methods in loopback you can refer to this article.