Request Mapper Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Alignment: The package leverages Symfony’s Serializer component (via denormalization) and Attributes, making it a natural fit for Symfony-based applications. For Laravel, this introduces a paradigm shift—Laravel relies on request objects (Illuminate\Http\Request) and form requests, while this package assumes Symfony’s dependency injection (DI) and serialization pipeline.
• OOP Validation Integration: The package maps request data to constructor parameters, which aligns with Laravel’s DTO (Data Transfer Object) patterns (e.g., Spatie’s Laravel Data) but requires manual DI setup in Laravel’s context.
• Use Case Fit: Ideal for:
  • API endpoints where request data must be validated and mapped to domain objects.
  • Symfony-to-Laravel hybrid apps (e.g., API platforms using both frameworks).
  • Microservices where request normalization is critical.

Integration Feasibility

• Laravel Compatibility:
  • Low: Laravel lacks native Symfony DI/Serializer integration. Workarounds include:
    • Manual DI: Resolving the mapped object via a service container binding (e.g., AppServiceProvider).
    • Middleware: Intercepting requests, hydrating objects, and injecting them into controllers.
    • Custom Serializer: Building a Laravel-compatible wrapper around Symfony’s Serializer.
  • Performance Overhead: Symfony’s Serializer is not natively optimized for Laravel’s request lifecycle, potentially adding latency.
• Validation Layer: The package does not replace Laravel’s built-in validation (e.g., Validator facade). It complements it by mapping raw data to objects post-validation.
• Upload Handling: FromUploads attribute assumes Symfony’s UploadedFile handling. Laravel’s Request::file() would need adaptation.

Technical Risk

Key Questions

1. Why Symfony’s Serializer?
   • Is the goal type safety (e.g., strict DTOs) or simplified validation? Laravel’s Validator + FormRequest may suffice.
2. Performance Impact
   • Will the Serializer add >10ms latency per request? Benchmark against native Laravel validation.
3. Alternative Solutions
   • Compare with:
     • Spatie Laravel Data (Laravel-native DTOs).
     • API Resource Validation.
4. Long-Term Maintenance
   • Who will maintain the Symfony-Laravel bridge? Is this a one-off or strategic choice?
5. Upload Handling
   • How will FromUploads integrate with Laravel’s Request::file() and HandleUploads traits?

Integration Approach

Stack Fit

Migration Path

1. Phase 1: Proof of Concept (PoC)
   • Implement a single endpoint (e.g., GET /articles/{id}) using the package.
   • Compare development time vs. native Laravel validation.
2. Phase 2: Hybrid Integration
   • Create a Laravel service that:
     • Uses Symfony’s Serializer under the hood.
     • Wraps it in a facade (e.g., RequestMapper::map()).
   • Example:

     // app/Services/RequestMapperService.php
     use Symfony\Component\Serializer\Serializer;
     use Devouted\RequestMapper\Mapper;
     
     class RequestMapperService {
         public function map(object $dto, Request $request): object {
             $serializer = new Serializer([], [new Mapper()]);
             return $serializer->deserialize($request->all(), get_class($dto), 'json');
         }
     }
     

3. Phase 3: Full Adoption
   • Replace Form Requests with DTOs where validation logic is complex.
   • Deprecate manual request parsing in favor of attributes.

Compatibility

• PHP 8.2+: Laravel 9+ supports this, but constructor attributes require PHP 8.0+.
• Symfony Dependencies: Avoid conflicts by isolating the package in a custom service.
• Laravel Middleware: Use middleware to inject mapped objects into controllers:

  public function handle(Request $request, Closure $next) {
      $dto = app(RequestMapperService::class)->map(new GetArticleQuery(), $request);
      return $next($request->merge(['dto' => $dto]));
  }
  

Sequencing

1. Start with Simple Endpoints
   • Begin with GET/HEAD requests (no uploads, minimal headers).
2. Add Complexity Gradually
   • Introduce FromHeader and FromPath before FromUploads.
3. Benchmark
   • Measure memory usage and response time against native Laravel validation.
4. Document Workarounds
   • Track Symfony-specific quirks (e.g., UploadedFile differences).

Operational Impact

Maintenance

• Pros:
  • DRY Validation: Centralize validation logic in DTOs instead of controllers/Form Requests.
  • Type Safety: PHPStan/Psalm will catch type mismatches early.
• Cons:
  • Vendor Lock-in: Tight coupling to Symfony’s Serializer may complicate future migrations.
  • Debugging Complexity: Stack traces for serialization errors will be less familiar to Laravel devs.
• Mitigation:
  • Write custom error handlers for Serializer exceptions.
  • Use interfaces to abstract the mapper layer.

Support

• Learning Curve:
  • Team must learn Symfony’s Serializer and attribute-based mapping.
  • No Laravel-specific docs → require internal documentation.
• Community:
  • No stars/issues → assume unproven reliability.
  • Fallback to Spatie’s Laravel Data or custom solutions if bugs arise.
• Support Plan:
  • Assign a tech lead to maintain the Symfony-Laravel bridge.
  • Create a runbook for common failure modes (e.g., malformed headers).

Scaling

• Performance:
  • Cold Start: Serializer initialization adds ~50ms on first request (cache with Symfony\Component\Cache).
  • Hot Path: Minimal overhead if reused across requests.
• Horizontal Scaling:
  • Stateless, so no issues with load balancing.
• Database Impact:
  • None (pure request-layer transformation).

Failure Modes

Ramp-Up

• Onboarding Time: 2–4 weeks for a team unfamiliar with Symfony’s Serializer.
• Training Materials:
  • Internal docs on:
    • How to define DTOs with attributes.
    • Debugging serialization errors.