Graphql Search Bundle Laravel Package

Technical Evaluation

Bottom line up front: this is a Symfony bundle, not a Laravel package. If our target stack is Laravel, the honest framing is that we are not evaluating a drop-in dependency — we are evaluating (a) a potential sidecar/satellite service and (b) a reference implementation of GraphQL search semantics worth mining for our own spec. Both are legitimate, but they carry very different cost profiles, and the decision must be made explicitly rather than drifting into a "just install it" spike.

Architecture fit

• Framework mismatch is the dominant constraint. The artifact ships as a Symfony bundle: it assumes a Symfony kernel, bundle registration, DI container autowiring, and a bundle config tree under config/packages. Laravel's service container, config repository, and package discovery are not compatible surfaces. A Laravel install would require us to hand-port service definitions, re-register resolvers, and own that bridge forever. That bridge is bespoke, untested by the vendor, and unmaintainable by anyone outside our team.
• The bundle is not self-contained. Release notes show a hard dependency chain on atoolo/search-bundle (pinned per release, e.g. 1.13.0) and atoolo/resource-bundle. Logic has been actively pushed down into those packages (PhpLimitIncreaser, EnvVarLoader, BackgroundIndexer moves in 1.0.0). This means the useful behaviour lives below the package we are assessing, and the assessment boundary is really "the Atoolo search stack," not one bundle.
• The GraphQL surface is opinionated toward a specific content model. Types and fields include NewsTeaser, MediaTeaser, kicker, staticImage, symbolicImage, copyright details for images, navigation context (sameNavigation), archive flags, and a urlBasePath rewriter context. This is the schema of a German web-CMS content model, not a generic search document model. If our domain does not resemble it, we inherit a schema we will constantly fight.
• What it does well architecturally. The feature surface is a credible checklist for search-as-an-API: filters (id, archive, template, relative date ranges with base offset), facets with minHitCount, boosting, custom sort criteria (SortCriteriaFactory), spatial sort, moreLikeThis, explain for result analysis, and server-side query execution (1.9.0). That list is genuinely useful as a requirements baseline regardless of adoption decision.

Integration feasibility

Four options, in descending order of commitment:

1. Full adoption (Symfony host). Only viable if the application is Symfony-based. Under a Laravel mandate, this is effectively a re-platforming argument, not a package decision.
2. Sidecar service. Run the bundle inside a minimal Symfony application we own, expose it over HTTP, and have Laravel call it as a search API. Preserves vendor code as-is; introduces a second runtime, a second deploy pipeline, and a network hop in the request path.
3. Reference implementation. Extract the query/facet/filter/boost semantics into our own Laravel GraphQL search layer. Highest engineering cost, lowest long-term coupling, full schema control.
4. Defer. No action; revisit if we move to Symfony or if the Atoolo ecosystem becomes a strategic constraint.

Feasibility is gated on unknowns we cannot resolve from the README: the supported Symfony version range, the concrete composer.json constraints, and which search backend atoolo/search-bundle requires (the domain vocabulary — facets, boosting, explain, spatial sort — strongly implies Elasticsearch/OpenSearch, but this is inference, not confirmed).

Technical risk

• Adoption risk — high. 2 stars, 0 dependents, single-vendor authorship (Sitepark). There is no evidence of production use outside the vendor's own ecosystem. Our "score 23.2 / opportunity 28.97" signal corroborates this: low market validation.
• Vendor-concentration risk — high. All commits in the sampled releases are by vendor staff. There is no external contributor base, no third-party plugins, no community QA. Bus factor is effectively one organisation.
• Schema-churn risk — medium-high. The 1.x line shows repeated renames and removals rather than purely additive change: ariaLabel → accessibilityLabel, actions → teaser features, removal of asset from MediaTeaser, SymbolicImage.url relocated under content, nullable-ised asset.variant. Each of these breaks consumer GraphQL queries or client types. Semver is being respected at the major level, but the minor line is not safe to float.
• Metadata-quality risk — low but worth noting. The "last release 2026-10-08" timestamp is inconsistent with the present and appears to be a clock/timezone/pipeline artifact. Verify the actual release cadence before relying on it as a maintenance-health signal.
• Quality signals — positive. PHPStan level 9, Codecov integration, a cross-repo E2E suite (atoolo-e2e-test), and PHP 8.1–8.4 badges. This is disciplined engineering, and it is the main reason this is a "maybe" rather than a "no."

Key questions to resolve before any commitment

