Laravel Resource Reducer Laravel Package

Product Decisions This Supports

• API payload strategy (feature-level): Choosing whether your API supports request-driven field selection and relationship pruning (sparse fieldsets / partial responses) rather than fixed, always-fat resource shapes. This is the core decision the package enables without requiring a rewrite of existing JsonResource classes.
• Build vs. buy on response shaping: The package is a thin, MIT-licensed helper. A PM should frame this as a cheap "buy," but note that the same behavior—conditional field inclusion and relationship dropping—can largely be replicated with native Laravel when() / whenLoaded() and query-string parsing. Decision: adopt to move faster on small teams; build in-house if the selection logic needs to be tied tightly to authorization, caching, or OpenAPI schemas.
• Mobile and bandwidth-sensitive clients: Justifies investment in leaner payloads (smaller responses, faster perceived load times) for mobile-first or low-connectivity audiences, where trimming nested data materially affects UX.
• Third-party / partner API surface: Supports letting integrators opt into exactly the fields and relationships they need, reducing breaking-change blast radius when resource shapes evolve.
• Roadmap sequencing: If field selection is a "nice-to-have" on the roadmap, this package lets you ship a v1 experiment with limited engineering spend and revisit platform-grade solutions (e.g., a query builder or JSON:API-compliant layer) later.
• Performance initiatives: Fits a broader "reduce response size / response time" workstream, though the package addresses serialization overhead, not database/query cost—a PM should not oversell it as a performance silver bullet.

When to Consider This Package

Consider it when:

• You have an existing Laravel codebase with JsonResource / ResourceCollection classes and want per-request field/relationship trimming without invasive refactors.
• You need selective inclusion/exclusion and nested-resource dropping with configurable defaults plus per-endpoint overrides—matching the package's stated fluent, chainable API.
• Your team is small and time-to-ship matters more than ecosystem maturity, and you can accept a low-footprint dependency (46 stars, single patch release, last release 2024-03-13).
• You can validate it in a clean Laravel skeleton first (the v1.1.1 patch only fixed composer.json packaging—confirm autoloading and package discovery behave as expected).

Look elsewhere (or build in-house) when:

• You need JSON:API-spec compliance, standardized fields[] / include semantics, or schema-driven validation—mature alternatives or a dedicated query-builder package are a better fit.
• You require strong maintenance guarantees, active CI, and a supported version matrix; the sparse release history is a supply-chain and bus-factor risk.
• Field-level authorization or caching semantics must be enforced server-side per user/role—selection logic may need to be purpose-built rather than delegated to a presentation helper.
• The core value overlaps heavily with native Laravel conditionals your team already knows; introducing a dependency for marginal convenience adds coupling without proportional benefit.
• You are not on Laravel/PHP or cannot confirm compatible framework and PHP version constraints.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, MIT-licensed Laravel helper that lets our API return leaner, request-shaped responses—clients ask for only the fields and relationships they need—without rewriting existing resource classes. It's a low-cost way to ship a payload-reduction capability on our roadmap faster, with the main trade-off being ecosystem maturity: it's a young package with limited adoption and a thin recent release history. Recommendation: pilot in a non-critical endpoint, measure payload/response improvement, and only standardize if it proves its value and maintainer responsiveness holds.

For engineering (summary): A Composer-installed Laravel package providing a fluent API to selectively include/exclude fields, drop relationships and nested resources, with configurable defaults and per-endpoint overrides—designed to sit alongside existing JsonResource definitions. Adopt as a thin convenience layer, not a platform: validate installation in a clean Laravel skeleton (v1.1.1 corrected a composer.json packaging gap), confirm PHP/Laravel version constraints and package discovery, and pin the version. Treat field selection as presentation-layer logic; keep authorization and query optimization in the application layer. Have a fallback plan—native when() / whenLoaded() conditionals—if upstream maintenance stalls, since the capability is largely reproducible in-house.

Decision ask: Approve a time-boxed pilot on one endpoint, with success criteria (measurable payload-size reduction, no regressions, acceptable maintenance signal) and a defined fallback if the dependency proves fragile.