Tdbm Graphql Bundle Laravel Package

Product Decisions This Supports

• Framework alignment (the first decision): despite the brief framing this as a "Laravel/PHP package," thecodingmachine/tdbm-graphql-bundle is a Symfony bundle. It is not usable in a Laravel application without abandoning the bundle wiring entirely. If the team is Laravel-first, this package should be closed out early rather than evaluated further.
• Code-first vs. schema-first GraphQL: the bundle's premise is that PHP classes (TDBM beans) are annotated/attributed and the GraphQL schema is derived from them. Adopting it is a vote for code-first schema generation, which is cheap for CRUD-shaped APIs and awkward for contract-stable public schemas.
• Build vs. buy for the data layer + API layer: the bundle is glue over two opinionated libraries — TDBM (DAO/bean generation from an existing relational schema) and GraphQLite (attribute-driven schema mapping). Buying this gets you a generated persistence layer and a generated GraphQL layer; the price is accepting both libraries' conventions and their release cadence.
• Roadmap sequencing for the Symfony 6 migration: v6.0.0 exists specifically to add Symfony 6 / GraphQLite 6 / TDBM 6 support. It is therefore both the enabler for, and the blocker on, a Symfony 6 upgrade. This release should be slotted into the platform-upgrade epic, not the feature backlog.
• Use cases where the value is real: internal admin/back-office tooling, partner-facing read-mostly APIs, and prototypes over an existing relational schema with many entities and a low appetite for hand-writing resolvers. The bundle earns its keep when the entity count is high and the schema is allowed to follow the database.
• Use cases where it is a poor fit: public, high-traffic, versioned APIs where schema changes must be deliberate; teams without an existing schema to generate from; anything requiring GraphQL performance work at the resolver level.

When to Consider This Package

Consider it when:

• The application is on Symfony 6 (or the Symfony 6 upgrade is committed and funded). Post-v6.0.0 there is no supported path for Symfony 4/5.
• You are already on, or deliberately adopting, GraphQLite 6 and TDBM 6 — the bundle has no independent value without them.
• The domain is schema-first-by-accident: a mature relational schema, many tables, CRUD-ish access patterns, and a team that would rather annotate classes than hand-write resolvers and DTOs.
• The API is internal or partner-facing, where you control all consumers and schema churn is tolerable.
• You need zero license cost and are comfortable with a small, single-vendor OSS dependency (TheCodingMachine).

Look elsewhere when:

• Laravel is the stack. Use Lighthouse or rebing/graphql-laravel; this bundle is not a candidate.
• You are pinned to Symfony 5.x / GraphQLite 5 / TDBM 5. Stay on v5.0.x and treat v6.0.0 as unavailable until the platform upgrade lands.
• You want a schema-first / SDL-driven contract with codegen, or you need federation, persisted queries, or deep query-cost analysis as first-class concerns — API Platform or a hand-rolled GraphQLite setup gives you more room.
• You don't use TDBM. The bundle is a TDBM↔GraphQLite bridge; without TDBM, drop the bundle and use GraphQLite directly.
• You need maintenance guarantees, a large contributor base, or commercial support. This is a niche integration layer with a correspondingly small bus factor.

On v6.0.0 specifically: the release is a coordinated major bump — it tracks GraphQLite 6, TDBM 6, and Symfony 6 together. Treat it as a breaking upgrade project, not a patch. There are no new end-user features in the notes; the entire value is version compatibility. Budget for the transitive upgrade of GraphQLite and TDBM alongside it, since the bundle's public surface is largely theirs.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source glue library that connects a database-driven PHP codebase to a GraphQL API, removing boilerplate for teams already on Symfony. It carries no licensing cost and no vendor contract, but also no support commitment — the risk is maintenance and upgrade effort, not money. The v6.0.0 release is purely a compatibility release: it lets us stay current on Symfony 6, and it is a prerequisite for that platform upgrade rather than a feature we can ship to customers. It is not applicable if we standardise on Laravel.

To engineering: v6.0.0 aligns the bundle with GraphQLite 6, TDBM 6, and Symfony 6. It is a breaking major — expect to upgrade GraphQLite and TDBM in lockstep and to re-verify generated schema output, since the annotations/attributes surface comes from those libraries. Do not adopt it on a Symfony 5 branch. If we proceed, pin exact versions for all three and treat the generated schema as an artifact worth snapshot-testing, because schema drift from a library bump is the most likely failure mode. If we are on Laravel, stop here and evaluate Lighthouse instead.

Recommendation: defer the adoption decision until the Symfony 6 migration is on the roadmap; at that point this package becomes a low-cost, low-risk dependency with a known upgrade path. If the stack is Laravel, reject on framework-fit grounds without further evaluation.