Framework Laravel Package

Technical Evaluation

Architecture Fit

• High-Performance PHP Framework: Spiral’s hybrid runtime (PHP + RoadRunner) aligns well with modern Laravel applications requiring low-latency, high-throughput workloads (e.g., APIs, real-time systems). The resident memory kernel reduces cold starts and memory leaks, a critical advantage for Laravel microservices or long-running processes.
• PSR Compliance: Full PSR-11 (Container), PSR-15 (Middleware), and PSR-17 (HTTP Factories) compatibility ensures seamless integration with Laravel’s existing DI, middleware, and HTTP layers. The Cycle ORM (a modern alternative to Eloquent) offers a type-safe, query-building approach that could replace or supplement Laravel’s Eloquent in performance-critical paths.
• Multi-Paradigm Support: Spiral’s CQRS, RPC, and Queue-Oriented architectures complement Laravel’s MVC but provide alternatives for event-driven or workflow-heavy applications (e.g., sagas, workflows via Temporalio).
• RoadRunner Integration: Leverages RoadRunner for GRPC, WebSockets, and background workers, enabling Laravel to adopt serverless-like scaling without rewriting core logic. This is particularly valuable for real-time features (e.g., notifications, live updates) currently handled via Laravel Echo/Pusher.

Integration Feasibility

• Laravel-Specific Bridges:
  • RoadRunner Bridge: Enables Laravel’s HTTP kernel to run under RoadRunner, replacing traditional PHP-FPM/Nginx setups. This reduces overhead and improves concurrency.
  • Cycle ORM Bridge: Allows mixed Eloquent/Cycle usage or a full migration to Cycle for high-performance queries (e.g., bulk operations, complex joins).
  • Queue Bridges: Extends Laravel’s queue system with AMQP, Kafka, or Beanstalk backends, improving reliability for distributed jobs.
• Shared Ecosystem:
  • Monolog, Symfony Console, and PSR-15 Middleware are already used in Laravel, minimizing learning curves.
  • Twig/Blade Hybrid: Spiral supports dynamic templates, but Laravel’s Blade remains the default. A custom Twig loader could bridge the two.
• Migration Path:
  • Incremental Adoption: Start with RoadRunner for HTTP/Workers, then introduce Cycle ORM for read-heavy models, and finally adopt Spiral’s DI/Events for complex workflows.
  • Laravel Service Providers: Spiral’s bootloaders can be mapped to Laravel’s service providers, allowing gradual replacement of core components.

Technical Risk

• Breaking Changes:
  • Spiral’s container (PSR-11) differs from Laravel’s Pimple-based container. While compatible, dependency injection strategies (e.g., singletons, scopes) may require refactoring.
  • Cycle ORM’s query builder is not Eloquent-compatible, necessitating model rewrites for complex queries.
• Performance vs. Familiarity Tradeoff:
  • Cycle ORM offers better performance for bulk operations but lacks Eloquent’s active record convenience.
  • RoadRunner improves concurrency but introduces new deployment complexity (e.g., Docker, process management).
• Tooling Gaps:
  • Laravel’s Artisan, Tinker, and Forge have no direct Spiral equivalents. Custom CLI tools (e.g., Spiral’s scaffolder) would need integration.
  • Laravel Mix/Vite has no Spiral equivalent; asset pipelines would require a separate solution (e.g., Webpack Encore).

Key Questions

1. Use Case Alignment:
   • Is the primary goal performance optimization (e.g., high-traffic APIs) or feature expansion (e.g., real-time systems, workflows)?
   • Would partial adoption (e.g., RoadRunner + Cycle ORM) suffice, or is a full rewrite needed?
2. Team Expertise:
   • Does the team have experience with PSR-11 containers, RoadRunner, or Cycle ORM? If not, what’s the ramp-up cost?
3. Deployment Impact:
   • How will RoadRunner’s process model interact with Laravel’s existing queue workers, cron jobs, and scheduled tasks?
4. Vendor Lock-In:
   • Spiral’s ecosystem is smaller than Laravel’s. Are critical dependencies (e.g., auth, caching) available in Spiral’s packages organization?
5. Testing & Debugging:
   • How will Laravel’s testing tools (e.g., Pest, Dusk) integrate with Spiral’s console commands and bootloaders?
6. Long-Term Maintenance:
   • Spiral is actively maintained, but Laravel’s backward compatibility is a key selling point. How will deprecations in either framework affect the hybrid system?

Integration Approach

Stack Fit

• PHP 8.1+: Spiral requires PHP 8.1+, while Laravel supports down to PHP 8.0. Upgrade Laravel to PHP 8.1+ for compatibility.
• RoadRunner as the Application Server:
  • Replace PHP-FPM/Nginx with RoadRunner for HTTP requests, WebSockets, and queues.
  • Use RoadRunner’s PSR-15 middleware to integrate Laravel’s middleware stack.
• Database Layer:
  • Cycle ORM for high-performance queries (e.g., analytics, bulk updates).
  • Eloquent for active record convenience (e.g., admin panels, CRUD).
  • Shared migrations between both ORMs via Doctrine Migrations.
• Dependency Injection:
  • Laravel’s Service Container → Spiral’s PSR-11 Container:
    • Use Spiral’s bindSingleton for Laravel’s singleton bindings.
    • Replace Laravel’s Facades with Spiral’s direct DI (e.g., app()->make() → container()->get()).
  • Event System:
    • Spiral’s PSR-14 Events can replace Laravel’s Events, but listeners will need adaptation (e.g., handle() method signature).
• Authentication & Security:
  • Spiral’s Auth (RBAC, JWT, sessions) can replace Laravel’s Auth, but custom guards (e.g., Sanctum) may need rewrites.
  • CSRF, Encrypted Cookies: Spiral’s built-in support can replace Laravel’s middleware.

Migration Path

Compatibility

• Laravel Packages:
  • Taylor Otwell’s Packages: Many (e.g., laravel/sanctum, spatie/laravel-permission) are PSR-compliant and can work with Spiral’s container.
  • Non-PSR Packages: May require adapters (e.g., wrap Laravel’s Auth in Spiral’s AuthMiddleware).
• Frontend Integration:
  • Blade/Twig: Spiral supports Twig; Laravel’s Blade can run via Twig’s {% verbatim %} or a custom loader.
  • Livewire/Alpine: No direct Spiral support; JavaScript frameworks (React/Vue) may be preferred for real-time features.
• Third-Party APIs:
  • Stripe, AWS SDKs: Use PSR-18 HTTP clients (e.g., Guzzle) already supported by both frameworks.

Sequencing

1. Proof of Concept (PoC):
   • Deploy a Laravel app under RoadRunner (PSR-15 middleware only).
   • Test queue workers and HTTP performance.