Product Decisions This Supports
- Search API strategy: Decides whether search should be exposed through GraphQL rather than a bespoke REST endpoint. This bundle provides a ready-made GraphQL search schema for Symfony applications already using the
atoolo/search-bundle, reducing API design and implementation work.
- Feature scope for search UX: Supports prioritization of search capabilities such as filters, facets, sorting, pagination, teasers, media/image fields, relative date ranges, “more like this,” boosting, and query explanation. Product can ship these as GraphQL fields rather than commissioning custom backend work.
- Build vs. buy/adopt: A candidate for “adopt” only when the product is already on the SitePark/atoolo stack. It is not a standalone search product; it is an integration layer. If the team is not on that stack, the build/buy calculus shifts toward a broader search platform.
- Roadmap for relevance and content discovery: Features like search boosting, explain support, more-like-this, custom sort criteria, and
minHitCount enable incremental relevance experiments without re-architecting the search API.
- Multisite and content-lifecycle decisions: Supports decisions around rewriter context, URL base paths, archive flags, and navigation-aware teasers—relevant for content-heavy or multisite products.
- Time-to-market trade-off: Can shorten delivery for GraphQL search on an existing atoolo deployment, but creates ecosystem coupling. PM should treat it as an accelerator with an explicit dependency and exit-risk note, not as a strategic platform bet.
When to Consider This Package
Consider it when:
- The product already runs Symfony and the atoolo/search-bundle (or SitePark ecosystem), and search is a near-term roadmap item.
- The team wants a GraphQL-first search interface with filters, facets, sorting, teasers, images, and related-content queries without building the schema and resolvers from scratch.
- Requirements are primarily content search—editorial pages, news, media, navigation-aware teasers—rather than e-commerce, vector/semantic search, or high-scale multi-tenant search infrastructure.
- Engineering can accept vendor/ecosystem coupling and has a plan to fork or replace the bundle if maintenance slows.
- A short pilot is acceptable: validate schema fit, query performance, and upgrade path before committing.
Look elsewhere when:
- The application is not on Symfony/atoolo/SitePark, or search must serve multiple unrelated backends.
- The product needs a standalone search platform (Elasticsearch/OpenSearch, Algolia, Typesense, Meilisearch) with stronger ecosystem support, SLAs, or operational tooling.
- The team needs large community support, broad adoption signals, or third-party implementation partners. This package has very low visible adoption (2 GitHub stars, 0 dependents), so vendor-risk tolerance must be explicit.
- Requirements include vector/hybrid search, advanced NLP, personalization, or multi-tenant SaaS search beyond the bundle’s content-search scope.
- The organization cannot accept a narrowly scoped, vendor-authored MIT package as a critical dependency without a fallback plan.
How to Pitch It (Stakeholders)
For executives: This is a targeted accelerator for teams already using the SitePark/atoolo Symfony stack. It can reduce time-to-market for a GraphQL search API and expose useful search features—filters, facets, teasers, related content, relevance controls—without buying a separate search platform. The license is MIT and the release cadence is active, but adoption is very narrow. Recommend a bounded pilot with clear success criteria and an exit plan, not a platform-level commitment.
For engineering: The bundle extends a Symfony GraphQL interface with search resolvers and schema for filters, sorting, facets, teasers, media, date ranges, boosting, explain, and more-like-this. It is PHP 8.1–8.4 compatible, uses PHPStan level 9, and has E2E coverage. The main concerns are coupling to atoolo/search-bundle, limited external community, and sparse standalone documentation. Treat it as a reusable integration layer: pilot it behind a feature flag, measure query performance and upgrade friction, and document the fork/replacement path before production adoption.