Graphql Maker Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for schema authoring, not for the API itself. This is a dev-only console generator: it scaffolds GraphQL type/query/mutation classes in the shape OverblogGraphQLBundle expects. The decision it informs is small and reversible — "do we hand-author type boilerplate or generate it?" — not "what is our GraphQL platform?" Keep the two decisions separate in the roadmap doc so a cheap tooling experiment doesn't get mistaken for an architecture commitment.
• Framework targeting (the decision that actually matters here). Despite being filed as a "Laravel/PHP package," this is a Symfony bundle layered on Symfony MakerBundle and Overblog GraphQLBundle. It has no Laravel service-provider story. The real product decision it surfaces is whether the service in question is Symfony or Laravel — get that wrong and an entire evaluation cycle is wasted. Action item for the PM: correct the package taxonomy in the internal registry and add a "framework fit" field so this misclassification doesn't recur.
• Codegen posture on the GraphQL roadmap. Adopting a generator sets precedent for how much of the GraphQL surface you generate vs. hand-write — client types, schema diffs, contract tests. A yes here is a small vote for "generation is part of our workflow"; a no is a vote for hand-authored conventions. Either way, record the rationale.
• Roadmap gate: code-first vs. schema-first (SDL). If the team is moving toward SDL as the source of truth, this tooling is directionally wrong regardless of quality. This package is a useful forcing function to settle that question before more schema is written.
• Feature velocity and onboarding cost on a specific slice. Concretely: a new Symfony service needs a GraphQL surface; the team is already fluent in bin/console make:*. Here the package plausibly compresses the first schema-building sprint and standardizes type shape across contributors, which shows up as faster onboarding and less review churn on type definitions.
• Vendor-risk budgeting on the developer path. ~10 stars, zero dependents, single maintainer. The decision this supports is explicit: are we willing to own this source (pin + fork contingency), or do we require a supported dependency here? Answer that before the spike, not after.
• Use cases to route elsewhere immediately: any Laravel service (evaluate Lighthouse, GraphQLite, API Platform, or webonyx/graphql-php directly); any team whose type volume is small enough that boilerplate isn't a measured cost.

When to Consider This Package

Consider it only when all of the following hold:

• The target application is Symfony, already running OverblogGraphQLBundle, with no planned migration off it in the next couple of release cycles.
• The team already works in the MakerBundle/CLI-scaffolding idiom (bin/console make:...), so the workflow is culturally free rather than a new habit to teach.
• Type volume is genuinely high — dozens of types, not five. Below that threshold, learning plus owning a generator costs more than typing the classes.
• You will treat it as a require-dev, version-pinned, forkable utility — never a long-lived supported dependency, never on the critical build path without a pin.
• You've accepted a 1–2 day timeboxed spike as the maximum exposure, with a named owner and a written fork contingency.

Look elsewhere when:

• You are on Laravel. This is disqualifying, not a tradeoff. The prerequisite stack doesn't exist; embedding a Symfony kernel to save keystrokes is not a serious option.
• You are schema-first (SDL). The product is class generation; if your source of truth is a .graphql file, there is no fit.
• You want types derived from existing Doctrine entities or ORM mappings at scale — API Platform or a bespoke generator covers more ground.
• You need vendor support, an SLA, a security-response trail, or a clean upgrade path across PHP/Symfony majors. None of that exists here; assume you'll patch for modern majors.
• Your GraphQL roadmap includes federation, persisted queries, or subscriptions — verify Overblog and this generator keep pace before adopting either.
• Your team already has a working authoring pattern. Adding a dependency to save keystrokes is a net negative.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, developer-only code generator that reduces repetitive typing when a Symfony team defines GraphQL types. It does not run in production, and removing it requires no migration — so the cost of being wrong is measured in days. The honest caveats: it is effectively unproven (roughly 10 GitHub stars, no downstream dependents, single maintainer), and it does not apply to our Laravel services at all. Recommendation: a one-to-two-day timeboxed spike on a single Symfony service, with a fork-on-adoption policy and no production dependency commitment. Treat it as a productivity experiment we own the source for, not a vetted vendor.

To engineering: The bundle adds maker-style console commands that scaffold OverblogGraphQLBundle type, query, and mutation classes, standardizing how types are declared across the team. It's a require-dev dependency with zero runtime footprint, so rollback is trivial. Three things to validate in the spike: (1) it resolves against your current PHP, Symfony, and OverblogGraphQLBundle versions — version coupling is the most likely failure mode, so assume incompatibility with modern majors and price in a small patch; (2) bin/console list make:graphql is the real documentation — README and blog posts drift, so trust the installed command surface and the bundle's Maker/ directory; (3) the generated output matches your namespace and coding conventions closely enough that you aren't rewriting the scaffolding anyway — scaffold-then-edit is fine, scaffold-and-ship is not. Confirm no command-name collision with the existing Symfony Maker bundle, and pin the exact version.

Positioning summary: A low-cost, low-risk developer-experience tool for Symfony + Overblog shops with meaningful GraphQL type volume. Do not present it as a Laravel package, do not put it on the critical path, and do not adopt it without a named owner and a fork plan. If the target service is Laravel, close the evaluation now and redirect the team to the idiomatic options.