Framework Laravel Package

Product Decisions This Supports

• Build vs. buy (framework layer): This is a "buy" (adopt) decision for the entire application runtime, not a library bolt-on. It settles how the request/worker lifecycle, DI container, routing, ORM, queue, and auth get built for the next 3–5 years. Treat it as an architecture decision record, not a dependency bump.
• Roadmap shaping for throughput-sensitive surfaces: Resident-memory execution via RoadRunner (no per-request bootstrap) plus native queue (AMQP/SQS/Beanstalk/Kafka), gRPC server/client, WebSockets, and Pub/Sub support maps directly to roadmaps that include real-time features, internal service-to-service RPC, or background job volume. If your roadmap has these, this package collapses several "build it ourselves" workstreams into one.
• Buy vs. build on infrastructure plumbing: Encrypted cookies, signed sessions, CSRF guard, RBAC, validation, auto-migrations, queue supervision, and (notably) PCI DSS compliance posture are pre-built. That is a meaningful accelerator for teams that would otherwise hand-roll these or pay for a separate identity/security layer.
• Workflow orchestration decisions: The Temporal bridge is the differentiator for product decisions involving long-running, multi-step business processes (order fulfillment, provisioning, approvals) where you'd otherwise build sagas and retry semantics yourself.
• Standardization / platform consolidation: 60+ PSR-compliant components (PSR-3/4/7/11/12/14/15/16/17) mean you can adopt parts without total lock-in — useful for a "one platform, many services" decision where you want shared conventions across gRPC, CLI, queue-worker, and HTTP apps.
• Not supported: decisions about ecosystem breadth, third-party package availability, or hiring-led standardization — those cut against this package (see below).

When to Consider This Package

Adopt when most of these are true:

• Throughput/latency is a stated product requirement, not a hypothetical — you have benchmark evidence or a service already bottlenecked on framework bootstrap.
• You need long-lived workers or persistent connections (WebSockets, gRPC streaming, high-volume queue consumers) as first-class, not bolted on.
• You have platform engineering capability: someone owns RoadRunner operations, worker lifecycle, graceful reloads, and debugging in a stateful process model where a memory leak survives across requests.
• You're greenfield or carving out a new high-load service — retrofitting a resident-memory runtime onto an existing app is a rewrite, not a migration.
• Your team is framework-agnostic PHP-strong rather than Laravel/Symfony-specialized; the DI/bootloader/scaffolding model is its own learning curve.
• You value PSR contracts so components can be swapped if the framework relationship sours.

Look elsewhere when:

• You need the ecosystem. Laravel/Symfony win decisively on package availability, tutorials, and hireable talent. With zero recorded dependents on this package and a 2k-star footprint, you are adopting a niche platform — expect to write integrations yourself.
• You need a vendor with contractual support. Maintained by one company (Spiral Scout), MIT, no visible commercial support tier or LTS commitment in the provided materials. That's a single-maintainer-class risk for a core platform.
• Team size is small and ops capacity is thin. Resident memory + RoadRunner means new failure modes (leaks, stale container state, scope bugs — visible even in recent changelogs around container scopes, proxies, and worker boot races).
• Debugging simplicity matters more than raw speed. FPM-style stateless debugging and off-the-shelf APM/tooling are better understood.
• You're already on Laravel and speed isn't the bottleneck. The migration cost dwarfs any benchmark delta you don't actually need.

How to Pitch It (Stakeholders)

For executives — one paragraph: Spiral is a mature (since 2013), MIT-licensed, high-performance PHP framework built on the RoadRunner application server, which keeps application code resident in memory between requests. For us, that translates into fewer servers for the same load and native support for real-time and background-processing features (WebSockets, gRPC, Kafka/SQS queues, workflow orchestration) that we would otherwise staff and build internally. The trade-off is deliberate: we take on a smaller ecosystem and more demanding operations in exchange for performance headroom and less custom infrastructure. This is a platform-level bet, so we should only make it where performance or persistent-connection needs are real and measurable — not as a default for every service.

For engineering — the honest version: You get a PSR-compliant stack, a strong DI/scope model, a genuinely good ORM (Cycle), first-class queue and gRPC support, and scaffolding that removes boilerplate. You also get: a resident-memory runtime you must operate and instrument (leaks persist across requests), a container/scope model with real sharp edges (recent releases are fixing proxy recursion, scope resolution, and worker boot concurrency), a framework-specific bootloader mental model, and an ecosystem where most integrations are yours to write. Assume a multi-week ramp for anyone not already fluent, and budget for observability (OpenTelemetry support exists) from day one.

Ask: fund a bounded, time-boxed spike on one non-critical high-throughput or worker-heavy service, with explicit success criteria (p95 latency, throughput per instance, incident rate, developer ramp time). Revisit platform standardization only after that spike clears the bar.