Graphql Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for API surface area. Declarative resource/filter/ordering configuration replaces custom controller and query-builder code. The v1.5.0 additions (enum comparison filters, multi-value string filters, custom orderBy resolver) directly remove the most common reasons teams end up hand-rolling list endpoints, which is the main driver of build-it-yourself cost in an API layer.
• Roadmap sequencing for search/filter UX. Native enum filtering and values-based multi-select string filtering unblock faceted browsing, status/state pickers, and "any of these categories" filters without bespoke query code — a prerequisite for a customer-facing list/filter experience.
• Real-time as a scoped bet, not a platform commitment. Subscriptions via mercure-bundle ^0.2 are now toggleable through configuration. This lets you ship live updates to one surface (e.g., notifications or order status) while keeping the capability dark elsewhere, and it lowers the cost of reversing the bet.
• Extensibility over forking. Resolving list filters from services by class name as service ID, plus custom order resolvers, means product-specific sort/filter logic (relevance, business-defined ranking, permission-scoped ordering) lives in application code rather than a fork — protecting upgrade paths.
• Portability across framework generations. Custom App namespace support for Symfony ^4 deployments reduces migration friction for teams on legacy app structures, which affects timing of a platform upgrade rather than the feature itself.
• Use cases this fits: internal/admin APIs, catalog and inventory list endpoints, multi-tenant back-offices, integration surfaces where filtered/paginated collections are the primary product.

When to Consider This Package

Consider adoption when:

• Your product's core value is collections with filters, sorting, and pagination, and those requirements are still changing — configuration-driven filters absorb churn better than hand-written query code.
• You need multi-value filtering (status enums, tag/category sets) and business-defined sort orders that don't map cleanly to database columns.
• You want optional real-time delivery you can enable per environment or tenant, and can accept a Mercure dependency behind a config flag.
• Your team is PHP-fluent and already on a supported framework version; you value convention over a bespoke API layer.
• You want filters and ordering expressed as services so product rules are testable and injectable rather than buried in controllers.

Look elsewhere when:

• You need GraphQL-first or gRPC-first contracts, or heavy custom transport semantics.
• Your API surface is small and stable (a handful of endpoints) — the abstraction tax outweighs the payoff.
• You require real-time at scale with no additional infrastructure; the Mercure dependency is real operational surface even when disabled.
• The team has no appetite for framework-coupled conventions, or you're mid-migration on an unsupported framework version — the App namespace support helps but doesn't eliminate upgrade coupling.
• You need the underlying mercure-bundle at a newer major line; the pinned ^0.2 constrains what else you can adopt in that stack.

How to Pitch It (Stakeholders)

To executives: This release is incremental but commercially relevant. It moves two frequently-requested capabilities — richer filtering and configurable ordering — from custom engineering work into configuration, and it makes real-time updates a switch we can flip per surface rather than a commitment. Net effect: faster delivery of list/search experiences, less bespoke code to maintain, and a cheaper exit if real-time doesn't prove out. The Mercure ^0.2 pin is a minor piece of technical debt worth tracking but not a blocker.

To engineering: v1.5.0 closes the practical gaps that pushed teams toward custom query builders: enum comparison in custom filters, multi-value string filtering via values on StringComparisonExpression, and an advanced orderBy custom resolver. Filters can now be resolved from the container by class name, so business logic stays injectable and testable instead of forked. Subscriptions are config-toggleable. Two caveats: the Mercure bundle is pinned to ^0.2, so verify compatibility with anything else in that stack, and the Symfony ^4 App namespace support is a migration convenience, not a signal that legacy structures are a long-term target. Recommendation: adopt, pilot real-time behind the flag, and keep custom resolvers thin so upgrades stay cheap.