✅ BlazorWASM Multi Tenant / Multi Tenancy
Hello,
I'm currently trying to implement multi tenancy to my blazor application and I could need a hand.
The User should be able to select a tenant at runtime and the new querys should use that new/updated tenant.
I browsed the internet a lot and found a lot of variants, but still not sure what's the best for me and also failed on implementing them xD
Currently I'm storing the tenant information in my appsettings and created a TenantService to set the tenant and receive the connectionstring.
My DbContext uses the service to get the current connectionstring (in theorey)
I registered my ContextFactory in the program.cs
Image is added how I use my context for example in my repo.
I'm trying to switch the tenant from the frontend via an api call.
I think my problem is the lifetime or smth, because I can switch the tenant and that settenant works, but if I use a new query it seems like the new instance of my context uses the default value, because the "updated tenant" isnt remembered. Sorry for my noob terms, I'm new to that and hope you can understand me :D
I'd be happy about some help and maybe some input for my knowledge and understanding. Thank you
Greetings
Exi
33 Replies
you're storing tennancy in APPSETTINGS?!
how does that make any sense?
or you just mean, you want to move it OUT of there, and make it a user-facing option?
I wanna move it out there later and have that in my sql server
Actually I'm not even sure if that tenacity thing is the stuff I need - At the beginning I just wanted to switch the db context depending on a value I selected in the frontend in a dropdown.
A friend of mine just said: that sounds like you need the multi tenacy lol
Now I'm trying to figure stuff out ^^
define "switch the db context"
okay lemme explain the use case a little bit, I guess that helps
usually 😉
Imagine we're having a few sql server with different tenants, lets say server1 and server2 and on each server are different tenants like Prod, Test, Dev or whatever.
Now there are some sql routines to validate some data or check some procedures or whatever.
in this blazor app is a for example a page with an overview of all errorlogs, fetched from server1, tenant test.
then the user wants to see the errors from server1, tenant dev => Has a Select and can select the desired tenant => Data refreshes
so, multiple servers, each with multiple databases
yes
you're building a server management tool
so, ultimately, the thing the user needs to swap around is which database they're connecting to
yes, that sounds very much like multi-tenancy
Good! At least it's the right path :D
I read a lot of articles and a lot of stuff was arround user auth and switching the tenant based on that, but in my case there isnt even a usermanagement implemented at the current state.
the instance is just running on a private server and can only read "non sensitive" data from the database and do nothing else.
that's the first thing that stopped me from implementing a lot of stuff.
But I'm pretty sure I wont get arround that usermanagement stuff in the future - Would you recommend me to do that before or in the process of implementing the multi tenacity as well?
I'm not really sure how to start into that whole topic^^
so, you don't have a user system at all?
if you can access the tool, you're assumed to have enough rights to access the things it accesses?
well, overall its all running over an azure AD, but the software by itself rn isnt connected
mm-kay
rn its like: its beta for testing and everyone who can access it, can access it anyways
since its on a well protected server
and only read^^
you might need to dip into SOME kinda user management, even without needing the concept of a user
cause what you DO need is the concept of some kinda session
I.E. multiple people could be using the tool at once, and want to look at different servers
if that's ALL you're concerned with, you could just drop the server choice into a cookie and be done with it
yea that's what I thought, otherwise I couldnt find a way to make that for each user
Thats what gonna happen
you could also just keep all your session state in the client, I suppose
and pass that data along to the server each time
I.E. make each request stateless
might be a little tedious, depends how many session var you need to pass along
mh mh mh
not sure how I feel about that passing the desired server everytime
that's what all the user-based multi-tenancy solutions that you're reading about are doing
cause they embed the tenant setting in the auth token
and the auth token gets passed along with every request
that's how auth works
that's how cookies work
etc.
yeah, if I've the usermanagement right
I saw a lot coming from the httpcontext and getting the info from there
that's web for you
Multi-tenancy - EF Core
Learn several ways to implement multi-tenant databases using Entity Framework Core.
mh I think I've to look into that auth stuff to pass the info I need from client
I thought you already said you were just gonna use a cookie?
if the tenant selection is the only thing you need to pass around, do that
or make it a request header
or make it a query param
if that's ALL you need, don't add a user system for that reason alone
yee that's my problem rn.
the state is that I only select a database at the frontend and call the SetDatabase function once ->
but afterwards if I load data for example I dont pass any information from the client regarding the desired server and because of that the context always uses the default value
if I send the server information with every interaction my problem is probably solved
sure sounds like it
that was my first thought at the beginning, but it felt like passing the server for every request in my header/query feels to simple and there is probably another way
the alternative is establishing an actual server-side session
which involves passing at least a session ID with each request anyway
might as well skip the noise
mhh, I saw a few tenacity samples where they used a part of the url to identify the server for the query, if I think about that now, thats kinda like passing it as header xD
6 of one, half-dozen of the other
Thanks for the conversation, you really helped me a lot and gave me confidence to proceed further
I'm always afraid to write bad code and dont follow best practice and that makes me hesitate just trying stuff out :D
Maybe I should leave that a little bit behind and just learn for now^^
you should
building something and then scrapping it and rebuilding it better once or twice is fairly normal
yee and usually its a good feeling for me, because I see the improvement over the time :D
But got new colleagues and that changed a little bit ^^