Filter Bundle Laravel Package

Technical Evaluation

Architecture fit — the framework mismatch is the headline. The package is published as metaclass-nl/filter-bundle and named a bundle, which is Symfony's packaging convention, not Laravel's (Laravel uses service providers/packages). Its stated purpose — extending API Platform with richer filter logic — inherits API Platform's Symfony-first DNA (HttpFoundation request objects, Symfony Serializer/Validator, Doctrine ORM query building). API Platform's Laravel integration exists but is a thinner, less mature surface, and third-party filters written against the Symfony filter interfaces are the least portable layer of it. For a Laravel/Eloquent application, the realistic assessment is: this is not a Laravel package and should not be planned as one. Fit is strong only for Symfony + API Platform + Doctrine teams needing OR/AND/nested filter groups beyond API Platform's built-in SearchFilter/FilterInterface primitives.

Integration feasibility. Low for Laravel, moderate for Symfony. Assuming the bundle exposes an ApiPlatform\FilterInterface implementation that parses a query-string filter tree into Doctrine query-builder expressions, adoption on Symfony is a composer require plus a #[ApiFilter]-style attribute or service config — a days-not-weeks integration. On Laravel it would require bridging HttpFoundation semantics, replacing the Doctrine expression compiler with Eloquent/Query Builder, and re-validating every edge case: effectively a fork, not an install. Verify first: supported PHP range, which API Platform major (v3 vs v4 filters changed materially), Doctrine-only vs multi-backend, and whether Eloquent/DBAL adapters exist.

Technical risk — high, driven by adoption signals rather than code quality. 50 stars, 0 dependents, and a low opportunity score (~26) indicate near-zero ecosystem validation: no downstream projects have absorbed the upgrade cost, so breaking changes are unlikely to be caught by anyone but the maintainer. Single-vendor provenance (a Dutch agency) with one likely primary author implies a real bus-factor of one. MIT licensing is a genuine mitigant — the escape hatch is a vendored fork — but forking a filter-expression compiler is nontrivial ongoing ownership. The risk profile is "acceptable as an accelerator on a Symfony project you control; unacceptable as a load-bearing dependency in a Laravel platform."

Key questions for the maintainer or a spike. Which API Platform and PHP versions are tested in CI? Is the filter parser backend-agnostic (ORM/ODB/Elastic) or Doctrine-coupled? Is there a documented filter grammar, and is it stable/public API or incidental? What is the release cadence and who reviews PRs? Are there published benchmarks for deeply nested filter trees (N+1 or query-plan risk)? Is there Laravel/Eloquent support on the roadmap, and would they accept a PR? Does it compose with API Platform's built-in filters or replace them?

Integration Approach

Stack fit. Decision rule: if the target is Symfony + API Platform + Doctrine, this fits and deserves a spike. If the target is Laravel/Eloquent, do not sequence this package into the plan — the integration cost exceeds building the filter grammar in-house, and the dependency's low dependents means you'd own the fork anyway. If the target is API Platform on Laravel, treat it as a research item, not a committed dependency.

Migration path (Symfony path). Adopt behind a thin internal abstraction: define your own FilterCriteria value object and translate to the bundle's input at the boundary, so the bundle is swappable. Pin an exact version (no caret range) and commit the lockfile. Start with read-only list endpoints (search/filter on GET collections) where blast radius is a query, not a write. Expand to nested boolean groups only after the grammar is documented in your own codebase.

Laravel alternative, if the actual need is "filter logic." Use spatie/laravel-query-builder (high dependents, actively maintained) for scope-based filtering, or hand-roll a filter DTO + allowed-fields whitelist compiled to Eloquent scopes. A ~300-line internal implementation with tests is cheaper than maintaining a Symfony bundle port, and it removes the bus-factor risk entirely. This is the recommended default for Laravel.

Compatibility. Confirm API Platform major version alignment before any code is written — filters are among the most churned APIs across API Platform majors, and a mismatch here silently invalidates the whole evaluation. Also confirm whether the bundle requires Symfony DI container features (compiler passes, tagged services) that have no Laravel analogue; those are the hardest parts to port.

Sequencing. (1) Two-day spike: install in a throwaway Symfony/API Platform app, reproduce three real filter requirements from your product backlog, measure query output. (2) Framework decision gate — Symfony yes/Laravel no. (3) If yes: internal abstraction layer + version pin. (4) Production rollout on one endpoint group behind a feature flag. (5) Quarterly re-evaluation of fork-vs-upstream based on release activity.

Operational Impact

Maintenance. The heavy cost is not the dependency, it's the contingency. With 0 dependents, you should budget for the assumption that you will eventually vendor the code: keep your abstraction seam thin, keep the filter grammar documented internally, and record the fork procedure before you need it. Track upstream releases manually — there is no ecosystem signal that will warn you.

Support. No commercial support, no community Q&A depth at 50 stars. Escalation path is a GitHub issue to a single vendor. For a production system with SLAs, that means internal ownership of any bug in the filter compiler, budgeted as a small but permanent maintenance line item rather than a one-off integration cost.

Scaling. The scaling risk is query-plan shape, not throughput: nested boolean filter trees can produce expensive, hard-to-index SQL and are a plausible source of slow-query incidents and N+1s on relation-based filters. Require query logging and cardinality limits (max filter depth, max group count) from day one, plus a hard timeout. Validate against realistic data volumes in the spike — deep nesting on large tables is where this class of library typically degrades.

Failure modes. (a) Silent semantic drift on upgrade — filters compile but return different result sets, the worst failure class for a search API; mitigate with a golden-file test suite of filter-string → expected-SQL/results captured during the spike. (b) Upstream abandonment — mitigated by MIT + vendorable code. (c) Framework lock-in discovered late — mitigated by the Symfony-only gate up front. (d) Unvalidated/user-shaped filter input — confirm the bundle whitelists filterable properties; if not, wrap it.

Ramp-up. Small for a Symfony/API Platform team already fluent in filters and Doctrine — hours to first endpoint. Effectively large for a Laravel team, because the ramp-up is really "learn API Platform's filter interfaces, then rebuild the compiler against Eloquent." Given the low opportunity score and zero dependents, the TPM recommendation is: pursue only on a Symfony/API Platform stack, as a pinned and abstracted accelerator; on Laravel, decline and implement filter logic in-house.