Hi, how should you go around using Prisma as multi...
# orm-help
a
Hi, how should you go around using Prisma as multi-tentant source with different microservices in Node.js? For example we have one location database and we have one app for transactinal purposes and one for content. But we want to use the same location db in both apps.
l
Probably have prisma itself in a microservice that can be accessed from different apps? Also, multi-tenant usually means separation of something along some axis (in B2B customers are usually tenants, so you may want to have them separated somewhere). I don't have experience with Prisma 2/3, but have a similarish one with Prisma 1.
i
If your scale warrants a microservice that's a good solution too, however in either case, you'll still need to invoke the
PrismaClient
constructor with a config object pointing at your specific tenant.
You might also consider forking your schema file into three separate schema files:
location.schema.prisma
,
tx.schema.prisma
,
content.schema.prisma
. And then have each microservice manage its own database independently of the others. Assuming all tenants are in lock step version-wise, that is
a
The best case scenario for us would be to have one source of truth for the schema. The tentants will only be our internal mixroservices in the company.
For example, we have one app for core and one for content. Is it a valid solution to keep the schema only in the core app?
i
I don't think I see anything explicitly wrong with that approach, you might run into some irritating scaling problems in the future though. From what I'm hearing, the trick comes down to how you give
location-service
and
content-service
access to the client. If you're in a monorepo, you can cheat and pull the
PrismaClient
from
core
and build it into
location
&
content
. If you're in separate repositories, you'll probably need to have a separate
data-access-layer || data-broker || data-client
module which ends up being just your schema and the client it generates. Then you'd declare that as a dependency among
location
,
content
and
core
. You could also have
location
and
content
declare dependence on
core
, but only do that if there is a gun to your head, that seems bad 😛. You can also still have a multitenant database-server, that hosts separated
location.schema.prisma
in a
location
database,
content.schema.prisma
in
content
database,
core.schema.prisma
in
core
database. This would let you maintain a single database server while allowing everything to vary independently of each other in a bit more flexible of an approach--it means you are not bound to move the
data-access-layer
around as a consolidated unit!
It also isolates and encapsulates your data, making it so
core
cannot cheat and take things from
location
without asking
location
first, and vice versa. If that's why you want SSOT, you may run into situations where you're not truly "microservice", and where scaling will make you cry at night 😕 And finally, I agree 100% with Lars, multi-tenancy in my experience refers to partitioning data storage on a per-customer basis.
a
Thanks a lot Ian for the explanation. Yeah it`s correct it will not truly be microservices to 100 % with this sultion. This is only internal data storage and accessing.