Alfred Noland
02/24/2022, 3:15 PMLars Ivar Igesund
02/24/2022, 5:01 PMIan Ray
02/24/2022, 7:06 PMPrismaClient
constructor with a config object pointing at your specific tenant.Ian Ray
02/24/2022, 7:10 PMlocation.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 isAlfred Noland
02/25/2022, 12:28 PMAlfred Noland
02/25/2022, 12:33 PMIan Ray
02/27/2022, 2:30 AMlocation-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!Ian Ray
02/27/2022, 2:51 AMcore
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.Alfred Noland
02/28/2022, 7:59 AM