Eloquery Laravel Package

Product Decisions This Supports

• API contract standardization. The package encodes a single convention for the five query-parameter families every list endpoint eventually needs — filter, sort, paginate, eager-load, and search. That makes it a useful specification artifact for deciding how our own endpoints should behave (syntax, defaults, validation, error responses) before we commit to an implementation.
• Build vs. buy scoping. Because it is small, MIT-licensed, and self-describing, it gives engineering a concrete baseline to estimate against: "adopt, fork, or build in-house" becomes a scoped decision rather than an open-ended spike. A PM can use it to price the cost of not standardizing query handling.
• Feature and roadmap framing. List/filter/search UX is consistently under-scoped in roadmaps. This package makes the work visible as a reusable platform capability instead of bespoke work repeated per resource — useful when arguing for a "list API foundation" line item.
• Design reference for prototyping. For internal admin dashboards, back-office tooling, and early public API endpoints, it can accelerate prototypes and validate the parameter shape with consumers before we invest in a maintained implementation.
• Consistency trade-off decisions. It exposes the classic tension between per-endpoint flexibility and platform uniformity (e.g., which fields are filterable, whether pagination is always on, how eager-loading is exposed to clients), which is a governance decision, not just an engineering one.

When to Consider This Package

Consider adoption (or, more realistically, vendoring/forking) when:

• You need a lightweight, opinionated convention for list endpoints and want to move fast on an internal or low-risk surface.
• Your team is comfortable owning the code: the MIT license permits forking, and the scope is small enough to audit.
• You are evaluating patterns and want a reference implementation to compare against spatie/laravel-query-builder before standardizing.
• Requirements are simple and stable: basic filtering, sorting, pagination, eager-load whitelisting, and keyword search.

Look elsewhere when:

• You need a maintained dependency. The repository is archived with 4 stars and 0 dependents — treat it as unmaintained code, not a supported library. No security patches, no Laravel version guarantees, no issue triage.
• You require support, SLAs, or a security review trail. There is no vendor, no release cadence, and effectively no community signal to lean on.
• You have complex query needs (nested/relationship filters, saved queries, aggregates, cursor pagination, authorization-aware field exposure). A mature, actively maintained alternative or a purpose-built internal layer is the better bet.
• You're exposing public APIs at scale, where input validation, DoS-resistant query limits, and documented contracts matter more than convenience.
• Your organization mandates maintained dependencies — in which case this is a design input only, never a production dependency.

How to Pitch It (Stakeholders)

To executives: This is a small open-source utility that defines a consistent way for our APIs to accept filtering, sorting, pagination, eager-loading, and search parameters. The package itself is archived and essentially unmaintained, so we are not proposing a dependency or a vendor relationship — we are proposing to use it as a low-cost design reference and, if we proceed, to own a small fork internally under its permissive MIT license. The business value is consistency: every list endpoint behaves the same way, front-end and integration work gets cheaper, and we avoid re-litigating query conventions per feature.

To engineering: It's a compact reference implementation of the query-parameter layer we keep rebuilding. Adoption is a build-vs-fork-vs-buy call: because it's archived with negligible adoption, treat it as a starting point or a pattern source rather than a library to depend on. Forking or reimplementing gives us the same conventions with the maintenance and security posture we actually control.