@noblemfd I’ve a couple of single database, multi-tenancy applications running in production that have been for a few years now, and were built without packages.
If you’re planning on adding a trait/scope to models to automatically scope them to a tenant, as someone who has been there and done that, my advise is: don’t. I took that approach in the first version of one of my apps, and it ended up causing more problems than it solved. You can use your models in admin panels, Artisan commands, queued jobs etc without having to also do something like call withoutGlobalScopes all over the place, which just let to unmanageable and unmaintainable code, so I ended up rewriting the app without global scopes and things are much, much better.
In terms of your tenant-specific settings, you’ll need to store them in a database rather than configuration files if you’re wanting tenants to be able to set their own mail settings etc. You can then use middleware to load the relevant settings from the database:
class LoadTenantMailSettings
{
public function handle(Request $request, Closure $next)
{
// Identify tenant from subdomain
// Load settings for that tenant
config('mailers.tenant', [
// Tenant-specific mail settings here
]);
return $next($request);
}
}
With the mailer configured at runtime, you can then use that in your application:
Mail::mailer('tenant')->to('[email protected]')->send(new SomeTenantMailable());