Filter Manager Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle, not a Laravel package, and the distinction is structural rather than cosmetic. The package implements a filter-manager abstraction for product-list filtering on top of Elasticsearch: filter types are registered as tagged services, a manager service collects active filter definitions per request, and the result is compiled into Elasticsearch query and aggregation DSL via ongr/elasticsearch-bundle and ongr/elasticsearch-dsl. The coupling points are Symfony DI (compiler passes, service tags, configuration tree), HttpKernel request handling, and a specific generation of the ONGR Elasticsearch stack. In a Laravel application, none of that wiring transfers.

Integration feasibility. The portable value is the domain layer: the filter type model (choice, range, boolean, multi-select), the request-to-filter-definition mapping, and the filter-to-DSL compilation with its aggregation handling. That logic is conceptually framework-agnostic but physically entangled with Symfony services. Extracting it is feasible—roughly two to four engineer-weeks to fork, strip the DI/HttpKernel coupling, re-target the DSL layer to a maintained client, and build a test suite around the compilation output. Installing the bundle as a dependency in Laravel is not feasible without also adopting Symfony's container and the ONGR Elasticsearch bundle stack.

Technical risk. High. The last release was May 2022, the repository has 26 stars and zero dependents, and the ONGR Elasticsearch bundles target Elasticsearch versions from the 5/6/7 era. Expected failure surfaces: Composer constraint conflicts against modern PHP and Laravel/Symfony versions, transitive dependencies that are themselves dormant, no security patching path, and a search client pinned to an Elasticsearch major version you likely are not running. The zero-dependents signal is meaningful—it indicates no downstream community is exercising this code against current stacks.

Key questions. Which Elasticsearch/OpenSearch versions does the DSL layer target, and is there a clean seam to swap the client? What are the exact php, symfony/*, ongr/elasticsearch-bundle, and ongr/elasticsearch-dsl constraints? Is OpenSearch supported or only legacy Elasticsearch? Are there known advisories in the transitive dependency tree? Is there any maintainer commitment or funded fork? Which filter types do we actually need—if the answer is "choice and range only," the extraction scope shrinks dramatically and the build-versus-borrow calculus shifts toward build.

Integration Approach

Stack fit. Strong for Symfony 4/5 with Elasticsearch 5/6/7. Weak-to-absent for Laravel 10/11 with Elasticsearch 8 or OpenSearch—a framework mismatch compounded by a client-version mismatch.

Migration path. Three viable routes, in descending order of preference for a Laravel target. First, treat the repository as a reference architecture: read the filter type contracts and DSL compilation, then implement a native filter manager against your existing search client—lowest ongoing cost, highest upfront design effort. Second, fork and extract: vendor the source, remove Symfony DI and HttpKernel coupling, re-target the DSL dependency, publish as an internal package with a Laravel service provider and config file. Third, run it as-is: stand up a small Symfony service exposing filter resolution over HTTP, which preserves the package intact but adds a network hop, a second runtime, and an operational surface for what is fundamentally a query-building concern.

Compatibility. Verify before committing any design: PHP constraint, Symfony major, and the pinned Elasticsearch client. If the package requires a client major you cannot run, extraction is mandatory rather than optional. Isolate any prototype in a throwaway Symfony skeleton so version conflicts do not contaminate the main application's dependency graph.

Sequencing. (1) Prototype in a disposable Symfony app to internalize the filter model and see the generated DSL. (2) Inventory the filter types the product actually needs and cut the rest. (3) Extract the DSL-building layer behind an interface with characterization tests captured from the prototype. (4) Bind that interface to the production search client. (5) Build the configuration and admin surface for filter definitions. (6) Remove the original dependency and record the fork point in the architecture decision log.

Operational Impact

Maintenance. The dominant cost. Upstream is effectively dormant, so adoption means ownership: your team carries dependency updates, Elasticsearch client migrations, and bug fixes. Budget a fork with its own CI pipeline, not a Composer line item.

Support. Community-only with minimal activity; no vendor backing and no realistic path to upstream fixes. Internal documentation and tests become the sole source of truth.

Scaling. The filter manager itself is a thin orchestration layer and will not be the bottleneck. Scaling is governed by Elasticsearch cluster capacity and aggregation cost—high-cardinality facets on large product catalogs are expensive regardless of which library builds the query. Watch aggregation depth and the number of concurrent facet requests per page load.

Failure modes. Silent wrongness is the one that matters: a filter that compiles without error but produces incorrect facet counts or misses documents is far more damaging than a hard failure, and it is easy to ship when the DSL layer is under-tested. Secondary modes include DSL drift across Elasticsearch versions, DI container compilation failures on framework upgrades, and Composer resolution deadlock during routine dependency bumps. Characterization tests on filter-to-DSL output are non-negotiable.

Ramp-up. A senior engineer needs Symfony DI fluency plus Elasticsearch aggregation knowledge—call it one to two weeks to productivity on the codebase, plus the extraction effort on top. If the team has no Symfony exposure, add that to the estimate or prefer the reference-architecture route, which lets engineers work in a stack they already know.