Runtime Laravel Package

Technical Evaluation

Architecture Fit

• Decoupling Global State: Symfony Runtime aligns perfectly with Laravel’s evolving architecture, particularly for modular monoliths or microservices. It replaces Laravel’s traditional public/index.php (which relies on $_SERVER, $_ENV, and global state) with a runtime-agnostic bootstrap layer, enabling:
  • Explicit dependency injection (e.g., replacing $_ENV['APP_DEBUG'] with injected config).
  • Runtime isolation (e.g., HTTP vs. CLI vs. worker contexts without shared globals).
  • Framework-agnostic execution (critical for serverless/Lambda deployments where PHP-FPM assumptions fail).
• Symfony Ecosystem Synergy: Laravel 10+ already uses Symfony components (e.g., HttpClient, Mailer). Symfony Runtime complements this by standardizing bootstrapping, reducing friction for teams adopting Symfony’s DI container or API Platform.
• Laravel-Specific Gaps:
  • Laravel’s Service Provider model (e.g., register(), boot()) often relies on global state. Runtime does not replace this but wraps it, requiring adaptive refactoring (e.g., moving $_ENV access to injected services).
  • Artisan CLI integration is mature, but worker/queue runtimes (e.g., RoadRunner) may need custom adapters.

Integration Feasibility

• Low-Code Entry Point: Replace public/index.php with a runtime-aware wrapper (e.g., bootstrap/runtime.php):

  use Symfony\Component\Runtime\Runner\RunnerInterface;
  use Symfony\Component\Runtime\SymfonyRuntime;
  
  $runtime = new SymfonyRuntime();
  $runner = $runtime->getRunner();
  $runner->run();
  

  • Zero config for basic use; minimal for customization (e.g., overriding project_dir).
• Laravel-Specific Challenges:
  • Kernel Initialization: Laravel’s Kernel assumes $_SERVER/$_ENV. Runtime must delegate these to injected services (e.g., Request, Config).
  • Middleware: Global state in middleware (e.g., $request->server->get('HTTP_HOST')) requires refactoring to injected dependencies (e.g., HostResolverInterface).
  • Event Listeners: Listeners using $_ENV or $_SERVER must be updated to use Symfony’s ParameterBag or Laravel’s Config.
• Tooling Compatibility:
  • Laravel Mix/Vite: Unaffected (runtime operates at the PHP layer).
  • Horizon/Queues: Requires custom runner for worker processes (e.g., RoadRunner adapter).
  • Testing: Eliminates flaky tests caused by global state (e.g., $_ENV pollution in ServiceProvider tests).

Technical Risk

Key Questions for TPM

1. Global State Audit:

   • "Which Laravel components (middleware, providers, listeners) currently rely on $_SERVER/$_ENV? Can we quantify the refactoring effort?"
   • Tool Suggestion: Run phpstan --level max with rules for global functions or use roave/security-advisories to detect indirect global state usage.

2. Runtime Diversity:

   • "Are we targeting HTTP-only, or do we need CLI/worker support (e.g., RoadRunner, Lambda)?"
   • Impact: Worker support requires custom runner adapters (e.g., RoadRunnerRuntime).

3. Laravel Version:

   • "Are we on Laravel 10+? If not, what’s the upgrade path (Symfony Runtime v7.x supports PHP 7.2+, but Laravel 9.x may need polyfills)."

4. Testing Strategy:

   • "How do we handle legacy tests that assume global state? Can we use Runtime’s TestRuntime for isolated test environments?"

5. Deployment Strategy:

   • "Can we A/B test Runtime in staging before full rollout? What’s the fallback plan if global state refactoring uncovers critical bugs?"

6. Team Readiness:

   • "Does the team have experience with Symfony components? If not, what’s the training/ramp-up plan for Runtime’s DI and runtime concepts?"

7. Long-Term Vision:

   • "Is this a stepping stone to microservices, or is it primarily for compliance/security?"
   • Impact: Microservices require deeper runtime customization (e.g., per-service bootstrapping).

Integration Approach

Stack Fit

• Laravel 10+: Native compatibility (Symfony Runtime v8.x aligns with Laravel’s PHP 8.2+ requirement).
• Laravel 9.x: Possible with v7.x, but may require polyfills for Symfony 6.x dependencies.
• PHP 8.4+: Recommended for v8.x (FrankenPHP auto-detection, PHP 8.4 features).
• Alternate Runtimes:
  • RoadRunner: First-class support via FrankenPHPRunner auto-detection.
  • AWS Lambda/Bref: Requires custom LambdaRuntime (example: Bref’s Symfony integration).
  • Cloudflare Workers: Experimental; may need WebAssembly (WASM) PHP (e.g., PHP-WASM).

Migration Path

Compatibility