Request Dto Resolver Bundle Laravel Package

Product Decisions This Supports

• Build vs. Buy: Avoid reinventing DTO resolution/validation logic for Symfony APIs, reducing technical debt and accelerating development.
• API/Backend Roadmap:
  • Standardize request validation: Replace ad-hoc validation logic in controllers with a declarative, reusable DTO pattern.
  • Improve developer experience: Reduce boilerplate in controllers by automating DTO instantiation and validation (e.g., no manual $request->request->get() calls).
  • Enforce type safety: Leverage strict typing for DTOs to catch errors early (e.g., invalid query params, missing headers).
  • Support complex payloads: Handle nested DTOs, file uploads, and mixed-type inputs (e.g., query params with custom transformations).
• Use Cases:
  • Public APIs: Ensure consistent validation across endpoints with clear error responses (e.g., 400 Bad Request with violation details).
  • Internal services: Validate requests between microservices or CLI commands using the same DTO pattern.
  • Legacy migration: Gradually adopt DTOs in existing controllers without rewriting validation logic.
  • Multi-tenant systems: Validate tenant-specific request data (e.g., headers, route params) uniformly.

When to Consider This Package

• Adopt if:
  • Your team uses Symfony and wants to reduce controller boilerplate for request handling.
  • You prioritize type safety and want to catch validation errors at runtime (e.g., invalid query params, missing files).
  • Your API handles complex payloads (nested DTOs, file uploads, custom query transformations).
  • You need consistent validation across endpoints with minimal duplication (e.g., shared DTOs for multiple routes).
  • Your team values developer experience (e.g., IDE support for DTOs, clear error messages).
• Look elsewhere if:
  • You’re not using Symfony (this bundle is Symfony-specific).
  • Your validation needs are simple (e.g., basic form validation without DTOs).
  • You require high performance for ultra-low-latency APIs (this adds a small resolution/validation overhead).
  • Your team prefers manual validation (e.g., for fine-grained control over error handling).
  • You’re using non-PHP backends (e.g., Node.js, Go, Python).
  • Your project has strict dependency constraints (e.g., avoiding new Symfony bundles).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us build APIs faster and more reliably by automating request validation and reducing boilerplate. Instead of manually parsing and validating request data in every controller (e.g., $request->query->get('age')), we define type-safe DTOs once and let the system handle the rest. This cuts development time, improves code quality, and ensures consistent error responses for our APIs. For example, a complex endpoint with 10 validation rules could shrink from 50+ lines of code to just a few lines using a DTO. It’s a low-risk investment with high ROI for backend teams."

For Engineers:

*"This bundle replaces manual request parsing and validation with a declarative DTO pattern. Key benefits:

• No more repetitive validation logic: Define constraints (e.g., @Assert\NotBlank) once in the DTO, reuse across controllers.
• Strict typing: Catch type errors early (e.g., string vs. int query params) with clear error messages.
• Nested DTOs: Support complex payloads (e.g., POST /orders with a Customer and Items[] DTO).
• Symfony-native: Integrates seamlessly with Symfony’s validator and exception handling.
• Flexible: Customize behavior per-DTO (e.g., strict vs. loose typing) or globally. Example: Instead of this:

public function createOrder(Request $request): Response {
    $data = $request->request->all();
    $validator = $this->validator->validate($data, ...);
    // ...
}

Use this:

public function createOrder(OrderDto $dto): Response {
    // $dto is auto-validated and hydrated
}

It’s cleaner, safer, and more maintainable—especially for APIs with many endpoints."*