• Which GraphQL server library does the bundle extend, and is that layer independently usable outside Symfony?
• What are the exact composer.json constraints — Symfony version range, atoolo/* pins, PHP floor?
• Which search backend is required, and does it need to be co-located, versioned, or licensed?
• Is there a documented config schema, or is configuration discovery dependent on reading source?
• Does the vendor offer commercial support, or is this MIT-only with no SLA?
• How many 1.x minors contained consumer-breaking renames? What is the observed breaking-change rate per quarter?
• Are there real-world consumers outside Sitepark we can talk to?

Integration Approach

Stack fit

Under a Laravel-first mandate, the fit is poor for direct dependency, acceptable for sidecar, good for reference. I would not approve a plan whose first milestone is "install this via Composer into the Laravel app" — the framework impedance is structural, not cosmetic, and any bridge we write becomes an unowned fork.

Migration path (if pursuing the sidecar option)

1. Spike (timeboxed, throwaway). Stand up the bundle in a minimal Symfony skeleton. Register a single search query end-to-end against the required backend. Exit criterion: a working query returning typed results, plus a written inventory of every config key and backend dependency. If the spike cannot reach a running query within the timebox, stop — the cost curve is worse than it looks.
2. Contract definition. Extract the subset of the schema we actually need. Do not adopt the full type surface; teasers, kickers, and imagery resolvers are CMS-specific and most will be dead weight.
3. Sidecar hardening. Containerise, add health checks, define the Laravel-side client with timeout/retry/circuit-breaking, and pin the bundle version exactly (no caret ranges across minors, given the rename history).
4. Shadow traffic. Mirror production search requests to the sidecar, compare result sets and latency against the incumbent. Exit criterion: acceptable relevance parity and p95 latency on our real query mix.
5. Cutover behind a feature flag, with the incumbent retained as a fallback path for a defined bake period.

Compatibility

• Pin PHP to a version the bundle actively tests (8.2/8.3/8.4). Note the README's own caveat that PHP 8.1 is "no longer checked automatically" — treat 8.1 as unsupported and do not let our platform floor drift there.
• Pin atoolo/graphql-search-bundle exactly, and pin its atoolo/search-bundle transitively. Composer-level flexibility is a liability here.
• Budget for a second runtime: separate base image, separate CVE patching, separate observability stack.

Sequencing

Discovery/spike → schema subset decision → sidecar build → contract tests in CI → shadow compare → flagged cutover → bake → decommission incumbent. The load-bearing gate is between step 1 and 2: if the spike reveals the backend requirement is operationally expensive, the whole option should be re-evaluated against "build it ourselves in Laravel," which at that point may be cheaper.

Operational Impact

Maintenance

• We would own the Symfony runtime, the container config, and the sidecar deployment — none of which comes from the vendor. Steady-state cost is dominated by our bridge code, not by the package.
• Upgrade cadence is dictated by the vendor's release train, which is brisk (roughly ten minors from 1.0 to 1.10 in the sampled window). Each minor must be diffed for renames before adoption.
• Mitigation: a mandatory contract-test suite that pins our GraphQL queries against a known-good response shape, run in CI on every dependency bump. Without this, schema drift will reach production as a front-end outage.

Support

• MIT, self-supported. No SLA, no support portal indicated, no external community to lean on. Practically, when we hit a bug, the resolution path is (a) upstream issue with no leverage, or (b) we patch. Budget for fork maintenance as a realistic contingency, and identify an owner before adoption rather than after.
• Knowledge concentration: only the vendor knows the Atoolo content model. Plan for one engineer to become the designated owner.

Scaling

• Search is read-heavy and latency-sensitive. The bundle's server-side query execution feature (1.9.0) is the key scaling lever — it shortens the round-trip chain and reduces client-side fan-out, and should be evaluated early as a performance instrument.
• Facets are the classic cost trap: a query requesting many facets with low minHitCount thresholds can fan out into expensive backend aggregation. Add query-complexity limits and per-query cost budgets at the API edge, not inside the bundle.
• Layered caching: persisted GraphQL queries, response caching keyed on normalised query + facet tuple, and warm-up for high-traffic queries.
• The sidecar adds one network hop and one failure domain; both must be reflected in our SLOs, not treated as free.

Failure modes

Ramp-up

• Two distinct learning curves stack: Symfony DI + bundle config, and the Atoolo search domain model (teasers, kickers, navigation context, rewriter context). The GraphQL semantics themselves are conventional and will be quick for anyone who has built a search API.
• Realistic estimate: one senior PHP engineer, ~2 sprints to the point of a confident spike outcome, and 3–4 sprints to a production sidecar with contract tests and shadow comparison. Flag these as planning ranges, not commitments, pending the key-questions answers.
• Under the "reference implementation" option, ramp-up is cheaper (no Symfony or Atoolo learning) but the build is longer, because we reimplement facets, boosting, and sort criteria ourselves.

TPM recommendation

Do not adopt as a Laravel dependency. Proceed with a timeboxed spike for the sidecar option only if the key questions resolve favourably on Symfony version range, backend requirements, and the presence of at least one non-vendor production consumer. In parallel and unconditionally, harvest the schema and feature inventory — filters, facets with minHitCount, boosting, custom sort, moreLikeThis, explain, relative date ranges, server-side execution — as our own search-API requirements baseline. That extraction is the real leverage in this package, and it is available to us whether or not we ever run a line of its code.