Graphql Laravel Package

Technical Evaluation

Architecture fit — the headline risk is category mismatch. ibexa/graphql is not a Laravel package. It is a Symfony bundle that ships inside Ibexa DXP (formerly eZ Platform), and its own README states the prerequisite plainly: install Ibexa DXP first. The bundle's service providers, DI compiler passes, and schema factories are bound to the Ibexa kernel and content repository — content types, field types, SiteAccess, and the policy/permission layer. There is no service provider contract, no facade, no config stub that a Laravel app can consume. For a Laravel/PHP team the realistic interpretation is a service-boundary integration (Laravel front-end consuming a headless Ibexa GraphQL endpoint over HTTP) or a reference-architecture read (how a mature PHP CMS models its GraphQL schema and resolvers), not a composer require.

Integration feasibility. Two viable paths, one non-viable:

Technical risk. Several compounding signals. The license is dual: Ibexa BUL 2.4 (requires a paid DXP subscription) or GPL-2.0. GitHub reports NOASSERTION, meaning automated compliance tooling will not classify it — that becomes a manual legal review, and if we take the GPL branch, copyleft obligations attach to anything we distribute that incorporates it. The package has 4 stars, 0 dependents, and zero standalone adoption, which tells us nobody consumes this outside the DXP distribution; there is no independent community, no third-party issue corpus, and no external contributor base to fall back on. Version cadence is locked to the Ibexa release train, so our upgrade calendar is the vendor's. The 2026-08-20 last-release date is worth verifying — it is either a forward-dated vendor artifact or a data quality issue in our source, and either way I would not cite it as a maturity signal.

Key questions for the decision review.

1. What is the actual requirement — do we need a full DXP with content modeling, editorial workflow, and multi-site, or do we need a GraphQL API over content we already own? Only the former justifies Ibexa.
2. Is any part of our estate on Symfony, or is this greenfield outside Laravel entirely?
3. Is there budget and appetite for an Ibexa DXP subscription, or would we be operating under GPL-2.0? Who signs off on the copyleft exposure?
4. Does the target schema actually map to Ibexa's content model, or would we spend the project fighting field-type constraints?
5. Who owns schema extensions and resolvers post-launch — us, the vendor, or nobody?

Integration Approach

Stack fit. Assume Laravel 10/11 on PHP 8.2+ and Ibexa DXP on Symfony 6/7 with PHP 8.2+. There is PHP version overlap but no runtime overlap: two applications, two deploy pipelines, two caching layers. The only contract between them is HTTPS + JSON GraphQL. Do not plan for shared Composer vendor trees, shared sessions, or shared Eloquent/Doctrine entities — those are the failure patterns that make this class of integration expensive six months in.

Migration path. There isn't one from Laravel; this is additive infrastructure. Either we adopt Ibexa as a new system of record for content, or we do not adopt it at all. Frame it to stakeholders as a platform selection, not an integration task, or the estimate will be wrong by an order of magnitude.

Compatibility surface to pin explicitly. GraphQL schema snapshot committed to our repo and diffed in CI; authentication model (JWT or token, and how Laravel guards map to Ibexa policies); CORS and trusted-proxy config; HTTP cache and invalidation signaling across the boundary; query depth/complexity limits configured on the Ibexa side before we let the BFF generate arbitrary queries; PHP and DXP minor-version pinning so an unattended vendor patch cannot rearrange the schema under us.

Sequencing.

1. Timeboxed spike, 2–3 days. Stand up Ibexa Open Source, expose the GraphQL endpoint, model two or three real content types from our domain, run representative queries. Output: a schema fit report.
2. Decision gate — commercial and legal. Resolve BUL vs. GPL before any code is written. This gate can kill the initiative; run it first, not last.
3. If proceeding: build a thin Laravel BFF owning auth, caching, and query shaping; contract tests against the committed schema snapshot; observability across the HTTP boundary from day one.
4. If declined: fall back to path C — Lighthouse or webonyx in Laravel over our existing data, using this bundle's schema organization as a design reference only.

Operational Impact

Maintenance. We inherit the vendor's release train on both sides of a version boundary. The GraphQL bundle's version is coupled to the DXP version, which is coupled to a Symfony version, which is coupled to a PHP version — a four-link chain where any link can force an upgrade window. Budget an annual upgrade cycle with a dedicated regression pass on the schema contract.

Support. Commercial support exists only with a paid Ibexa subscription. Under GPL-2.0 we are entirely self-supporting on a codebase with effectively no external community. Bus factor is the vendor. There is no Stack Overflow corpus for this package, no third-party blog coverage, and issues will not be triaged by an independent maintainer group.

Scaling. Two platforms to capacity-plan. The material risks are (a) resolver-level N+1 on the Ibexa side producing request amplification under load, (b) cross-boundary cache invalidation — editorial publish in Ibexa must invalidate Laravel-side caches, and getting this wrong produces stale content that looks like a data bug, and (c) GraphQL query cost: without depth and complexity limits enforced server-side, a single expensive client query can degrade the content repository for all consumers. None of this is documented in the README; all of it is our problem.

Failure modes to instrument for.

• Schema drift on vendor upgrade — silent BFF breakage. Mitigation: committed schema snapshot + CI diff, treated as a failing test.
• License non-compliance discovered late — GPL obligations triggered by distribution after architecture is committed. Mitigation: legal gate at step 2 above.
• Vendor lock-in — content model, schema extensions, and editorial data live in a proprietary format with a paid exit cost. Mitigation: negotiated data export terms up front.
• Auth boundary failures — token expiry and policy mismatches surfacing as intermittent 401/403 for end users.
• PHP/Symfony version divergence — Laravel and Ibexa drift onto incompatible runtimes, blocking co-hosting or shared tooling.
• Zero-community abandonment — package deprecated or made subscription-only with no fallback maintainer.

Ramp-up. The learning curve is Ibexa domain knowledge, not GraphQL: content types, field type constraints, SiteAccess resolution, and the policy model take weeks to become productive in, not days. A Laravel developer without Symfony DI experience will need additional ramp. Plan for two engineers partially allocated for a month before the first production query, and treat any estimate that assumes a one-week integration as unserious.

Recommendation for the review board. Do not approve this as a package integration — the framing is wrong and the risk signals (4 stars, 0 dependents, dual license with NOASSERTION, vendor-coupled release train) do not support it. Approve a 2–3 day spike and a parallel legal/licensing check, with an explicit kill criterion: if we cannot justify adopting Ibexa DXP as a platform, we close this and build our GraphQL layer in-house. The opportunity score of 60.86 reflects an interesting capability inside a product we are not buying; it is not a signal about the package's standalone value to us.