Laravel Data Laravel Package

Product Decisions This Supports

• Unified Data Layer: Eliminate redundancy in API responses, form requests, and frontend TypeScript definitions by defining data structures once in PHP. Reduces technical debt and improves maintainability.
• Build vs. Buy: Buy this package to avoid reinventing wheels like DTOs, API transformers, and validation logic. Avoids fragmented libraries (e.g., separate packages for validation, serialization, and TypeScript generation).
• Type Safety: Enforce strict typing across backend/frontend boundaries, reducing runtime errors (e.g., invalid API payloads, mismatched frontend types).
• Roadmap Priorities:
  • API-First Development: Accelerate API development by auto-generating OpenAPI/Swagger docs or TypeScript interfaces from Data classes.
  • Microservices: Standardize data contracts between services (e.g., shared Data classes for inter-service communication).
  • Legacy Modernization: Gradually introduce typed data objects into monolithic apps without rewriting existing validation/resources.
• Use Cases:
  • Admin Panels: Replace manual form handling with validated Data objects (e.g., UserData, OrderData).
  • GraphQL: Auto-generate GraphQL input types from Data classes (via spatie/laravel-graphql).
  • Event Sourcing: Define event payloads as Data objects for consistency.
  • Headless CMS: Serialize content models (e.g., ArticleData) for frontend consumption.

When to Consider This Package

Adopt If:

• Your team struggles with data duplication (e.g., repeating fields in API resources, form requests, and TypeScript).
• You need strong typing for API contracts but lack time to maintain separate validation layers (e.g., FormRequests + API Resources).
• Your frontend uses TypeScript and you want to auto-generate types from PHP (reduces manual sync errors).
• You’re building scalable APIs where data consistency is critical (e.g., microservices, public APIs).
• Your app has complex nested data (e.g., arrays of objects) that requires validation/transformation.

Look Elsewhere If:

• Your project is small-scale with minimal data contracts (overhead may not justify benefits).
• You’re heavily invested in existing DTO libraries (e.g., php-dto, symfony/serializer) with deep customizations.
• Your team lacks PHP 8.1+ (required for constructor property promotion, used heavily in Data classes).
• You need real-time performance in high-throughput systems (reflection overhead; mitigate with caching).
• Your data structures are highly dynamic (e.g., user-uploaded schemas) and can’t be defined upfront.

How to Pitch It (Stakeholders)

For Executives:

"This package lets us define our app’s data structures once in PHP, then reuse them everywhere—APIs, forms, and even frontend TypeScript. It’s like having a single source of truth for all data, which cuts development time by 30% and slashes bugs from mismatched types. For example, if we update a User model, the API response, frontend form, and validation rules all stay in sync automatically. It’s a no-code solution for consistency, and it’s free to use."

Key Outcomes:

• Faster development: No more copying/pasting fields across layers.
• Fewer bugs: TypeScript and backend types stay aligned.
• Lower maintenance: Change data in one place, not three.

For Engineers:

*"Laravel Data replaces three separate concerns—validation, API serialization, and frontend typing—with a single Data class. Here’s how it works:

• Validation: Define types in the constructor (e.g., public string $email), and the package auto-validates input.
• API Responses: Extend Data and use ->toArray() or ->toJson() for consistent API payloads.
• Frontend Types: Generate TypeScript interfaces from your PHP classes (e.g., SongData → songData.ts).
• Performance: Cache reflection analysis in production for negligible overhead.

Example:

class UserData extends Data {
    public function __construct(
        public string $name,
        public int $age,
        public Email $email, // Custom castable type
    ) {}
}

Now UserData works as:

• A FormRequest (auto-validates).
• An API Resource (serializes to JSON).
• A TypeScript type (auto-generated).

Why Now?

• If you’re tired of maintaining separate FormRequests, API Resources, and manual TypeScript, this consolidates it all.
• Perfect for new APIs or modernizing legacy systems where data consistency is a pain point."

Migration Path:

1. Start with critical data objects (e.g., User, Order).
2. Replace FormRequests/API Resources incrementally.
3. Enable TypeScript generation for frontend teams.
4. Cache structures in production (php artisan data:cache-structures)."