Youshido Graphql Extended Laravel Package

Product Decisions This Supports

• Build vs. buy for the GraphQL layer. This is the only decision this package meaningfully informs, and it pushes toward "build the thin wrapper yourself." The package is convenience glue over an existing library, not a capability you can't replicate.
• Framework/platform standardization. The repository is a Symfony bundle (YoushidoGraphQLExtendedBundle), not a Laravel package. If your roadmap is Laravel-first, this is a non-option and the decision collapses to "which Laravel GraphQL stack do we standardize on" — a real decision, but not one this package answers.
• Migration planning off a legacy GraphQL stack. The most valuable use of this assessment is sizing the cost of moving an existing youshido/graphql schema to a maintained runtime. For teams already on Youshido, this package is a signal that the surrounding ecosystem is small enough that a single vendor wrote its own sugar layer.
• Roadmap items it does not unlock. No federation, no persisted queries, no subscriptions story, no observability/APM integration, no schema governance tooling. It reduces boilerplate; it does not add product capability.
• Use cases where it's defensible: an internal tool or short-lived service already committed to Youshido on Symfony, where the alternative is a day of hand-written resolver/type wiring.

Adoption signal is effectively absent — zero dependents, zero score, no star count recorded. Treat as unvetted code, not as a community-endorsed component.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony, not Laravel (it will not integrate with a Laravel service container).
• You already have a production youshido/graphql schema you are not migrating this quarter.
• The wrapper is small enough that you can vendor or fork it and read the entire diff in an afternoon.
• The consuming service is internal, low-blast-radius, or has a bounded lifespan.
• You accept that you — not the upstream maintainer — own patching.

Look elsewhere when any of these are true:

• New project or new schema. Start on webonyx/graphql-php (the de facto PHP GraphQL runtime) rather than a framework-specific wrapper over a library with no visible release cadence.
• Laravel. Evaluate Lighthouse or an API Platform-style approach; this bundle is out of scope by construction.
• Symfony, greenfield. API Platform or OverblogGraphQLBundle give you maintained, documented, widely-deployed paths.
• Long-lived product surface. Zero dependents means zero downstream bug-finding; you will be the first to hit edge cases and the only one to fix them.
• Security or compliance requirements. No dependents and no observable maintenance means no coordinated disclosure path. That is a procurement blocker in regulated contexts.
• You need the wrapper's value in under a day. If the "easy" it adds is a few hundred lines of type/resolver registration, writing it in-house against your own conventions is cheaper than adopting an unowned dependency.

Before any decision, verify two things directly: whether youshido/graphql itself has received releases or security fixes recently, and whether this bundle pins a compatible version. Transitive abandonment is the dominant risk here, not the wrapper's own code.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency, and I recommend against adopting it. It is a small convenience layer over an existing GraphQL library, published by a single vendor, with no other projects depending on it and no measured adoption. Adopting it converts a public dependency into a private one — we inherit the maintenance burden without inheriting any support. The recommendation is to standardize on a maintained runtime and, if we need the ergonomics, spend the day writing them ourselves.

To engineering: Two concrete problems. First, it is a Symfony bundle, so it is not usable in our Laravel services — the "Laravel/PHP" framing in the package metadata is wrong. Second, it extends youshido/graphql, which has no visible release cadence; we would be stacking unmaintained glue on an effectively dormant base, with no dependents to surface bugs ahead of us. Where we still run Youshido, vendor or fork the wrapper and treat it as first-party code we own. Where we are starting fresh, use webonyx/graphql-php (or Lighthouse on Laravel, API Platform on Symfony).

One-line summary: Low-maturity, framework-mismatched wrapper with no adoption signal — skip for anything new; if already on Youshido, fork it and own it rather than depending on it.