Architecting with Loopback
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.
Define models and their base
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.
Relationships
Users ->
Belongs To
- OrganizationOrganization ->
Has Many
- UsersProducts ->
Belongs To
- OrganizationOrganization ->
Has Many
- ProductsCatalog ->
Belongs To
- OrganizationOrganization ->
Has Many
- CatalogOrders ->
Belongs To
- OrganizationOrganization ->
Has Many
- Orders
Sample Queries
Create product for Organization
Fetch product for Organization
Invalid or disabled Queries
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.
Last updated