Psl Laravel Package

Technical Evaluation

Architecture Fit

• Strong alignment with modern PHP architectures: PSL’s structured concurrency (fibers), immutable collections, and type-safe APIs align well with Laravel’s evolving async/await support (PHP 8.1+) and Laravel’s growing emphasis on performance and type safety (e.g., Laravel 11’s PHP 8.4+ requirements).
• Replaces legacy PHP primitives: PSL’s Vec, Dict, Str, and Async components directly address Laravel’s reliance on raw arrays, str_* functions, and callback-based async patterns (e.g., queues, jobs). This reduces boilerplate and improves maintainability.
• Complementary to Laravel’s ecosystem:
  • Async: PSL’s Async/Fiber integration could replace Laravel’s Illuminate\Bus or Laravel\Horizon for lightweight, structured concurrency (e.g., batch processing, real-time APIs).
  • Collections: PSL’s Vector/Map/Set could augment or replace Laravel Collections (Illuminate\Support\Collection) for stricter typing and functional operations.
  • Networking: PSL’s TCP/TLS/HTTP components could underpin Laravel’s HTTP client (Guzzle) or replace Symfony\Component\HttpClient for low-level control.
• Potential conflicts:
  • Laravel’s Service Container may clash with PSL’s immutable/functional design (e.g., dependency injection vs. pure functions).
  • ORM integration: PSL’s type safety could conflict with Eloquent’s dynamic properties or relationships unless explicitly adapted.

Integration Feasibility

• High for greenfield projects: PSL’s design is modular, allowing selective adoption (e.g., start with Async or Type validation).
• Challenging for legacy Laravel apps:
  • Stateful vs. immutable: Laravel’s ORM, sessions, and caching rely on mutable state, while PSL enforces immutability. Hybrid patterns (e.g., PSL for DTOs, Laravel for persistence) would be needed.
  • Async compatibility: Laravel’s queues/jobs use promises/callbacks, while PSL favors fibers. Bridging these (e.g., via Async\run) would require careful sequencing.
• Tooling support: PSL’s Psalm/PHPStan plugins enable gradual adoption by surfacing type errors early, but Laravel’s built-in tools (e.g., php artisan make:model) may need updates.

Technical Risk

Key Questions

1. Adoption scope:
   • Should PSL replace Laravel’s core collections/async, or supplement them (e.g., for APIs/DTOs)?
   • Which components (e.g., Async, Type, Vec) offer the highest ROI?
2. Async strategy:
   • How to integrate PSL fibers with Laravel’s queue system (e.g., Async\run wrapping job execution)?
   • Will PSL’s structured concurrency replace Laravel’s Illuminate\Bus or coexist?
3. Type safety:
   • Should PSL’s types override Laravel’s scalar types (e.g., non_empty_string vs. string)?
   • How to handle Eloquent models with PSL’s immutable constraints?
4. Performance:
   • What’s the overhead of PSL’s type checks vs. native PHP?
   • Can PSL’s TCP/HTTP components outperform Guzzle/Symfony HTTP clients?
5. Tooling:
   • How to integrate PSL’s Psalm/PHPStan plugins with Laravel’s built-in tools?
   • Will mago or phpstan-extension replace Laravel’s IDE helpers?

Integration Approach

Stack Fit

• Best for:
  • API layers: PSL’s Async/HTTP/Type for request validation and concurrent processing.
  • Background jobs: Replace Laravel queues with PSL fibers for lightweight, structured concurrency.
  • DTOs/validation: PSL’s Type for input validation (e.g., API payloads, form data).
  • Data pipelines: PSL’s Vec/Dict for functional transformations (e.g., ETL, reporting).
• Poor fit for:
  • ORM/persistence: PSL’s immutability conflicts with Eloquent’s dynamic properties.
  • Stateful services: Laravel’s sessions, caching, or real-time event systems may need wrappers.
  • Legacy callbacks: PSL’s fiber-based async won’t interop with Closure-based Laravel events.

Migration Path

1. Phase 1: Validation and DTOs (Low Risk)

   • Replace Laravel’s manual validation with PSL’s Type (e.g., API request DTOs).
   • Example:

     use Psl\Type;
     
     $userType = Type\shape([
         'name' => Type\non_empty_string(),
         'email' => Type\email_address(),
     ]);
     $validated = $userType->coerce(request()->all());
     

   • Tools: Use PSL’s Psalm plugin to catch type errors early.

2. Phase 2: Collections (Medium Risk)

   • Replace Illuminate\Support\Collection with PSL’s Vec/Dict for functional operations.
   • Example:

     use Psl\Vec;
     
     $users = Vec\map($users, fn($user) => $user->name);
     

   • Challenge: Laravel’s Collection macros may need PSL equivalents.

3. Phase 3: Async/Concurrency (High Risk)

   • Replace Laravel queues with PSL fibers for CPU-bound tasks.
   • Example:

     use Psl\Async;
     
     Async\main(static function() {
         $result = Async\concurrently([
             fn() => processOrder(1),
             fn() => sendNotification(2),
         ]);
     });
     

   • Challenge: Integrate with Laravel’s Illuminate\Bus or Laravel\Horizon.

4. Phase 4: Networking (High Risk)

   • Replace Guzzle/Symfony HTTP clients with PSL’s HTTP/TCP for custom protocols.
   • Example:

     use Psl\HTTP;
     
     $response = HTTP\request('GET', 'https://api.example.com');
     

   • Challenge: PSL’s low-level API may require wrappers for Laravel’s HTTP conventions.

Compatibility

Sequencing

1. Start with non-critical paths:
   • API validation (Type).
   • Functional data transformations (Vec/Dict).
2. Isolate async changes:
   • Use PSL fibers for new background services (e.g., workers).
   • Gradually migrate from queues to fibers.
3. Avoid ORM conflicts:
   • Keep Eloquent models separate; use PSL for DTOs/input validation.
4. Leverage tooling:
   • Enable PSL’s Psalm/PHPStan plugins early to catch issues.
   • Use mago for enhanced type inference during migration.

Operational Impact

Maintenance

• Pros:
  • Reduced boilerplate: PSL’s functional collections (Vec/Dict) eliminate manual array operations.
  • Type safety: Catches bugs at compile time (e.g., invalid API inputs).
  • Consistent APIs: PSL’s standardized interfaces reduce context-switching.
• Cons:
  • Learning curve: Team must adopt functional programming patterns (e.g., immutability, pure functions).
  • Tooling dependency: Relies on Psalm/PHPStan for full benefits; may slow down CI.
  • Debugging: Fibers/async code can be harder to debug than traditional callbacks.

Support

• Pros:
  • **Self