Df Cassandra Laravel Package

Technical Evaluation

Architecture fit

• df-cassandra is not a general-purpose Laravel library — it is a service-type plugin for the DreamFactory platform, packaged as a Composer module. It registers a "Cassandra" service handler and resource/schema classes into DreamFactory's service container so the platform can auto-generate governed REST endpoints over CQL tables.
• Consequence: the build-vs-buy question is really "are we a DreamFactory shop?" If yes, this is the canonical path to exposing Cassandra without writing a bespoke API gateway. If no, adopting this package means adopting DreamFactory (platform, admin UI, RBAC, licensing tier) — a much larger decision than a normal composer require.
• Fits the standard DreamFactory connector pattern (sibling to df-mysql, df-pgsql, df-sqlsrv), so operators who already run another SQL connector get a familiar admin experience, script hooks, and role/API-key model.

Integration feasibility

• Deployment is Composer-level in the manifest, but the runtime dependency is the likely blocker: Cassandra connectivity from PHP typically requires the DataStax CQL native driver (ext-cassandra), a PECL/C++ extension. That means base-image changes, build toolchains, and version pinning against the PHP minor — not a pure-PHP drop-in.
• Requires confirming which DreamFactory major (Laravel version) this branch targets; connector repos are versioned in lockstep with the platform release train and are not generally forward/backward compatible across majors.

Technical risk

• Impedance mismatch (highest risk): auto-generated REST resources over Cassandra invite consumers to treat it as a relational DB. Cassandra has no joins and demands partition-key-bounded queries; naively exposed list endpoints can produce cluster-wide scans / ALLOW FILTERING behavior that degrades a shared cluster.
• Schema introspection fidelity: API generation depends on reading table metadata; Cassandra/Scylla type coverage (collections, UDTs, counters, TTL, tuples) may be partial, producing lossy or omitted fields.
• Auth model gap: DreamFactory governs the API edge (keys, JWT, RBAC, rate limits), but Cassandra's own authz (per-keyspace roles) is separate — a single service credential often means broad access downstream of the governance layer.
• Vendor-signal ambiguity: 0 stars / 0 dependents reflects the repo being split out of the main dreamfactorysoftware/dreamfactory monorepo, not abandonment — but it does mean no independent community, no third-party issue triage, and documentation that assumes platform context.

Key questions

1. Which DreamFactory platform version does this release (2026-02-11) target, and is it in the vendor's supported matrix?
2. Does it require ext-cassandra, or is there a pure-PHP/CQL-over-HTTP fallback? What are the build artifacts for our base image?
3. Which Cassandra (3.11 / 4.x / 5.x) and ScyllaDB versions are validated? DSE?
4. How are filter/where parameters translated to CQL — parameterized prepared statements or string interpolation?
5. Is there mandatory paging/LIMIT enforcement on generated list endpoints, or can a caller request an unbounded result set?
6. Are UDTs, collections, counters, and TTL columns representable in the generated schema?
7. Support path: commercial DreamFactory entitlement, or GitHub issues only?

Integration Approach

Stack fit

• Assumes a PHP/Laravel runtime managed by DreamFactory and a Cassandra cluster reachable over the native protocol (port 9042). The connector is stateless request-scoped code; it has no opinions about your app tier, so it composes cleanly with existing PHP-FPM/Kubernetes deployment patterns.
• Where it fits well: internal/admin tooling, LLM tool-calling backends, low-code app builders, and read-heavy lookup APIs against denormalized tables — the governance layer (keys, quotas, audit) is the actual value.
• Where it fits poorly: high-throughput transactional paths (you'd bypass the gateway), analytics (use Spark/Sidecar, not REST), or teams expecting relational semantics.

Migration path

• Greenfield: add dreamfactory/df-cassandra to the platform's Composer manifest → rebuild image with the CQL driver → run platform migrations → create the service via admin UI or seeded config → define roles/API keys → publish OpenAPI.
• Brownfield from an existing DreamFactory MySQL/Postgres service: treat as a new service type, not a port. Data model, query patterns, and error semantics differ; existing client code will not translate 1:1.
• Brownfield from direct CQL clients: the connector becomes a facade. Plan for an adapter/shim layer in consuming apps rather than pointing them at generated endpoints directly.

Compatibility

• Hard pins to verify in a spike before committing: PHP minor ↔ ext-cassandra ↔ DreamFactory major ↔ Cassandra server version. Any one of these drifting is a rebuild.
• Check how the vendor publishes this repo — if it is a read-only subtree split, patches must go upstream via PR to the monorepo; you cannot sustainably vendor a fork.

Sequencing

1. Environment spike (1 sprint): build a container with the driver, connect to a non-prod cluster, create one service, exercise one table end-to-end. This single step de-risks most of the assessment.
2. Driver/CI hardening: bake the extension into the base image, pin versions, add a smoke test.
3. Read-only exposure first: one keyspace, one or two tables, explicit roles, rate limits, enforced paging.
4. Schema/error contract review: validate OpenAPI output, error codes, and type mapping against real tables.
5. Write paths (only if required): insert/update via API; validate idempotency and timestamp/TTL handling.
6. Load and failure testing against realistic partition-key distributions before opening to consumers.
7. Cutover with the legacy access path retained behind a flag for one quarter.

Operational Impact

Maintenance

• Low code surface, non-trivial platform surface: the package itself is small, but you inherit the DreamFactory upgrade treadmill plus the PECL extension. Budget a recurring "rebuild image when PHP or the platform bumps" task — this is the single most predictable ongoing cost.
• Pin the Composer version and the extension version together; treat upgrades as re-certification events, not patch-and-forget.

Support

• With zero dependents and no visible community, the realistic support channel is a commercial DreamFactory subscription or self-support via reading platform source. For a regulated or revenue-critical path, assume self-support and staff accordingly; assign a named owner for the connector.
• Apache-2.0 means you can fork, but the monorepo-split publication model makes fork maintenance a poor trade unless you're already deeply invested.

Scaling

• The connector scales with your PHP worker pool, not with Cassandra. Per-worker connections to the cluster multiply quickly at high replica counts; cap pool size and use persistent/prepared statements where supported.
• Cassandra itself scales horizontally, but the REST facade does not remove the need for good data modeling. The gateway will happily serve a query pattern that a Cassandra engineer would reject — scaling problems will surface as cluster-side, not API-side, and be harder to trace.

Failure modes to instrument

• Boot-time failure if the CQL extension is absent or ABI-mismatched (fails at container start, not at request time — good, if you test it).
• Query timeouts / partial results on large scans; silent truncation if paging defaults are wrong.
• Schema drift: a column added or dropped after API generation produces stale contracts for consumers.
• Credential blast radius if the service account has keyspace-wide privileges.
• Injection risk if filter parameters are interpolated into CQL rather than bound.
• Coordinator hotspotting when generated endpoints omit partition keys.

Ramp-up

• DreamFactory administration is genuinely low-code — days, not weeks.
• The real ramp-up cost is Cassandra data-modeling literacy for whoever owns the endpoint catalog. Without it, the team will publish APIs that look fine in staging and cause cluster incidents in production. Plan one experienced Cassandra reviewer in the design gate for any new exposed table, and document "approved query shapes" as a first-class artifact.
• Net: attractive if DreamFactory is already in the estate and the use case is governed read access to a well-modeled cluster; a poor first project if either of those is untrue.