Df Core Laravel Package

Product Decisions This Supports

• API platform / integration strategy: Still best suited to decisions around exposing data and services through DreamFactory-style APIs, especially "extend the existing DreamFactory deployment" versus "build custom API scaffolding." Release 1.0.18 reinforces that the package is a live part of DreamFactory's own release train (cut for DreamFactory 7.7.1), not an abandoned side project.
• Build vs. buy for API management: Frames "buy/extend DreamFactory" versus "build a Laravel-native API gateway or integration layer." The security work in this release (SSRF/TLS hardening in the curl wrapper, authenticated service-type catalog at the API root) is exactly the kind of hardening a PM would otherwise have to specify, budget, and review in a custom build — a credible argument for buying/extending if DreamFactory is already strategic.
• Security posture of exposed APIs: Now a first-class decision input. Redirects are no longer followed automatically, each opted-in redirect hop is validated and pinned to its resolved IP, SSL peer/host verification is on by default, and the service-type list requires authentication. Any roadmap item that exposes DreamFactory-backed endpoints externally should be planned against 1.0.18+ rather than earlier versions.
• API contract / behavior-change management: This release changes observable behavior. Filters like a='x' OR b='y' without explicit parentheses previously matched nothing and now match; BETWEEN/NOT BETWEEN now work; validation errors on updates return 400 instead of 500; ?model=true is built from the caller's _table listing. Consumers (including AI agents via MCP query templates, which now use snake_case args) may rely on the old behavior — treat as a contract-change review, not a quiet patch.
• Roadmap fit: Potential enabler for internal tools, admin APIs, data-access facades, connector work, role/service-access administration, and package/import workflows around DreamFactory. The service-access-list and package-import fixes matter specifically for role-based access provisioning and tenant/service onboarding — relevant if entitlements or per-service permissions are on the roadmap. Still unlikely to be a customer-facing differentiator on its own.
• Use-case validation: Useful for prototypes needing DreamFactory core behavior without rebuilding primitives. The filter-parsing and MCP template fixes make it more viable for reporting/aggregation and agent-facing query use cases that previously returned silently empty results — a common source of false "it works" in demos.
• Risk decision: Unchanged in kind, partially improved in evidence. Vendor maintenance is real and current (active PRs, security response, versioned to a DreamFactory release), but external community signal remains thin (16 stars, 0 dependents). Adopt only against a specific DreamFactory requirement, and now also require a re-test of filter/query and redirect-dependent integrations before upgrading.

When to Consider This Package

• Consider it when you are already on or extending DreamFactory and need its core components in PHP/Laravel-adjacent services — ideally on the matching DreamFactory line (7.7.1 for this release).
• Consider it when you are already running an earlier 1.0.x and want the security and filter-correctness fixes; 1.0.18 is the version to plan against for anything externally exposed.
• Consider it when the fixes map to known product pain: unparenthesized AND/OR filters silently returning empty sets, missing BETWEEN support in report/filter UIs, roles unable to be granted _spec access, service access rows skipped during package import, or 500s surfacing where 400s belong.
• Consider it when Apache-2.0 licensing, source access, and vendor-managed core behavior are acceptable and your team can inspect/pin the dependency.
• Look elsewhere when you need a standalone, Laravel-native API gateway, admin panel, connector library, or general-purpose backend toolkit with strong documentation and community support.
• Look elsewhere when low adoption is a blocker: zero dependents and limited stars still mean few community answers and higher integration/debugging burden, even with an active vendor.
• Look elsewhere when you need a dependency your team can adopt without DreamFactory-specific context or without tracking DreamFactory's release cadence.
• Before adoption or upgrade: budget for a regression pass on filter/query endpoints, anything relying on HTTP redirect following from the curl wrapper, MCP/agent query templates, and error-code handling in clients. Confirm Laravel/PHP version compatibility and pin the exact patch.

How to Pitch It (Stakeholders)

• To executives: "This is a targeted, Apache-licensed core dependency for DreamFactory-based API work. The new 1.0.18 release is a security-hardening and bug-fix cut tied to DreamFactory 7.7.1 — SSRF/TLS defaults tightened, the service-type catalog now requires auth, and filter parsing was corrected. It lowers risk if DreamFactory is already strategic and reduces what we'd otherwise build and harden ourselves, but it is not a general Laravel accelerator and external community adoption remains very small."
• To engineering: "Treat df-core as an infrastructure dependency, not a framework. Upgrade to 1.0.18 but treat it as a behavior change: filters without explicit parentheses now match, BETWEEN works, update validation returns 400 not 500, and the curl wrapper no longer follows redirects automatically with SSL verification on by default. Isolate it behind an adapter, pin the version to the DreamFactory line you run, and regression-test query/filter endpoints, redirect-dependent integrations, role/service-access provisioning, package imports, and MCP query templates."
• Recommendation: Pursue only with a DreamFactory-specific requirement and a low-cost spike; adopt 1.0.18 for the security fixes if already on the package. Do not position it as the foundation for a greenfield API platform unless engineering confirms the security changes are compatible with existing integrations, the version-pinning strategy to DreamFactory releases is sustainable, and the dependency is replaceable if vendor support falters.