Multi-tenancy

Arrel no té cap estratègia de multi-tenancy pròpia, ni per domini, ni per subdomini, ni per base de dades, perquè ja n'hi ha bones a l'ecosistema Laravel (stancl/tenancy és l'habitual) i no té sentit reinventar-ne una de pitjor. En comptes d'això, exposa dos punts d'enganxament perquè hi connectis la teva:

1. TenantResolver

namespace Arrel\Tenancy;

interface TenantResolver
{
    public function resolve(): mixed;
}

Implementa'l i enllaça'l al contenidor:

final class StanclTenantResolver implements TenantResolver
{
    public function resolve(): mixed
    {
        return tenant();
    }
}

// AppServiceProvider::register()
$this->app->bind(TenantResolver::class, StanclTenantResolver::class);

Un cop enllaçat, $this->tenant() és disponible dins de qualsevol Resource:

public function canViewAny(): bool
{
    return $this->tenant()->hasFeature('students');
}

public function getEloquentQuery(): Builder
{
    return parent::getEloquentQuery()->where('tenant_id', $this->tenant()->id);
}

Sense cap TenantResolver enllaçat, $this->tenant() retorna null, Arrel funciona igual de bé en una aplicació sense tenancy, sense haver de configurar res.

2. Middleware

// config/arrel.php
'middleware' => [
    \App\Http\Middleware\IdentifyTenant::class,
],

Aquest middleware s'executa abans de l'autenticació i el propi routing d'Arrel, a totes les rutes web i API del panell. És on identifiques el tenant a partir de la petició (domini, subdomini, capçalera...) i actives la connexió de base de dades corresponent, perquè quan Arrel arribi a consultar qualsevol Resource ja estigui resolent contra la base de dades correcta.

Cap d'aquests dos punts força res sobre com defineixes «tenant»: és una interfície i un slot de middleware, no un sistema.