Multi Tenant Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 7 Focus: The package is explicitly designed for Symfony 7, which may introduce compatibility challenges if the Laravel application relies on Symfony components (e.g., via bridges like symfony/http-foundation). A Laravel-specific multi-tenancy solution (e.g., stancl/tenancy) would be a better architectural fit.
• Entity-Centric Tenancy: The bundle enforces tenant isolation via Doctrine entities and an Aware interface, which aligns with Laravel’s Eloquent ORM but requires custom adapters (e.g., traits/interfaces) to integrate with Laravel’s Model classes.
• Middleware-Less Tenancy: Unlike Laravel’s tenancy packages (which often use middleware for tenant resolution), this bundle requires manual tenant context setting (e.g., via TenantsProvider), increasing boilerplate.

Integration Feasibility

• Doctrine Dependency: The bundle assumes Doctrine ORM, which Laravel uses but with key differences (e.g., event listeners, repository patterns). Custom event listeners or service providers would be needed to bridge gaps.
• Symfony Services: Laravel’s service container (PSR-11) differs from Symfony’s, requiring rewiring of TenantsProvider and related services (e.g., via Laravel’s bind() or extend()).
• Routing/Request Context: Tenant resolution typically happens at the HTTP layer in Laravel (e.g., subdomains, path prefixes). This bundle lacks built-in support for request-based tenant detection, necessitating custom middleware.

Technical Risk

• High Rewriting Effort: Porting this bundle to Laravel would require:
  • Adapting the TenantAware interface to Laravel’s Model trait system.
  • Replacing Symfony’s event system (e.g., kernel.request) with Laravel’s middleware/pipeline.
  • Handling Doctrine-specific features (e.g., EntityManager hooks) in Laravel’s Eloquent context.
• Maintenance Overhead: Without Laravel-specific documentation or community support, long-term maintenance would be risky. The package’s immaturity (0 stars, no dependents) signals unproven reliability.
• Performance Impact: Manual tenant context management (vs. middleware-based resolution) could introduce latency or inconsistency if not handled carefully.

Key Questions

1. Why Symfony-Specific?

   • Are there Symfony components in the Laravel stack (e.g., API Platform, Symfony UX) that justify this choice over native Laravel solutions?
   • Could a lighter-weight Laravel package (e.g., spatie/laravel-multitenancy) achieve the same goals with less risk?

2. Tenant Resolution Strategy

   • How will tenants be identified (subdomains, headers, database)? The bundle lacks built-in support for common Laravel patterns.
   • Will tenant context be set per-request (middleware) or manually (service layer)? The latter increases complexity.

3. Entity Isolation Scope

   • Will all models require the TenantAware trait, or only specific ones? Partial adoption could lead to inconsistent isolation.
   • How will shared/tenant-agnostic entities (e.g., User) be handled?

4. Testing and Validation

   • Are there existing tests for multi-tenancy edge cases (e.g., tenant switching, concurrent requests)?
   • How will data migration/seeders account for tenant-specific schemas?

5. Alternatives Assessment

   • Has stancl/tenancy or spatie/laravel-multitenancy been evaluated? These are Laravel-native and more mature.

Integration Approach

Stack Fit

• Laravel Compatibility: The bundle’s Symfony-centric design (e.g., EventDispatcher, ContainerInterface) requires significant adaptation. Key mismatches:
  • Doctrine vs. Eloquent: The bundle’s TenantAware interface and entity resolution logic must be rewritten for Laravel’s Eloquent ORM.
  • Service Container: Symfony’s ServiceContainer differs from Laravel’s Container (e.g., no autowiring by default, different DI syntax).
  • HTTP Layer: Laravel’s middleware pipeline (e.g., HandleTenants) is the standard for tenant resolution, but this bundle lacks integration points.
• Workarounds:
  • Use Laravel’s ServiceProvider to rebind Symfony services (e.g., TenantsProvider) to Laravel’s container.
  • Create a facade or decorator for TenantsProvider to abstract Symfony dependencies.
  • Replace Symfony events (e.g., kernel.request) with Laravel’s Model observers or Eloquent events.

Migration Path

