Reputation: 23
Hello dear community!
SITUATION
I'm restructuring a tenant-based application.
Currently there exist 3 .env files (local, development, production) for each tenant and i load the correct .env file through a logic of IF's in bootstrap/app.php depending on the SERVER_NAME from the request.
TASK/IDEA
Now i wan't to shift away from overloading .env files, especially since the 'configs' aren't differenciating from (e.g.) .env-local to .env-development.
So; a config-file where i store those settings would be the most logic idea
config/tenant.php
<?php
$tenantArr= [
1 => [
"id" => 1,
"name" => "Config 1",
"user_login" => "ldap",
"role_management" => "abo",
],
2 => [
"id" => 2,
"name" => "Config 2",
"user_login" => "db",
"role_management" => "abo",
],
3 => [
"id" => 3,
"name" => "db 3",
"user_login" => "ldap",
"role_management" => "abo",
]
];
return $tenantArr[ $tenant_id] ?? die("error; no key found");
GOAL
The goal is that i can load a config universally via (e.g.) config('tenant.name').
(Later-on this of course get's more split up, perhaps with an Facade across the project to access further specifics of each tenant.)
QUESTIONS
Where could i implement the logic to get $tenant_id in the last line?
Is there a way to pass the variable from bootstrap/app.php into the config-array?
Or should i simply insert my IF-logic at the start of the config-file?
Thanks in advance!
Upvotes: 0
Views: 1170
Reputation:
Little late to the party on this one. None of these approaches are good in my book. Since I've done this several times here is my advise. The best way in my eyes is doing a middleware attached to your routing. From there you can tell the tenant by either a subdomain or the first segment in your URL. Then store all that tenant info in the database with connection info to the separate tenant database. Once you know that connection info you can set a dynamic 2nd database connection. Now you have separation of tenants but still using the main Laravel base framework at the same time. Keep your tenant models away from your framework models or you will have a nightmare on your hands. Particularly important also is to always keep tenant code in their own namespaces. For instance on my latest enterprise multi-tenant that I've been working on for 5+ years:
app\Models\Main - this is the framework directory for models
app\Models\Tenant\Foo - this is the Foo tenant directory for models
app\Models\Tenant\Bar - this is the Bar tenant directory for models
Then continue to do this for all tenants in controllers, public files, views and then have a separate route file for each tenant. If you want to use a class between all tenants like a common menu system or something learn about using Traits. You can then share between all tenants and not have to have the same class 27 times in 27 different places. Lots of info here and lots to think about. Giving you a shove in the right direction. Also, dealing with a config file is a nightmare to change. Read about the order Laravel loads things up and then caches them. You'd have to do a cache bust on almost every load and that's a huge performance hit.
Upvotes: 2