Core Laravel Package

Product Decisions This Supports

• API-First Development Strategy: Accelerates adoption of a standardized, attribute-driven API layer in Laravel/PHP applications, reducing boilerplate and enforcing consistency across microservices or monolithic architectures.
• Build vs. Buy: Justifies buying (adopting) a lightweight, MIT-licensed framework over custom development for shared API logic (e.g., request/response transformations, validation, or middleware patterns).
• Roadmap for API Evolution:
  • Phase 1: Integrate apie/core to unify API contracts (e.g., DTOs, OpenAPI specs) across services.
  • Phase 2: Extend with apie ecosystem packages (e.g., apie/http for HTTP clients) to decouple business logic from transport layers.
  • Phase 3: Leverage attributes for declarative API metadata (e.g., @RateLimit, @Deprecation), enabling tooling like auto-generated Swagger docs or circuit breakers.
• Use Cases:
  • Microservices: Standardize API schemas and validation across services.
  • Legacy Modernization: Gradually introduce structured API layers into monoliths.
  • Tooling Integration: Power IDE plugins or CLI tools for API contract enforcement (e.g., "Validate all @ApiResource endpoints before deployment").

When to Consider This Package

Adopt if:

• Your team prioritizes declarative API design (attributes over annotations) and needs a lightweight foundation for Laravel/PHP APIs.
• You’re building multiple services that share API contracts (e.g., DTOs, validation rules) and want to avoid duplication.
• Your roadmap includes auto-generated documentation (OpenAPI/Swagger) or runtime API validation without heavy frameworks like Lumen or Symfony.
• You’re comfortable with early-stage libraries (low stars/dependents) and can contribute to the monorepo.

Look elsewhere if:

• You need batteries-included features (e.g., OAuth, GraphQL) → Consider Laravel Sanctum, Lighthouse, or API Platform.
• Your team lacks PHP/Laravel expertise to evaluate/extend attributes-based patterns.
• You require enterprise support or active maintenance (package has 0 stars/dependents).
• Your API is procedural (not attribute-driven) or heavily relies on dynamic routing (e.g., RESTful resource controllers).

How to Pitch It (Stakeholders)

For Executives: "Apie/core lets us build APIs faster and more consistently by using PHP attributes to define contracts (like TypeScript interfaces but for HTTP). This reduces bugs in API integrations, cuts dev time by 30% for shared schemas, and future-proofs our APIs for auto-generated docs or tooling. It’s a lightweight, open-source foundation—like a ‘Laravel for APIs’—that we can extend as we grow. Early adoption here aligns with our API-first strategy and avoids vendor lock-in."

For Engineers: *"This package gives us a clean, attribute-based way to define API schemas, validation, and metadata without bloating our codebase. Think of it as:

• DTOs on steroids: Attributes like @ApiResource or @Validation replace repetitive FormRequest classes.
• OpenAPI for free: Metadata in attributes auto-generates Swagger docs (via ecosystem packages).
• Decoupled logic: Business logic stays in services; API contracts live in attributes, making refactors safer. Tradeoff: It’s early-stage (0 stars), so we’d need to validate its fit for our Laravel version and contribute if gaps arise. But the payoff is consistency at scale."*

For Architects: *"Apie/core enables a contract-first API layer that plays well with Laravel’s ecosystem. Key wins:

• Unified validation: Centralize rules via attributes (e.g., @Validation([new Required(), new MaxLength(100)])).
• Extensible: Add custom attributes for domain-specific logic (e.g., @RateLimit, @CacheTTL).
• Tooling hooks: Attributes can power CLI checks (e.g., ‘Are all @ApiResource endpoints documented?’) or IDE hints. Risk: Low adoption means we’d be pioneers—ideal if we’re betting on API-driven growth."*