Framework Laravel Package

Technical Evaluation

Architecture fit spiral/framework is a meta-package that pulls in 60+ first-party components and, by its own README, is a "High-Performance Long-Living Full-Stack framework" — a peer to Laravel, not an extension of it. Two kernel-level divergences make fit effectively zero: (1) the bootloader-based container/bootstrap model versus Laravel's service providers and facades, and (2) a resident-memory execution model anchored on the RoadRunner application server versus Laravel's request-per-process lifecycle. The ORM is Cycle (Data Mapper), not Eloquent (Active Record), so every persisted model is a rewrite. The only genuine architectural overlap is at the transport layer, where both frameworks can be hosted on RoadRunner. Any stakeholder framing of this as "a Laravel package" is wrong and will set the wrong expectation.

Integration feasibility Split into two tracks. (a) Wholesale framework swap: not feasible for an existing Laravel codebase — providers, facades, Eloquent models, Blade views, queue jobs and middleware all need reimplementation for no functional gain; this is a multi-quarter re-platforming programme, not an integration. (b) Surgical reuse: viable in principle, because the repo advertises PSR-{3,4,7,11,12,14,15,16,17} compliance, meaning individual components can be consumed without the Spiral kernel. In practice the candidates are narrow — PSR-7/PSR-17 bridges (spiral/sapi-bridge, spiral/nyholm-bridge) and the RoadRunner gRPC bridge for service-to-service RPC — and Laravel/Octane already ships equivalents for most of them. Adoption therefore needs a named capability gap (native gRPC server, Kafka-native queue transport, Temporal workflow orchestration), not a general quality argument.

