Adding multi tenancy to an existing Laravel web application

hi my name's mike and every day i code today i'm going to be adding multi-tenancy to an existing loroveil application in case you don't know multi-tenancy offers your application users a unique database connection therefore increasing the stability and security of your app for this project i'm going to use tennessee for lauravel i've used this platform or this package in the past and it actually works pretty well there are a few gotchas and a few tricky things that that i will have to figure out together um but rest assured it's a pretty stable package and i'm actually pretty happy with it before we start let's go ahead and jump over to this this uh sketchboard and let's figure out how this is gonna look so of course the traditional application design would have a website perhaps this would be the website that connects to a single database so the problem that you might see here is if you have a lot of app users then each one of the users of course would be using the same the same database the reason that i like multi-tenancy is because it ensures that each user is almost siloed from from the others you've most definitely have used multi-tenancy in the past so if you have a gmail account uh if you've got a dropbox account realistically any account that you have where you log in just about every software as a service is a multi-tenant app so the structure of this multi-tenant app will actually look something like this so the first database is what we'll call the landlord and then the sub databases is each tenant you can think of each tenant as a customer so if i was dropbox then dropbox would be the landlord and the users would be the tenants so i've tried to to code this myself and it was it wasn't as easy as i thought it would be um the tennessee package actually works really really well and um it's it seems to be i mean you could basically install it you don't have to change too much within your application so it makes it really easy to integrate uh in the project that we're integrating today the project is near completion and so this is one of the last steps that we've done for this project one of the reasons that we we decided to wait until the end is because um because each tenant will essentially get their own database so if your application isn't finished then anytime you make a change to your application preferably through a migration then you have to run that that migration for each one of your tenants so there are three basic ways that you can implement tennessee tenancy on your application so the first way would just be to use database tables so for example that the table might have an id or key or some reference to who the tenant is so back to the original dropbox example um perhaps in the table there's a company id or an owner id that would be directly in the table i don't like that method as much because if for some reason there's a bug in the source code and data can be leaked out then it would be possible that other individuals that are accessing the same database if it's a shared database table then some of my data and some of my information might be leaked so so that's method one method two would actually be to use uh multiple databases um we should also list so um i think my sequel and postgres are probably the most common uh definitely the drivers are are here for um with the tennessee package um so the multi database approach would kind of look like this right here um now the approach that i will ultimately do is i will use a single tenant database with a separate seam with separate schemas so this is a feature that can only be done with postgres uh you could think of a schema as almost like a sub database so if we were to redraw how we're going to set this up today then it would look more like this so we now have our tenant database and then within the tenant database we have our schemas so this would be like schemo so um i don't know this would be like acme inc this could be the city of gotham and so on i like schemas because they essentially function the same way databases do so that basically covers the architecture of how our databases need to be set up let's go ahead and just talk quickly about how traffic hits our application and then what happens so the request is now made to the landlord application so in the previous example this was dropbox um the the way i guess the the big difference between a standard app and perhaps a multi-tenant app is sometimes you identify who the tenant is based off of the domain name so if someone was to make a request and maybe dropbox isn't the the best example here but sometimes you might see something like a a subdomain for the site okay so if the company if our company the landlord company was called site inc um and the tenant was acme then whenever whenever someone goes to the acme.site inc we would want to swap over to the acme inc database it would also be possible because this of course this is all dns and it just depends how you want it to be routed if you wanted to have the top level domain itself to be routed as as the the tenant's domain that's possible too essentially uh for every tenant you would have some domain mapped to them so these would be the tenant domains the landlord application maintains a list of these tenant domains so the landlord application application actually almost focus or functions like a soft router so um in addition to that we have a a landlord app or perhaps this would be like the application we'll say this is the tenant application and this is all shared source code a landlord app sits somewhere in here and via the landlord app is how you would be able to do things like add tenants suspend tenants or anything else so realistically anything that the landlord app does ultimately um so so this area right here manages just think of it like a landlord it manages everything a landlord advantage who the customers are or who the tenants are and then for the tenants each one of the the tenant database has the entire site migration so so um an independent copy of the database the data structure their own tables etc so now that we've gone over that let's go ahead and just jump right into uh the integration i think we're ready so back to tennessee for lauravel we can click on this documentation tab right here and i'm just going to jump right to the quick start there's a lot of great information in here and realistically we can set this up in just a couple minutes but the default setup that this quick start has basically is the the first tenancy idea where we're just using a table it's not horrible okay it's probably it takes it has the least number of moving parts you only need one database um but like i said i don't think it's as ideal um so we will skip over any any areas where we need to and um and then i'll walk you through how we set it up like this the way that i prefer um so let's go ahead and jump right in so on this side now i've got my my uh lauraville app that's set up you can kind of see all my migrations here so let's go ahead and first add the tendency package so next we run the tennessee install i'm using lorvel cell so i've got to prefix each one of my database enabled commands with cell so one when once that has completed we can see that this folder now exists in our mic in our migrations we also have a config file these two items right here uh can stay where they are but everything else actually needs to move into the tenant folder whenever a new tenant is created we want these migrations to be run here in the routes we now have a tenant route so i'm gonna go ahead and just remove this dashboard here as well if i don't remove this well actually let's find out um so typically what it probably will do is it'll tell me that we've got two routes named dashboard i've seen it before we'll go ahead and just remove this one for now so now that we've done that the next thing that tendency wants us to do is run the migration but we haven't configured our databases just yet so let's go ahead and do that first so typically the env file um i mean i mean the default database setup is is what you probably would see um typically what i would do is i would add this this env variable and um and this is basically going to be my landlord database i also need to make a a tenant database so if we jump over to table plus i've already created these two databases let's see if there's anything in here i haven't run a migration yet so let me just delete these delete these okay so uh this this pretty much sets up our env file but there's some other things that we need to do to our our database itself so the first thing is is we have to create a few different database connections um because the stock database just comes with one driver for for postgres or one one driver for my sql so what we're going to do here is we're just going to copy this original postgres driver and then i'm going to rename this to pg landlord we'll make another one down here and i'm going to call it pg tenant so that should match what i have in the env for the database for the landlord we're going to reference the database env and i think that's just about it i don't think that we have to do much beyond that so let's go ahead and try to run our migration now actually there's one last thing i'd like to do because this is a postgrass platform and we are using uuids so it's going to be important for one of my initial migrations to to use to add the uuid extension let's see okay i think this should work for us so uh here when we run this first migration this is actually only going to run the migrations in this folder so anything in the tenant folder will be omitted nope uh let's go ahead and run our optimize because we changed a config all right so looking over at our database our landlord table now we have this domains this is essentially going to be the tenant domains that we can access this will have a list of our tenants so that puts us right about here let's go ahead and continue we're going to update the app config and after the routes we'll add the tenant service provider we're going to create a new tenant model then we'll just paste this in in the config we're going to add this model class [Music] there it is i've already added it there's a few other things that i've done um i've already modified this config to add our central domain so this would be our landlord i've also i've also updated the tenancy config to tell us who our landlord database or our central connection is and this pg tenant the way that this works is the pg tenant will um is basically the it's a template the the tenant uh database that's already set up is is the the template for any future um this prefix here really comes in handy if you're only using one database if you wanted you could just use one database and how it would look is under the the tenants you would have all of your tables so perhaps you'd have like users you might see acme underscore users city of gotham underscore users so on and so forth so here on this line i have removed this uh this line because i don't want to create individual databases instead i like to use the postgres schemas so this this line has was originally coming out and it's now uncommon aside from that i don't think i made any other changes to the tenant config so with that let's just go ahead and clear our caches once more and [Music] we do need to modify our our routes to support the tenant domains so let's go ahead and just update the route provider so we'll add this at the very end and then in the boot method we'll call those two functions okay we've added our central domain to our our tendency config i've actually already removed uh i've already updated our routes in this case they say that we can just put some debugging in and it looks like we have it okay so let's see what happens in the documentation they have this tinker command so we'll go ahead and start tinker and we'll try to create our first tenant and here we'll call this one acme uh let me just run this optimize command real quick and we'll just give it another shot beautiful so if we take a look at our database then here's what we see so in our tenants actually in our landlord table we can see that we have a new tenant created acme down here in our tenancy table we should have a new schema in here so let's refresh so here's acme you can see all of our previous migrations are here let's go ahead and give give us a means of accessing our acme tenant so to do that we are going to assign acme.test to acme and that's about it so um just to show you how this works now back here we could go to some site dot test okay i i'm using dns masking so any any site i do test gets forwarded to my local host or 127. um so we're also going to access this on this port so this is my application port as you can see right here okay so accessing this here we should see a message that says that the 10 is not found so i would expect to see that that's great now let's go ahead and request acme.test and this is the the dump that we set so that's it our multi-tenancy has basically been set up um and i mean technically it it works so um so that's that i hope that this video was helpful in the next one we'll go ahead and we'll add a gui so that our landlord application can manage our tenants so that would include being able to add tenants add domains or add sites and then perhaps some way to to access those sites from where we're at thanks again i hope you like this video if you do give it a thumbs up if you want to see more like this let me know in the comments and be sure to subscribe thanks again

Channel: Kompute’s Edge

Views: 17,345

Keywords: laravel, multi-tenancy, tenancy, saas

Id: BitZhTeLgR4

Length: 21min 45sec (1305 seconds)

Published: Fri Apr 15 2022