Components Laravel Package

Product Decisions This Supports

• Runtime strategy / platform bet. The core decision this enables is whether to move throughput-sensitive services onto a Swoole coroutine runtime or keep scaling PHP-FPM horizontally. The package's value proposition is specific: it lets an existing Laravel-fluent team adopt that runtime without a rewrite, because facades, the container, Eloquent, and HTTP keep familiar shapes. That talent-leverage is usually the largest line item in a migration business case, so this package is a lever on it, not a utility dependency.
• Build vs buy. Buy (MIT, zero license cost). The real alternatives aren't competing packages but: (a) building coroutine-safe framework internals in-house, (b) adopting a different Swoole framework with a different API contract and a steeper learning curve, or (c) staying on FPM and adding capacity. Frame the trade as API familiarity and team speed versus maturity and ecosystem breadth.
• Per-service scoping, not platform flip. Adoption is a decision per service: does this service own its middleware pipeline, and is its dependency footprint small enough to vet? Modularity ("install only the components you need") supports incremental scope, which is exactly the risk posture a PM wants pre-1.0.
• Customer-visible API contracts. The v0.3.26 fix changes how exceptions thrown inside the middleware pipeline surface — status codes, error payload shape, and log volume. That is a product contract, not an internal detail: it touches API docs, client SDK assumptions, and error-budget reporting. Require error-path contract tests and updated docs as a release gate.
• Cost model. Resident-in-memory workers move spend from infrastructure toward engineering risk mitigation (regression suites, dependency vetting, an upgrade cadence). Model both sides; the infra saving alone will not justify the adoption if the vetting cost is hidden.
• Ecosystem vetting as a roadmap cost. Every third-party Laravel package that assumes per-request bootstrap becomes a compatibility question. This is where these migrations typically fail, so budget it as an explicit workstream rather than a surprise.
• Talent and hiring. Laravel API parity widens the hiring pool and shortens ramp-up. The genuinely scarce skill becomes coroutine/long-lived-worker semantics, not the framework itself — relevant to how you staff the pilot.

When to Consider This Package

Adopt (piloted):

• Greenfield or materially rewritten services already targeting Hypervel/Hyperf that need Laravel-shaped HTTP, container, events, or Eloquent.
• Latency or throughput per box is the binding constraint, and cheaper levers (caching, query work, horizontal scale) are exhausted or materially more expensive.
• The team is Laravel-fluent and time-to-productivity outweighs framework maturity.
• You control the middleware stack, and your dependency footprint is small enough to vet package by package.
• You can pin exactly (~0.3.26), run a middleware/error-rendering regression harness, and name an internal owner with a fork-or-patch escape hatch.

Look elsewhere / defer:

• Any part of the estate running vanilla PHP-FPM Laravel — wrong runtime; don't scope this as a shared dependency. Keep it explicitly coroutine-services-only.
• A long-lived platform core that needs semver guarantees and a support contract. Pre-1.0 versioning, a low-star community, and a small-maintainer release cadence are key-person risk; either wait for 1.0, or budget the fork deliberately.
• Applications with a heavy third-party Laravel package footprint (auth providers, admin panels, queue/observability integrations) — the compatibility surface is too large to reason about.
• Where latency is not the constraint: long-lived worker state, coroutine leakage, and config-cache staleness add operational complexity that buys nothing.
• Environments requiring vendor support SLAs and a documented CVE/response process.

How to Pitch It (Stakeholders)

For executives. This is a small, MIT-licensed open-source component set that lets our Laravel-experienced engineers run on a high-throughput coroutine runtime without rewriting application code. The strategic value is not the package itself — it's that our existing skills transfer, which removes the dominant cost of a runtime migration. The cost is maturity risk: it's pre-1.0, small-community, and maintained by a very small team. The proposal is therefore a pilot, not a commitment: one low-risk service, one full release cycle, exact version pin, and a regression suite around middleware and error responses before any widening. Decision requested: approve the pilot and roughly one engineer-week for the test harness; revisit at 1.0 or at the end of a full cycle, whichever comes first.

For engineering. Treat it as a pilot dependency, not foundational. Pin the exact version; do not float. Upgrade gated on a harness that reproduces middleware-thrown exceptions and diffs status codes, response bodies, and log output between versions. Do not catch Throwable broadly in middleware — that bypasses the pipeline's handling. Keep per-request state in coroutine-scoped storage, never on singleton middleware instances, since workers persist. Watch specifically for silent swallowing (errors turning into 200s → monitor for exception-rate drops, not just spikes), double handling, and cross-request contamination under load. Confirm the fix adds no per-request allocation or log-write overhead at target concurrency. Open questions to settle with the maintainer or by inspection: which exception classes are now caught, whether any existing endpoint's status or payload changes, whether #510 ships a regression test we can mirror, and what the 0.3.x support model and 1.0 timeline are.