Simorgh Laravel Package

Product Decisions This Supports

• Feature scoping for list/index endpoints. The package encodes a convention: HTTP query parameters map directly to Eloquent where/orderBy/with clauses. That makes it a useful reference point when deciding how much of your filtering, sorting, and relation-loading behavior should be generic infrastructure versus hand-written per endpoint.
• API contract design. Adopting any request-to-query library forces you to commit to a query-parameter grammar (filter[status]=active, sort=-created_at, include=comments). That grammar becomes part of your public API surface — it affects documentation, client SDKs, backward compatibility, and how easy it is to add new filterable fields later. This is a product decision, not just a technical one.
• Build vs. buy vs. borrow. The realistic decision here is borrow: read the source, extract the pattern, implement a small internal allowlist-based abstraction, rather than take on the dependency.
• Velocity vs. consistency trade-off. Centralizing filter parsing reduces boilerplate across many CRUD endpoints — relevant if you're shipping admin panels, back-office data grids, or internal dashboards where "sortable/filterable table" is a repeated pattern.
• Roadmap prioritization. Helps answer whether ad-hoc filtering is MVP table stakes or a later enhancement, and whether it belongs in a public API or only behind an internal admin surface.
• Primary use cases: internal admin tools, B2B/partner APIs with data-grid clients, reporting dashboards where consumers need to slice data without new endpoints per query.

When to Consider This Package

Consider it only if:

• The consumer is internal, fully trusted, and you control every client.
• You're willing to vendor/fork the code into your repo and own it — treat it as a code sample, not a dependency.
• You're on a Laravel/PHP version the package actually supports (verify explicitly; a last release of 2020-11-09 predates Laravel 9–11 and PHP 8.2+, so expect to patch it).
• Its out-of-the-box parameter grammar happens to match what you'd have designed anyway.

Look elsewhere when:

• Anything public-facing, multi-tenant, regulated, or long-lived. 11 stars and no release in ~5 years means no security response, no compatibility updates, and no community to catch regressions.
• Query parameters can influence column names, relation names, or operators. Without a strict allowlist this is a data-exposure and injection risk. Prefer spatie/laravel-query-builder (explicit allowedFilters/allowedSorts, actively maintained, well-documented) or tucker-eric/eloquentfilter.
• You need complex boolean groups, nested relation filters, or field selection — the scope outgrows a small package quickly.
• Filtering is trivial — two or three params across a handful of endpoints doesn't justify any dependency.
• You need support SLAs or an upgrade path across Laravel majors.

How to Pitch It (Stakeholders)

To executives: "There's an open-source shortcut for a very common API feature — turning URL filters into database queries — that could save a few days on list and detail endpoints. The catch is that the project has 11 stars and hasn't been updated since late 2020, so we'd be adopting code nobody maintains, including security fixes, on a stack that has moved several major versions since. My recommendation is not to adopt it as a dependency. We'll use it as a design reference and spend roughly a day building a small internal version with strict allowlists that we fully control — same velocity benefit, no unmaintained code in the critical path."

To engineering: "It's convention-over-configuration for request→Eloquent. Before anyone evaluates it further: unmaintained since 2020, unverified Laravel 10/11 and PHP 8.2+ support, no visible test or security posture, and the core mechanic — letting request input drive column and relation names — needs a hard allowlist or it's a liability. The risk-adjusted cost is likely higher than writing a ~150-line trait with allowedFilters/allowedSorts. If we do want a package rather than our own, spatie/laravel-query-builder is the safer, maintained choice."