Tdbm Graphql Bundle Laravel Package

Technical Evaluation

Architecture fit. thecodingmachine/tdbm-graphql-bundle is a Symfony bundle that glues together two opinionated libraries: TDBM (The Database Machine, a schema-first ORM that generates DAOs from the database) and GraphQLite (annotation/attribute-driven GraphQL schema generation). It is not a Laravel package in any meaningful sense — it ships a Symfony Bundle class, DI compiler passes, and service wiring against symfony/dependency-injection and symfony/http-kernel. A Laravel codebase would gain essentially nothing from the bundle wrapper; it could at best consume GraphQLite and TDBM as standalone libraries and hand-wire them in a service provider, which forfeits the bundle's only real value (auto-configuration). Architectural fit is therefore strong only for Symfony 6 monoliths that are already committed to the TDBM generated-DAO model; weak-to-nil for Laravel, API-only microservices, or teams using Doctrine/Eloquent.

Integration feasibility. The v6.0.0 change is a coordinated major-version alignment: GraphQLite 6, TDBM 6, Symfony 6. Each of those is itself a breaking release, so v6.0.0 is a hard floor, not a soft upgrade. Feasibility is gated almost entirely by the host application's Symfony version and PHP version (Symfony 6 implies PHP 8.1+; GraphQLite 6 likewise raises the PHP floor). If the consuming app is on Symfony 5.4 LTS, v6.0.0 is simply unusable and the team must pin to the 5.0.x line and accept that it is now a maintenance branch.

Technical risk. High, concentrated in three areas: (1) Coupled majors — you cannot adopt GraphQLite 6 independently of TDBM 6 through this bundle, so a single-library upgrade cascades into an ORM migration; (2) Code generation — TDBM generates DAO/bean classes from the live schema, so ORM majors typically alter generated code shape, and any hand-edits or subclass overrides in the generated namespace become breakage points; (3) Terse release signal — the release notes are a single changelog line with no migration guide, no deprecation list, and no upgrade notes. Absence of documented breaking changes in a 5.x → 6.0.0 jump should be read as "undocumented," not "none."

Key questions.

• What is our current Symfony, PHP, GraphQLite, and TDBM version matrix, and does anything already pin us below the v6 floor?
• Do we have any code that subclasses or patches TDBM-generated classes, and is that code covered by tests?
• Is the GraphQL schema annotation-based or attribute-based, and did GraphQLite 6 deprecate the annotation path we rely on?
• Who owns the TDBM schema-to-DAO regeneration step, and is it reproducible in CI?
• Does the maintainer publish upgrade guides outside the changelog, and what is the historical release cadence for the bundle itself?
• Is GraphQLite+TDBM still the right bet versus a Doctrine-backed GraphQL layer, given we are being forced into a coordinated triple-major upgrade?

Integration Approach

Stack fit. Confirm scope before planning anything: if the target application is Laravel, this bundle is out of scope and the evaluation should be re-framed around GraphQLite and TDBM as standalone libraries. If the target is Symfony, fit is good but only on Symfony 6 with PHP 8.1+.

Migration path. Treat this as a platform upgrade, not a dependency bump. Sequence: inventory the four coupled versions, stand up a Symfony 6 + PHP 8.1 branch, upgrade TDBM first and regenerate DAOs against a representative schema snapshot, then GraphQLite, then the bundle. Regenerate rather than reconcile — diff generated output before and after to surface behavioral shifts early.

Compatibility. Verify the full transitive set explicitly: symfony/* components at 6.x, graphqlite/graphqlite at 6.x, thecodingmachine/tdbm at 6.x, plus any PSR/PSR-15 and PSR-11 implementations the DI container depends on. Check for abandoned transitive dependencies, since TDBM's ecosystem is narrow and older adapters are the usual failure point.

Sequencing. Do not run this in parallel with other framework-level work. Land the Symfony 6 upgrade first as a standalone change, ship it, then upgrade TDBM+GraphQLite+bundle as a second isolated change. If Symfony 6 is not achievable in the current planning horizon, pin to 5.0.x now, record the pin and its rationale, and open a tracking item — a stale pin without an owner is how these become emergencies.

Operational Impact

Maintenance. The upgrade carries a recurring cost, not a one-time one: TDBM's generated-code model means every schema change re-runs generation, so the team must own a generation pipeline and keep it in CI. Note also the bus-factor risk — this is a small, single-maintainer-adjacent ecosystem, and the changelog's terseness suggests limited upgrade documentation.

Support. No commercial support path. Upstream help is limited to GitHub issues. For a production GraphQL API this is a real constraint; budget internal ownership and expect to read source when something breaks.

Scaling. The bundle itself is not a throughput bottleneck — it is DI wiring, and the scaling characteristics belong to GraphQLite (schema construction, resolver dispatch) and TDBM (query generation). Neither is inherently problematic, but annotation/attribute-driven schema builds are typically compiled and cached; verify the production cache warmup path survives the upgrade, since that is a common post-upgrade surprise (cold-start latency or uncached schema rebuild on every request).

Failure modes. Most likely failure is silent behavioral drift in generated DAOs — the code compiles, tests that assert on mocks pass, and a subtle change in generated query behavior reaches production. Second most likely is a partially-upgraded dependency tree where Composer resolves an older GraphQLite against the new bundle. Third is schema-generation failures in CI that block unrelated work. Mitigate with: a golden-schema regression test that snapshots the generated GraphQL SDL and diffs it on every change; an integration test suite against a real database rather than mocks; and a strict lockfile with an explicit composer why-not check in CI.

Ramp-up. Moderate. Engineers need working knowledge of three coupled abstractions (Symfony DI/compiler passes, GraphQLite's attribute-driven schema, TDBM's schema-first generation) before they can debug an upgrade failure. Estimate one engineer for roughly two to three weeks of focused effort for a Symfony 5.4 → 6 migration including this bundle, assuming a moderately sized schema; scale up if the schema is large or if generated DAOs are customized. The v6.0.0 release itself warrants only a low-urgency re-assessment: it is a legitimate breaking release that must be tracked and planned against, but it is not a security or correctness fix, so there is no case for emergency adoption.