Product Decisions This Supports
- Flexible read APIs without a GraphQL server. Requent lets a client shape an Eloquent response at request time — selecting fields, filtering, sorting, paginating, and controlling eager-loaded relations — using a query-string-style interface. This supports decisions like "do we build a full GraphQL layer, or expose a lighter, request-driven query contract?"
- Feature scoping for mobile/web clients. When different clients need different payload shapes (thin lists vs. rich detail views), Requent supports a single endpoint that adapts per request, reducing the number of bespoke REST endpoints a team must design and maintain.
- Build-vs-buy for data-access layers. It is a candidate in the "adopt OSS" bucket versus building an in-house query filter/selection layer or adopting a maintained alternative. The decision hinges on whether the flexibility outweighs the maintenance and security review cost.
- Roadmap input for internal tools and prototypes. Strongest fit for internal dashboards, admin panels, and early-stage APIs where speed of iteration matters more than long-term maintenance guarantees.
- API contract/security policy decisions. Because client-supplied parameters map directly onto Eloquent queries, this package forces an explicit product decision about whitelisting allowed fields/filters/relations — i.e., what data a client is permitted to request. That is a governance decision, not just an engineering one.
- Vendor lock-in assessment. MIT-licensed, self-contained, and no runtime dependents, so the reversibility cost of trying it (and later replacing it) is low — useful when deciding whether a spike is worth it.
When to Consider This Package
Adopt or evaluate Requent when:
- You are on (or targeting) an older Laravel 5.x-era codebase where the package's assumptions still hold.
- You need GraphQL-like read flexibility (sparse fieldsets, filtering, pagination) but do not want the schema/operational overhead of a full GraphQL stack.
- The use case is internal, low-blast-radius, or prototype — admin tools, internal APIs, or a time-boxed spike.
- Your team is comfortable owning the code (pinning, vendoring, or forking) rather than relying on upstream releases.
Look elsewhere when any of the following are true:
- Modern Laravel/PHP. Last release was June 2017; Laravel and PHP have changed substantially since. Expect compatibility work.
- Production or externally exposed APIs. With 0 dependents, 78 stars, and no releases in ~8 years, there is effectively no active maintenance, security patching, or community support.
- Security-sensitive data. Request-driven Eloquent mapping is a classic vector for over-fetching and unauthorized field/relation access; without strict whitelisting this is a liability.
- A maintained alternative fits. For flexible filtering/sorting/includes, prefer actively maintained packages such as Spatie's Laravel Query Builder; for full GraphQL, prefer a maintained server (e.g., Lighthouse); for response shaping, Laravel API Resources may suffice with zero added dependency.
How to Pitch It (Stakeholders)
To executives: Requent is a small, MIT-licensed utility that lets a single API endpoint adapt its response to what each client asks for — selecting fields, filtering, and paginating Eloquent data — similar in spirit to GraphQL but far lighter. It could accelerate delivery of internal tools and client-flexible APIs and reduce the number of one-off endpoints we build. The material caveat is maintenance risk: the package has not been released since 2017 and has no downstream dependents, so it is effectively unmaintained. My recommendation is to treat it as a low-cost, reversible experiment or internal-only tool — not a foundation for customer-facing production APIs — and to gate any use behind a security review of what fields and relations clients may request.
To engineering: This is a request-to-Eloquent mapper with a GraphQL-like interface and built-in data transformation, under MIT. It buys flexibility and speed but costs you ownership: no upstream maintenance, no security patches, and compatibility gaps against modern Laravel/PHP. If we proceed, pin it, vendor or fork it, and enforce a strict allowlist of selectable fields, filters, and relations at the boundary. Before committing, we should benchmark it against maintained options (Spatie Laravel Query Builder for filtering; Lighthouse if we actually want GraphQL) and confirm it does not become a one-way door. The upside is genuine reversibility — small surface area, permissive license, and zero dependents mean we can replace it cheaply if it disappoints.