1. Proof of Concept (PoC)

   • Implement a minimal TenantAware trait for Eloquent models:

     trait TenantAware {
         use \CommitM\MultiTenant\Multitenancy\TenantAware; // Hypothetical adapter
         public function getTenantKey(): string { ... }
     }
     

   • Test tenant context setting via TenantsProvider in a service.
   • Validate query scoping (e.g., where('company_id', auth()->tenant()->id)).

2. Middleware Integration

   • Create a TenantMiddleware to resolve tenants from the request (e.g., subdomain tenant1.app → Company::find(1)) and set context via TenantsProvider.
   • Example:

     public function handle(Request $request, Closure $next) {
         $tenant = TenantResolver::resolve($request);
         app(TenantsProvider::class)->setTenant($tenant);
         return $next($request);
     }
     

3. Doctrine-Eloquent Bridge

   • Override Doctrine’s EntityManager or use Laravel’s Model events (retrieved, saved) to inject tenant IDs.
   • Example global scope:

     Model::preventAccessFromNonOwnerUsing(function ($model, $user) {
         if (!$model->tenant_id || $model->tenant_id !== $user->tenant_id) {
             abort(403);
         }
     });
     

4. Configuration Layer

   • Adapt multi_tenant.yaml to Laravel’s config/tenancy.php:

     'tenants' => [
         'company_id' => [
             'entity' => \App\Models\Company::class,
             'aware_interface' => \App\Interfaces\TenantAware::class,
             'property' => 'company_id',
         ],
     ],
     

   • Use Laravel’s config() helper to access settings.

Compatibility

• Doctrine Extensions: If using Doctrine beyond Eloquent (e.g., doctrine/dbal), ensure the bundle’s query listeners work with Laravel’s setup.
• Caching: Tenant context may need to be cached (e.g., in middleware) to avoid repeated DB lookups.
• Testing: Use Laravel’s RefreshDatabase or MigrateFresh with tenant-specific seeders.

Sequencing

1. Phase 1: Core Tenancy

   • Implement tenant resolution (middleware) and context setting (TenantsProvider).
   • Add TenantAware to critical models (e.g., Product, Order).

2. Phase 2: Query Scoping

   • Replace raw queries with tenant-aware scopes or global scopes.
   • Test isolation (e.g., TenantA cannot see TenantB data).

3. Phase 3: Edge Cases

   • Handle tenant switching (e.g., admin users).
   • Validate performance (e.g., N+1 queries, eager loading).

4. Phase 4: Migration

   • Backfill existing data with tenant IDs.
   • Update seeders/factories to include tenant context.

Operational Impact

Maintenance

• Custom Adaptations: The bundle’s Symfony dependencies will require ongoing maintenance (e.g., updates to Laravel’s Doctrine bridge, service container changes).
• Documentation Gaps: Lack of Laravel-specific guides means troubleshooting will rely on Symfony docs or trial/error.
• Dependency Bloat: Introducing Symfony components (e.g., EventDispatcher) may increase deployment size and complexity.

Support

• Community Risk: With 0 stars/dependents, support is limited to the package author or Symfony community (unhelpful for Laravel issues).
• Debugging Complexity: Tenant context leaks or query issues will require deep knowledge of both stacks (e.g., Symfony’s ParameterBag vs. Laravel’s Request).
• Vendor Lock-In: Custom adapters may become obsolete if the bundle evolves or is abandoned.

Scaling

• Performance Bottlenecks:
  • Manual tenant context setting (vs. middleware) could lead to inconsistent performance if not optimized (e.g., caching TenantsProvider results).
  • Doctrine-specific features (e.g., EntityListener) may not scale well with Eloquent’s simpler approach.
• Horizontal Scaling: Tenant isolation must be validated in distributed environments (e.g., queue workers, scheduled jobs).
• Database Load: Tenant-aware queries may increase read/write operations if not optimized (e.g., missing indexes on tenant_id).

Failure Modes

• Context Leaks:
  • If TenantsProvider is not reset between requests (e.g., in CLI or queue jobs), data isolation fails.
  • Example: A queue job running as TenantA updates TenantB data due to stale context.