Graphql Laravel Package

Product Decisions This Supports

• Headless / API-first delivery strategy. This bundle exposes Ibexa DXP content (content types, locations, fields, search, users) through a GraphQL server. That directly supports the decision to serve web, mobile, kiosk, partner portals, and SPA frontends from one content platform instead of building bespoke REST endpoints per channel.
• Build vs. buy for the API layer. The default decision this package argues for is buy/inherit: if Ibexa DXP is already the CMS, the GraphQL server is a vendor-maintained capability rather than a 3–6 month internal API project. If Ibexa is not already in the stack, this package does not make the decision — it is not a standalone GraphQL library.
• Frontend framework and team-topology choices. A stable GraphQL contract lets frontend teams (Next.js/Nuxt/React Native, agency partners) work independently of PHP delivery cycles, and lets you evaluate composable/DXP frontends without re-platforming content.
• Roadmap sequencing for decoupling. Useful as the enabling layer for a phased migration: keep Ibexa as the content system of record, introduce GraphQL for new channels first, and defer a full CMS replacement. It de-risks "re-platform" into "re-interface."
• Integration product decisions. Content syndication to partners, marketplaces, and internal tools can be scoped as GraphQL consumer work rather than custom export jobs — a cheaper, more reusable pattern for B2B/partner-facing products.
• Licensing and commercial-model decisions. The dual license (Ibexa Business Use License for DXP subscribers, GPL-2 otherwise) is itself a product constraint: it forces an explicit decision on subscription tier vs. accepting copyleft obligations, and should be surfaced in any build-vs-buy business case.
• Mobile/app roadmap. If a native app is on the roadmap, this is the cheapest credible content API path when Ibexa is already licensed — avoid committing to a parallel CMS or a custom BFF prematurely.

When to Consider This Package

Consider it when:

• You are already running Ibexa DXP (Enterprise) or Ibexa Open Source. The README is explicit: install Ibexa DXP first. This bundle is an add-on to that platform, not a general-purpose package.
• You have (or will buy) an Ibexa DXP subscription, making the Business Use License the operative terms; or you are prepared to accept GPL-2 copyleft obligations for the Open Source path.
• Your product needs a read-heavy content delivery API across multiple channels, and you want it maintained by the platform vendor rather than your team.
• You want schema-level predictability for frontend contracts (GraphQL introspection, typed queries) more than maximum query flexibility.
• You are standardizing on the Ibexa ecosystem and value vendor support, upgrade alignment, and documentation continuity over community momentum.

Look elsewhere when:

• You are on vanilla Laravel / any non-Ibexa stack. Use Lighthouse (or Nuwave) — this package provides no value without the Ibexa content repository underneath.
• You need a general GraphQL server, federation, or schema-stitching layer. This is a content-domain server, not an API gateway.
• Community support and ecosystem breadth matter. Signals are weak: ~4 GitHub stars, 0 dependents, low composite score. There is no第三方 plugin ecosystem, no Stack Overflow corpus, and hiring for Ibexa GraphQL experience is a narrow market.
• License clarity is a blocker. License is reported as NOASSERTION; the real terms are a dual BUL/GPL-2 arrangement. Any legal review must treat this as non-standard and confirm the subscription path before architecture is locked.
• You need write/mutation-heavy or transactional APIs, or real-time subscriptions at scale — validate against the bundle's supported schema before assuming parity with a purpose-built GraphQL layer.
• Vendor lock-in is unacceptable. Adopting this deepens dependence on Ibexa's content model, release cadence, and commercial relationship.
• You require active independent maintenance evidence: single-vendor stewardship, low visibility, and a release date that is hard to corroborate against a public changelog warrant a support-contract check first.

How to Pitch It (Stakeholders)

For executives (one paragraph): Ibexa GraphQL is the API front door to our content platform. If Ibexa DXP is already in our stack — or is our chosen CMS — it lets us expose content to web, mobile, and partner channels without funding a custom API build, and it keeps that API maintained and upgraded by the vendor instead of by us. It is not a standalone purchase: it has no value without the Ibexa platform, and its licensing runs through the Ibexa subscription or GPL-2. The recommendation is to treat it as an included capability to exploit, not a new product decision — approve it as the standard content API for new channels conditional on confirming our Ibexa license tier and legal sign-off on the dual-license terms.

For engineering (the honest version):

• Scope: a GraphQL server implementation bound to the Ibexa content repository, shipped as an Ibexa DXP bundle. Requires Ibexa DXP installed; it will not install or function meaningfully in a plain Laravel app.
• Integration: bundle registration, schema exposure over Ibexa content types/locations/search, auth aligned to Ibexa permissions. Expect work in schema design and query-cost/rate limiting, not in server plumbing.
• Maturity caveats: very low external adoption (~4 stars, 0 dependents), single-vendor maintenance, license string reported as NOASSERTION with dual BUL/GPL-2 text. Pin versions, read the changelog per release, and budget for vendor support rather than community answers.
• Alternatives to name explicitly: Lighthouse/Nuwave for generic Laravel GraphQL; a thin custom BFF if we need to aggregate non-Ibexa services; REST/Content API if GraphQL's flexibility isn't earning its complexity.
• Ask: a one-week spike validating schema coverage against our top 10 frontend queries, plus a legal confirmation of license path, before committing it to a channel roadmap.