- Can I use overblog/graphiql-bundle in a Laravel application?
- No. This is a Symfony bundle that relies on Symfony bundle registration, the DI container, and a Flex recipe, none of which Laravel provides. Making it work in Laravel would require a shim service provider that reimplements routing, config loading, and asset publishing, which is throwaway code with no upstream support. For Laravel, use mll-lab/laravel-graphiql, Lighthouse's built-in IDE, or a static GraphiQL or Apollo Sandbox page instead.
- What does overblog/graphiql-bundle actually do?
- It adds the GraphiQL in-browser GraphQL IDE to a Symfony app and serves it at /graphiql. It does not run GraphQL, parse schemas, or manage resolvers; it renders the GraphiQL single-page UI and points it at your GraphQL endpoint. Treat it as dev tooling, not a runtime dependency.
- How do I install overblog/graphiql-bundle in Symfony?
- Install it as a dev dependency with composer require --dev overblog/graphiql-bundle. With Symfony Flex, accept the recipe from symfony/recipes-contrib, configure your GraphQL endpoint, then open /graphiql. For Symfony Standard, enable the bundle only in the dev and test sections and import the routing resource in routing_dev.yml.
- Do I need Twig to use this GraphiQL bundle?
- Yes, if your project does not already have Twig, the README says to install it with composer require twig. If Twig is used only for GraphiQL, add --dev so it does not become a production dependency. This is another sign the bundle is intended for development environments.
- How do I configure the GraphQL endpoint that GraphiQL connects to?
- The Flex recipe adds a config block where you set the GraphQL endpoint path, typically the route exposed by overblog/graphql-bundle. The bundle only serves the UI; schema ownership, resolver wiring, and endpoint routing stay with your GraphQL server. Confirm the endpoint URL and route name match what your app actually exposes.
- Is it safe to enable /graphiql in production?
- No. An interactive IDE plus introspection exposes schema shape and query surface, which is high-value reconnaissance for attackers. Keep the bundle dev-only by registering it only in dev and test, and restrict the route by environment, IP allowlist, or auth if it must exist elsewhere. If you have a strict Content-Security-Policy, confirm whether assets are bundled locally or loaded from a CDN. Control this by policy rather than trusting defaults.
- Which Symfony and PHP versions does overblog/graphiql-bundle support?
- The package is on 0.x semver, so check the exact Symfony and PHP constraints in its composer.json before adopting it. It fits Symfony 6 and 7 shops well, but do not assume support outside the declared matrix. Pin the version explicitly because minor bumps may include breaking changes.
- What are the best Laravel alternatives to this Symfony GraphiQL bundle?
- For Laravel, use mll-lab/laravel-graphiql, Lighthouse's built-in GraphQL IDE, or a static GraphiQL or Apollo Sandbox page served from a Blade view or CDN. A local-only npm script is also cheaper than porting this bundle. All of these use native Laravel conventions and are easier for your team to support.
- Does this bundle support GraphiQL 2 or 3 features like subscriptions and @defer?
- The bundle ships and binds a specific GraphiQL JavaScript version, so newer UX and features such as subscriptions or @defer and @stream may be unsupported until upstream bumps the assets. This is the most likely source of it does not quite work issues. Verify the bundled GraphiQL version against your schema needs before relying on it.
- Is overblog/graphiql-bundle actively maintained and safe to depend on?
- Adoption signals are weak: it has around 76 stars, zero dependents, single-vendor ownership, and a README that still shows a deprecated Travis CI badge. It is MIT licensed and legally clean, but the bus factor is effectively one. Pin an exact version, expect breaking changes on minor releases, and budget for upgrade work yourself.