Df Graphql Laravel Package

Product Decisions This Supports

• API surface strategy: REST vs. GraphQL. This package is the cheapest possible test of "should we expose our DreamFactory-managed data as GraphQL?" If DreamFactory is already your data-access layer, df-graphql lets you ship a read-only GraphQL endpoint without standing up Apollo, Hasura, or a hand-written schema layer — a one-sprint experiment instead of a one-quarter platform bet.
• Build vs. buy on the API gateway layer. Using this module implicitly commits you to DreamFactory as the system of record for API generation. That's the real decision; the GraphQL module is a rider on it.
• Roadmap sequencing for platform migrations. If you're modernizing off a PHP monolith toward Laravel services, this package is a bridge artifact: it preserves existing DreamFactory services while front-end teams move to GraphQL. It should appear as a dated tactical item, not a strategic pillar.
• Client-facing capability commitments. Useful for deciding whether "GraphQL support" can be promised to mobile/partner teams in the near term, and under what SLA caveats.
• Buyer/internal-tooling use cases. Low-stakes internal dashboards and admin tooling where a thin GraphQL shim over existing DB services saves weeks — and where a 2023-era, single-maintainer module is an acceptable risk.

When to Consider This Package

Consider it when:

• You already operate DreamFactory in production and want GraphQL exposure with minimal incremental infrastructure. This is the only scenario where the trade-offs are favorable.
• The scope is internal, low-blast-radius, read-mostly — reporting tools, admin UIs, prototyping against existing services.
• You need a time-boxed proof of concept to validate GraphQL demand before funding a real schema layer.
• You have PHP/DreamFactory operational competency in-house and can fork/patch the module yourself if upstream stalls.

Look elsewhere when:

• You are building a greenfield Laravel application. This is not a Laravel package — it's a DreamFactory module with framework-adjacent dependencies. Use Lighthouse (or similar) and stay inside Laravel's ecosystem.
• You need ongoing maintenance guarantees. Signals here are weak: 1 GitHub star, 0 dependents, last release 2023-02-28, no community. Treat it as vendor-internal code that happens to be public.
• You require GraphQL subscriptions, federation, persisted queries, cost-based rate limiting, or fine-grained field-level authorization. Not evidenced in this module; you'd be building it.
• Security or compliance scope includes external partners. An unmaintained shim in front of your data layer is a poor place to accept dependency risk.
• Your team has no DreamFactory footprint. Adopting a niche platform plus a low-adoption module to get GraphQL is strictly worse than adopting a maintained GraphQL server.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible experiment — not a platform commitment. It lets us validate whether GraphQL improves client delivery speed on top of infrastructure we already run, at roughly the cost of a single sprint. The catch is maintenance: the module has one public release (Feb 2023), no meaningful community, and no downstream dependents. I'd fund it as a 30-day spike with an explicit exit criteria, not as a line item in the architecture roadmap. If the spike succeeds, the follow-on decision is whether to invest in a maintained GraphQL layer — and that decision should be made on its own merits, not inherited from this module.

To engineering: Treat dreamfactory/df-graphql as vendor-internal code with a public URL, not a community dependency. Concretely: pin the version, vendor it, and assume we own it. Validate three things before committing — (1) version compatibility with our DreamFactory core, since the module tracks the platform's release cadence; (2) authorization propagation, i.e. that DreamFactory role/API-key scoping actually applies per-field through the GraphQL resolver path; (3) query-depth and complexity limits, which are the usual way a thin GraphQL shim becomes a denial-of-service vector against the underlying database. If any of those are absent, the effort to harden it likely exceeds writing a purpose-built schema layer, and we should say so early.