Weave Code
Graphql Laravel Package
ibexa/graphql
GraphQL server implementation for Ibexa DXP and Ibexa Open Source, providing a query API for content and platform data. Part of the Ibexa DXP package family.
At a glance
Frequently asked questions about Graphql
- Can I install ibexa/graphql in a Laravel app with Composer?
- No. ibexa/graphql is not a Laravel package; it is a Symfony bundle that ships inside the Ibexa DXP distribution. Its service providers, DI compiler passes, and schema factories are bound to the Ibexa kernel, content repository, content types, field types, SiteAccess, and policy layer. There is no Laravel service provider contract, facade, or config stub to publish, so a composer require into a Laravel application is not a viable path.
- What is ibexa/graphql actually used for?
- It provides a GraphQL server implementation for Ibexa DXP and Ibexa Open Source, exposing a query API over content and platform data. It lets you query content items, content types, and related platform structures through a schema maintained by Ibexa. The package is one component of the wider Ibexa DXP package family rather than a standalone library.
- What are the prerequisites for installing ibexa/graphql?
- The README states the prerequisite plainly: install Ibexa DXP first, and this package comes as part of that distribution. In practice that means running a Symfony 6 or 7 application on PHP 8.2 or newer alongside the Ibexa kernel and content repository. There is no supported way to install it into an application that is not an Ibexa instance.
- How do I consume an Ibexa GraphQL endpoint from a Laravel front end?
- Treat it as a headless service boundary: Laravel talks to Ibexa over HTTPS plus JSON GraphQL and nothing else. Plan authentication explicitly, typically a JWT or token that maps your Laravel guards onto Ibexa policies, and configure CORS and trusted proxies on the Ibexa side. Do not plan for shared Composer vendor trees, shared sessions, or shared Eloquent and Doctrine entities, because those assumptions are what make this class of integration expensive later.
- Does ibexa/graphql support Laravel 10 or Laravel 11?
- There is no runtime integration with any Laravel version. The only overlap is PHP 8.2+ compatibility, since Laravel and Ibexa run as two separate applications with separate deploy pipelines and caching layers. The realistic model is a Laravel application calling an Ibexa GraphQL endpoint over HTTP, not a package installed inside Laravel.
- What license does ibexa/graphql use and what are the implications?
- The code is dual licensed under the Ibexa Business Use License 2.4, which requires a paid Ibexa DXP subscription, or GPL-2.0. GitHub reports the license as NOASSERTION, so automated compliance tooling will not classify it and you should expect a manual legal review. If you take the GPL branch, copyleft obligations attach to anything you distribute that incorporates the code, so get explicit sign-off before building on it.
- Is ibexa/graphql actively maintained and safe to use in production?
- Maintenance follows the Ibexa release train, so your upgrade calendar becomes the vendor's calendar. The repository has very low standalone adoption, roughly 4 stars and 0 dependents, which means there is no independent community, third-party issue corpus, or external contributor base to fall back on. Production support realistically comes from an Ibexa DXP subscription rather than from open source community activity.
- What are the alternatives if I want GraphQL in a Laravel application?
- For a Laravel-native GraphQL layer, look at Lighthouse, which integrates directly with Eloquent, or webonyx/graphql-php if you prefer to define the schema by hand. Those options keep you inside one runtime and one deploy pipeline. Ibexa GraphQL only makes sense if you have separately decided to adopt Ibexa DXP as your content platform.
- Can I reuse Ibexa's GraphQL schema and resolver patterns without adopting the platform?
- Yes, and it is the only low-effort way to leverage this package from a Laravel codebase. Treat it as reference architecture: study how a mature PHP CMS models content types, field types, SiteAccess, and its policy and permission layer in a GraphQL schema. You can then apply those patterns to your own Lighthouse or webonyx implementation without inheriting the Symfony or Ibexa kernel coupling.
- How should I test and version the contract between Laravel and an Ibexa GraphQL backend?
- Commit a GraphQL schema snapshot to your repository and diff it in CI so vendor-side schema changes surface as failing builds rather than production incidents. Add contract tests that exercise the specific queries and mutations your Laravel application depends on, and run them against a staging Ibexa instance. Also pin your authentication model, CORS and trusted-proxy configuration, and cache invalidation signalling, since those are the parts most likely to break silently across releases.
Weaver
How can I help you explore Laravel packages today?