Any one using prisma in a multi-tenant setup?
# orm-help
l
Any one using prisma in a multi-tenant setup?
l
not yet but planning to do so
j
I’m trying it right now
l
How are you guys solving it? Shared db or one db per tenant?
j
l
How many tenants do you expect to get? And how do you deal with migrations? Do you keep a separate prisma.yml file per tenant?
j
i’m in very early stage for this, far from being production ready. We have several clients using an app from us, and the goal is to set one db per client
no need for separate prisma.yml
i’m using env vars
i
all i really want in this regard is composed indexes, so instead of going with real separation i'm using one db atm, with a few slower queries in the meantime -- i'm guessing they're in the roadmap.
l
Do you just do something like
({ where: { tenant_id: "1234" }})
on every query or have you figurer out a nicer way? Tried using row level restrictions in the dB?
@iago ?
i
hmm so i kind of modeled around my "tenant" domains. every login i check
where { email, domain }
i store permissions along with the user in redis
and then everything else runs fast
permissions and the "tenant" ofc
slower login but the rest runs normally. i didn't need separate dbs, so i figured this would be more practical
since there's no compound index i need to scan the whole collection, that was my tradeoff, which i hope is temporary
l
for me it's gonna be a shared DB and an extra table "tenant"/"company" or whatever, because they all have a similar layout. and for the tenant_id, I guess you could send this as a header maybe to prevent a separate sql query (not sure yet tho)
i
you probably want to check the tenant on the server, to avoid malicious usage
l
ofc, I mean send the tenant as header from the client and then you can check/verify in a middleware on the server (which actually doesn't save a query I just realized, it just saves you a graphql level)
l
@iago do you pass the tenant to the resolvers via context and get all other models thru the tenants relationships, instead of the prisma client?
i
i store whatever info i need constantly in the session. that includes the tenant relationships, yes. in my usecase i actually store the org that the user belongs to, and the org in turn belongs to a domain (my tenant-ing need). session in context -> gql-shield -> resolvers
i store those in the session merely because it takes a table scan to get to them, and that's only because there are no compound indexes yet
i do all this through the prisma-client
(all relating to mongo that is)
l
Interesting! It's not open source by any chance..?
i
it's not lol. but what do u need?
l
😁 could you give me an example of what a query resolver? Let's say the tenants are a e-commerce ships and you need to fetch all the products..
i
i'd use the domain your webserver gets in the { where } basically
that's about it
isn't it?
l
Oh I get it ! Thanks
i
just a thought... if you're using mongo i think that relationship should be on the side of the shop/domain. i dont know if the side you query them from makes a difference (@Harshit ?). e.g.:
db.domain({ domain:'<http://myshop.com|myshop.com>' }).products()
@Lars-Jørgen Kristiansen
h
yes, that might work but it depends on your datamodel and use case
i
but does prisma trigger the same queries on mongo?
db.domain({ domain:'<http://myshop.com|myshop.com>' }).products()
===
db.products({ domain: {domain:'<http://myshop.com|myshop.com>'} })
?
h
yes you will get the same results
i
and the same performance?
h
I will prefer the second for perf
i
ah, i see. very good to know. thanks! 🙂
oh wait. the second? assuming the link is on the domain side?
i'd expect otherwise
t
@Harshit @iago @Lars-Jørgen Kristiansen Hi gentlemen, sorry to dig old thread, but do you know if there is any improvement in the are of multitenants in Prisma? Development of https://github.com/Errorname/prisma-multi-tenant seems to be dead for 1,5 years.