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.

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.

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.

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.

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!

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.