Symfony Presentation Bundle Laravel Package

Technical Evaluation

Architecture fit The package is a Symfony bundle, not a Laravel package, and that distinction drives the entire evaluation. Its integration surface is Symfony-specific: bundle registration in bundles.php, DependencyInjection/*Extension classes, service tagging, and almost certainly Symfony\Component\HttpFoundation\Request in the query/search layer. Laravel's container, package discovery, and HTTP kernel do not consume any of that. The conceptual model — separating Commands (writes) from Queries (reads) and centralizing filtering, sorting, and pagination into a reusable query object — maps cleanly onto problems every Laravel application eventually has. So the architecture idea fits; the artifact does not.

Integration feasibility Direct composer require into a Laravel codebase is not viable without a compatibility shim, and a shim would mean owning a fork of a three-star package on day one. Realistic options, in order of preference:

1. Pattern adoption (recommended). Reimplement the command/query split and the filter-sort-paginate contract as an internal Laravel package, using spatie/laravel-query-builder or a thin custom implementation for the query side.
2. Conceptual reference only. Read the source for its request-to-criteria translation and reuse the design, not the code.
3. Direct adoption. Only defensible if we already run Symfony services and want a shared query layer across both stacks — and even then, the maintenance profile below is a hard sell.

Technical risk

• License: NOASSERTION. This is a gating item. No declared license means no clear grant to use, modify, or redistribute. Legal review is required before any code is copied, not just installed. For a pattern-only adoption this is largely moot; for code reuse it is a blocker.
• Adoption signal is effectively zero. Three stars, zero dependents, single maintainer organization. There is no community to catch regressions and no upstream roadmap we can lean on.
• Staleness. Last release August 2023. Symfony's DI, HTTP, and serializer components have moved since; version constraints may already conflict with current Symfony releases, which tells us the package is not tracking upstream.
• Query-layer failure surface. A filtering/sorting/pagination engine touches user input directly. Unvalidated sort fields, unbounded page sizes, and filter keys mapping to arbitrary columns are the classic failure modes. We would need to audit and re-test this regardless of provenance.

Key questions

• What is the actual license text, and does Legal permit pattern-level reuse or only clean-room reimplementation?
• Which Symfony versions and PHP versions are supported, and is there a CI matrix proving it?
• Does the query/search engine depend on Doctrine ORM/DBAL, Pagerfanta, or KnpPaginator — and if so, how tightly is persistence coupled to the presentation layer?
• Is filtering driven by an explicit allowlist of fields and operators, or by reflecting over request parameters?
• Is there a test suite we can read to understand intended behavior without running the code?
• Who is the maintainer of record, and is there any commit activity outside tagged releases?

Integration Approach

Stack fit Our target is a Laravel/PHP application. This package assumes Symfony. There is no shared runtime: different container, different HTTP abstraction, different config conventions. We should treat it as a design reference, not a dependency. The transferable assets are the command/query separation, the criteria object (filters + sort + pagination as a value object), and the search endpoint shape.

Migration path There is nothing to migrate from — we are not currently running this bundle. The realistic path is greenfield:

1. Spike (1 week). Read the bundle's source, extract the query criteria contract, and write a one-page design note on what we would keep, change, and drop.
2. Internal package. Build acme/query-kit in Laravel: a QueryCriteria value object, filter allowlist per resource, sort whitelist, and a paginator adapter. Use spatie/laravel-query-builder for the filter/sort mechanics rather than hand-rolling.
3. Command side. If we want CQRS discipline, use Laravel's bus or EventSauce/laravel-command-bus — mature, maintained, Laravel-native.
4. Pilot. Apply to one read-heavy endpoint, measure query counts and response shape, then template it.

Compatibility No version-compatibility work is required under the pattern-adoption path, which is the main reason to prefer it. If someone insists on direct use, they must first prove the bundle installs against our Symfony/PHP constraints — and we have no Symfony runtime to install it into, which settles the question.

Sequencing Licensing review and the source-reading spike run in parallel and gate everything else. Design note and internal package skeleton follow. Pilot endpoint ships behind a feature flag. Only after the pilot do we generalize to a second resource — generalizing from one example is how query layers become over-abstracted.

Operational Impact

Maintenance Under pattern adoption, we own the code we write — a known, bounded cost, and roughly the same effort as forking the bundle but without the inherited baggage. Under direct adoption we inherit a package with a single maintainer, no release cadence, and an unclear license, meaning we fork on day one and carry upstream drift forever. The TCO comparison is not close.

Support No vendor support, no SLA, no security disclosure process visible. Any CVE in the query layer would be ours to find and patch. With zero dependents, there is no chance a third party has already hit and fixed our bug. Budget for internal ownership regardless of path.

Scaling The performance characteristics depend almost entirely on what we build, not on the bundle. The risks to design against: unbounded per_page values enabling trivial resource exhaustion; COUNT(*) on every paginated request against large tables; filters on unindexed columns; and offset pagination degrading badly past deep pages. Mitigations — capped page size, cursor pagination for high-volume endpoints, index review per filterable field — belong in our internal package's contract, not in a post-launch fix.

Failure modes

• Invalid or unknown filter/sort keys causing 500s instead of 422s (allowlist + validation rules).
• Unvalidated sort fields leaking column names or enabling expensive sorts.
• Missing pagination defaults producing full-table responses.
• Coupling query objects to HTTP requests, which makes them untestable and un-reusable from CLI/queue contexts.
• Silent behavior drift if we fork and upstream ever changes — with three stars, unlikely, but a fork still needs a pinned reference commit.

Ramp-up Low for the pattern path: the team already knows Laravel, and spatie/laravel-query-builder needs a day of reading. The CQRS framing needs a short internal brown-bag — the concepts are simple, but teams over-apply them, so pair the rollout with a written rule for when not to introduce a command. The direct-adoption path requires Symfony fluency the team does not currently need, which is a hiring/training cost with no product payoff.

Recommendation: Do not integrate the package. Run the one-week source-review spike, harvest the query criteria design, and build a small Laravel-native internal package. Revisit only if we acquire Symfony services where a shared query layer across stacks becomes a genuine requirement.