Technical risk Medium-high. (1) Breaking-change treadmill: SingletonInterface is deprecated for v4, spira/hmvc was deprecated in 3.14, and 3.15 tightened singleton-rebinding semantics with explicit guidance to opt into future behavior now. We would be adopting mid-cycle onto an API surface that is actively being reworked, with a v4 migration already visible. (2) Resident memory: the vendor ships anti-memory-leak tooling, which is an implicit admission that cross-request state leakage is a live failure class. A Laravel team's muscle memory is built around request teardown; this is a new operational discipline. (3) Security patch dependency: 3.17.1 fixed session id validation and file-handler path containment (path-traversal class) and 3.17.0 fixed a CSRF cookie missing Path. Good that fixes ship fast; bad that there is no visible CVE feed or LTS commitment — we own tracking. (4) Data-quality caveat on the input assessment: "Dependents: 0" is almost certainly a scanning artifact of spiral/framework being a meta-package nothing requires directly, so don't over-read that single number — but the underlying signal (a thin third-party ecosystem compared with Laravel's) is real and independently verifiable. The 56/100 score with a 46.1 opportunity sub-score points the same way: credible engineering, weak commercial upside for us.

Key questions

• What specific capability does our Laravel stack lack that Spiral uniquely provides, and can it be obtained without the Spiral kernel?
• Are we already on Octane/RoadRunner? If not, the resident-memory model is a new operational paradigm, not an incremental step.
• What is the v4 timeline and the support policy for 3.x after v4 ships? Do security patches continue?
• Who owns a Spiral service in 18 months — can we hire for bootloaders, container scopes and Cycle ORM, or is this a permanent bus factor of one?
• Is community Discord support acceptable, or do we need a negotiated commercial SLA from Spiral Scout before production?
• Is Cycle's Data Mapper a hard requirement (rich domain, complex aggregates)? If it's a nice-to-have, Eloquent stays and the case collapses.

Integration Approach

Stack fit Poor at the whole-application level, good at the perimeter. If the estate is Laravel on PHP-FPM, Spiral adds nothing that Octane + RoadRunner doesn't already deliver. Fit becomes defensible only for a genuine need around long-lived workers, gRPC, pub/sub or workflow orchestration — and then for one bounded service, not the platform.

Migration path Three options, ascending in cost:

1. Zero-adoption / reference only — mine the changelogs, RoadRunner documentation and bridge designs for patterns to apply inside Octane. No dependency added, no new operational surface.
2. Service-scoped adoption (recommended if a gap exists) — stand up one new, non-customer-critical service (internal RPC endpoint or a queue worker) on Spiral + RoadRunner, hidden behind a contract as a black box. This is the only path that lets us measure real TCO without touching the Laravel monolith.
3. Component lift — require specific Spiral packages inside a Laravel app, bypassing the kernel. Viable only where the package has no dependency on spiral/boot or spiral/core; verify per-package (composer why-not spiral/framework 3.17.1) because several bridges are kernel-coupled by design.

Do not attempt to swap the framework underneath an existing application. If the business genuinely wants to move off Laravel, that is a separate re-platforming decision with its own business case; spiral/framework is a candidate in that RFP, not a migration target here.

Compatibility Check the PHP version constraint first — it must clear our runtime standard. PSR compliance gives real interop at the HTTP message layer (PSR-7/15/17) with existing middleware via bridges, but the container contracts do not interop with Laravel's service container at all. Any shared code must be container-agnostic: plain constructors, no facades, no framework helpers. Cycle entities do not map onto Eloquent, so a shared persistence layer is off the table entirely.

Sequencing

1. One-week desk spike: confirm the capability gap is real and can be named in a single sentence.
2. Two-to-three-week timeboxed prototype (option 2) with exit criteria agreed in advance: p95 latency at target RPS, zero memory growth over a 24-hour soak, an on-call runbook written, and a documented security-patch process.
3. Go/no-go review against those criteria.
4. Only then any broader rollout — service by service, never big-bang.

Operational Impact

Maintenance Cadence is high and steady: the changelog excerpts show 3.11 through 3.17.1 with frequent patch releases and visible PHP 8.4 deprecation work. That's a healthy maintenance signal and a real operating cost — pinning exact versions and upgrading on a schedule is ongoing staffed work. The 3.x → 4.0 transition (singleton interface removal, container strictness) will require a funded upgrade; put a line item in the budget rather than assuming it's free.

Support MIT license means legal and redistribution risk is effectively nil. Support is community (Discord, GitHub issues) plus Spiral Scout — an agency, not a foundation. No LTS commitment or commercial SLA is visible in the material, and documentation depth should be spot-checked for the specific components we'd touch, not judged from the front page. Negotiate support terms before adoption, not after the first incident.

Scaling This is where Spiral genuinely earns its place: RoadRunner plus resident memory plus the TechEmpower benchmark lineage means worker-per-core efficiency and native queue/GRPC/pub-sub without bolt-on infrastructure. If our bottleneck is framework bootstrap cost or per-request FPM overhead, that is the lever. Realizing it depends on getting worker lifecycle right, which is a skill rather than a configuration switch.

Failure modes (ranked by what a TPM should track)

• State leakage across requests in a long-lived worker (cross-tenant data exposure) — highest severity; the vendor's anti-leak tooling exists because this is easy to get wrong. Mandate a soak test and a per-request scope audit before any production traffic.
• Container/scope misconfiguration — the changelog is dense with scope-resolution fixes (proxies, recursion detection, request binding). Symptoms are subtle rather than loud, which is the expensive kind of bug.
• Silent breakage on a patch release — mitigated by exact version pinning and a CI matrix.
• Security patch lag — we own CVE tracking; fixes like the 3.17.1 path-containment change ship as patch lines, not advisories.
• Vendor and bus-factor concentration — single commercial maintainer, small contributor pool, no internal expertise today.

Ramp-up Budget 4–6 weeks for a mid-level PHP engineer to be productive, longer to be safe on resident memory and scope semantics. The mental model transfers partially from Octane and not at all from Eloquent to Cycle — that is the steepest curve for a data-heavy team. Fund one engineer to go deep and become the named owner; without that, the bus factor is one and the business case fails on risk regardless of technical merit.

Bottom line: spiral/framework is credible, well-maintained engineering that solves problems we may not have. Default to no adoption; run the timeboxed service-scoped spike only if a specific capability gap can be named, and stop calling it a Laravel package.