Graphqlite Bundle Laravel Package

Product Decisions This Supports

• API layer strategy (REST vs GraphQL): Supports a build-vs-buy call on GraphQL infrastructure. GraphQLite generates schema/types/resolvers from PHP attributes and annotations, so an existing PHP domain model becomes the API surface without a hand-maintained SDL. This is the "keep the API thin, keep the domain authoritative" option.
• Roadmap timing for public/partner APIs: If a versioned, introspectable API is on the roadmap, schema caching in non-debug environments (v7.6.0) removes a known production performance objection — schema is built once per deploy rather than per request. That is the kind of change that moves a feature from "needs a spike" to "shippable this quarter."
• Platform fit / technology bet: This is the Symfony bundle for GraphQLite, not a Laravel package. For a Laravel codebase the relevant decision is adopting the core thecodingmachine/graphqlite library (framework-agnostic) rather than this bundle. Treat this release as a signal of upstream health, not as a drop-in Laravel dependency.
• Team capacity and hiring: Attribute-driven schema generation lowers the GraphQL-specific skill floor — PHP developers write resolvers in familiar code. Useful when deciding whether to staff a dedicated GraphQL specialist or distribute API work across the existing team.
• Maintenance-risk register: The release is dependency hygiene plus one contributor feature. It tells you the project is maintained (Dependabot, CI, responsive merges) but does not demonstrate active feature investment. Relevant when weighing this against actively-evolving alternatives (Lighthouse for Laravel, API Platform for Symfony).
• Security and dependency posture: Routine bumps to actions/checkout, actions/cache, and setup-php keep CI supply chain current — a small positive input to a vendor security review, not a deciding one.

When to Consider This Package

Consider it when:

• The codebase is Symfony-based (or you're willing to use the framework-agnostic core library in Laravel/custom PHP).
• Your domain is already expressed as PHP services/entities and you want the GraphQL schema to be derived from code, avoiding a parallel SDL that drifts.
• You need authorization, input validation, and pagination conventions handled by the framework rather than re-implemented per resolver.
• You're deploying to production with debug off and want the schema cache benefit — v7.6.0 makes caching the default in non-debug environments, which is the configuration most production apps want.
• Team is PHP-first and you want to avoid a JS/Node GraphQL server as a second runtime.

Look elsewhere when:

• You're Laravel-first and want idiomatic integration — evaluate Lighthouse (SDL-first, native Laravel) before adopting a framework-agnostic library with a Symfony-centric bundle.
• You want SDL-first / schema-first design as a contract with external consumers, or you need schema-as-artifact for codegen pipelines.
• You need federation, subscriptions, or persisted-query tooling out of the box — those are add-on work here.
• Your team is small and unfamiliar with GraphQL concepts generally; the abstraction hides boilerplate but not the underlying model.

On this release specifically: v7.6.0 is additive and non-breaking — schema caching on non-debug environments plus CI dependency bumps. No migration work, no deprecations, no config changes required. It does not change the adoption calculus; it mildly strengthens the production-readiness case.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated GraphQLite as the way to expose our PHP domain as a GraphQL API without maintaining a second schema definition. It lets our existing PHP engineers ship API features in the language they already know, and the latest release (v7.6.0) adds production schema caching — meaning the main performance concern for a live deployment is now handled by the library rather than by custom work. Recommendation: viable for a Symfony codebase; for our Laravel codebase, benchmark it against Lighthouse before committing, since this bundle targets Symfony. Cost is low (open source, MIT-style licensing, no vendor contract); the real cost is GraphQL ramp-up time on the team.

For engineering (the ask): The library generates schema types from PHP attributes, so resolvers live next to the domain code and the schema stays in sync by construction. v7.6.0 caches the schema in every non-debug environment — verify our deploy sets APP_DEBUG=false in staging and production so we get it, and confirm cache invalidation on deploy is wired into our release process. Release is non-breaking; no upgrade work beyond a composer bump.

Risks to name honestly:

• This is the Symfony bundle; adopting it in a Laravel app means using the underlying library and owning the integration glue ourselves — that's ongoing maintenance we'd absorb.
• Recent releases are predominantly dependency maintenance; we should not assume a fast-moving feature roadmap. Budget for contributing fixes upstream or pinning versions.
• Exit cost is moderate: schema-from-attributes means our resolvers become coupled to the library's annotations. Encapsulating resolver entry points keeps that reversible.

Decision requested: Approve a timeboxed spike (1–2 weeks) against our top three API use cases, comparing GraphQLite (core library) with Lighthouse on developer velocity, schema-cache behavior under load, and long-term maintenance burden.