Graphql Laravel Package

Product Decisions This Supports

• Build vs. buy for the internal service-to-service API layer. This bundle is the "buy (cheap)" option for connecting microservices over GraphQL: it packages schema definition, remote schema consumption, and query/mutation transport so teams don't hand-roll a client per service. It supports a decision of "adopt a thin, standards-based GraphQL contract across services instead of bespoke REST endpoints per integration."
• Standardizing the contract between services. GraphQL's typed schema is the real product value here — it gives a single, introspectable contract that lets a consuming team request exactly the fields it needs without negotiating new endpoints with the owning team. That directly reduces cross-team coordination cost, which is a roadmap-level lever, not a code-level one.
• Reducing payload over-fetching on chatty service calls. If services currently exchange fat JSON payloads across several round-trips, GraphQL aggregation is a defensible feature decision to consolidate those calls.
• Fork-and-vendor as a strategic option. With an MIT license, the code can be vendored into an internal package if the architecture is useful but the maintenance isn't. That makes this a legitimate reference implementation purchase even if the package itself is never installed as a dependency.
• Use cases it plausibly fits: internal BFF/aggregation layer in a Symfony-based microservice fleet; a schema-first contract for a small number of services where the owning team controls both ends; prototyping a GraphQL boundary before committing to a heavier platform.
• What it does not support: it is a Symfony bundle, not a Laravel package. It does not give you a Laravel-native GraphQL server, Eloquent integration, auth/policy integration, or an HTTP endpoint for browser clients. Do not let it into a Laravel roadmap as "our GraphQL layer."

When to Consider This Package

Adopt only when all of these hold:

• You are already inside the Garlic microservices ecosystem and need to speak its existing GraphQL conventions — interop, not architecture, is the reason.
• Your service layer is Symfony, not Laravel.
• You are comfortable pinning to a 2019-era, unmaintained release and can accept ownership of upgrades, security patches, and PHP/Symfony version drift yourself (last release 2019-12-23; 3 stars; 0 known dependents).
• The blast radius is internal and low-stakes: no untrusted client traffic, no public schema, no multi-tenant authorization boundary.
• You have a named internal owner and a documented exit path (fork, or replace with a maintained client).

Look elsewhere when:

• Any Laravel application is the consumer or producer. Use webonyx/graphql-php directly, or Lighthouse for a Laravel-native server; use Symfony HttpClient / Laravel HTTP client for plain service calls.
• You need a maintained dependency. Three stars and zero dependents means no community to absorb a breaking change; the score of 0.145 is consistent with that. Treat it as abandoned code.
• You need the public-facing GraphQL API surface (persisted queries, batching, query depth/cost limits, federation). Nothing here provides that at a standard you'd want to defend in a security review.
• You need schema federation or stitching at scale. Prefer Apollo Federation/GraphQL Mesh or an API gateway — better maintained, better documented, and easier to hire for.
• You don't actually need GraphQL. If calls are one-to-one and stable, gRPC or plain typed REST is cheaper to operate and easier to observe.

How to Pitch It (Stakeholders)

For executives: This is a small, permissively licensed (MIT) integration helper for GraphQL between microservices inside one specific vendor ecosystem. It is not a strategic dependency: three GitHub stars, no known downstream users, and no release since December 2019. Recommendation is do not adopt as a platform dependency. The realistic value is architectural — a compact reference for how to expose and consume a typed GraphQL contract between services — and that value can be captured by reading or forking the code at essentially zero cost and zero vendor lock-in. If we pursue GraphQL as a service contract, we should budget for a maintained stack (Lighthouse/webonyx for PHP-Laravel, Federation or a gateway if we go multi-team) rather than treating this bundle as the foundation.

For engineering: It's a Symfony bundle aimed at Garlic's own service mesh, so it doesn't drop into our Laravel apps and provides no Eloquent, policy, or HTTP-endpoint integration. It's unmaintained since 2019 — assume no upstream fixes, plan to vendor/fork if we use any of it, and don't let it near client-facing endpoints. If the goal is "typed contract between our services," propose Lighthouse (Laravel) or webonyx/graphql-php plus a schema-first workflow; if the goal is fewer round-trips, evaluate gRPC before GraphQL. Ask for a spike, not an ADR.