Swoole Bridge Bundle Laravel Package

Product Decisions This Supports

• Runtime architecture: PHP-FPM vs. persistent workers. This package is plumbing that lets a PHP framework boot once and serve many requests inside Swoole's worker loop. Adopting it (or not) is effectively a decision to move off the request-per-process model — a foundational choice that ripples into deployment, observability, and local dev.
• Build vs. buy for the glue layer. Bridging Swoole to a framework means converting Swoole\Http\Request into framework requests, managing the DI container lifecycle across requests, and resetting state between them. That's non-trivial bespoke infrastructure. The decision is: maintain ~hundreds of lines of in-house bootstrap code, or take a dependency.
• Throughput/latency/cost OKRs. Persistent workers eliminate per-request framework bootstrap — usually the single largest cost in a Laravel/Symfony request. This supports roadmap items like "cut p95 latency," "reduce instance count," or "absorb traffic growth without proportional infra spend."
• Feature enablement beyond PHP-FPM. Long-lived connections (WebSockets, SSE), warm in-worker caches, and coroutine-based background work are hard or impossible on the standard runtime. This package is a lever for those capabilities without adding a separate service tier.
• Runtime standardization across frameworks. A framework-agnostic bridge is only strategically interesting if the org runs more than one PHP framework and wants a single runtime story and ops runbook. If you're Laravel-only, this decision collapses into a much simpler one (see below).
• Dependency risk posture. 31 stars, 0 dependents, and a single-maintainer profile means the real decision is how to consume it: as a supported dependency, or as a reference implementation to vendor/fork and own. That framing should be explicit before anyone puts it on a roadmap.

When to Consider This Package

Consider it when:

• You are on Symfony (the primary target of "PHP frameworks" bundles like this) and have already committed to Swoole as an approved extension in your platform.
• You want a thin bridge, not a full runtime/framework — you're keeping your existing framework and only replacing the serving layer.
• You have the engineering appetite to pin, vendor, and potentially fork — i.e., you treat it as code you own, not a vendor you can escalate to.
• You've confirmed your application is stateless-safe (or you've budgeted for the refactor) and your team can operate PECL extensions, worker reloads, and memory-leak hunting.

Look elsewhere when:

• You're on Laravel. Use Laravel Octane — first-party, actively maintained, covers Swoole and RoadRunner and FrankenPHP drivers, and ships runtime-specific tooling (worker reload, concurrency helpers, tick-based tasks). For a Laravel team, this package is almost certainly the wrong answer regardless of its merits.
• You need ecosystem breadth or community support. 0 dependents and 31 stars means near-zero field validation; you will be the first to hit most edge cases. RoadRunner, FrankenPHP (now a first-party Laravel option), or Hyperf for greenfield are safer bets.
• You need an SLA or predictable security patching. Low-adoption, single-maintainer packages are a procurement and incident-response liability.
• Your app leaks state. Heavy singletons, static caches, superglobal reliance, exit()/die() calls, or packages that assume a fresh process will break under persistent workers — and no bridge fixes that for you.
• The team lacks runtime ops depth. Worker lifecycle, graceful reloads, and "why is RSS climbing" debugging are new operational competencies, not a config flag.

How to Pitch It (Stakeholders)

To executives: This is infrastructure plumbing that lets an existing PHP application run inside Swoole's persistent-worker model rather than the traditional one-process-per-request model. The upside is real: meaningfully higher throughput and lower per-request latency, which translates into fewer instances and lower cloud spend for the same traffic. The downside is operational complexity and dependency risk — the package is small, has essentially no adoption, and would become code we own. Recommendation: fund a timeboxed spike with a benchmark gate, not a production commitment.

To engineering: Treat this as a two-week experiment, not an adoption. Stand up a representative endpoint under PHP-FPM and under the bridged Swoole runtime; measure req/s, p95/p99, memory growth over 50k+ requests, and instance-count delta. Gate the go/no-go on memory stability and a credible maintenance story (pin + vendor + named owner for the fork). Separately, budget the statefulness audit — that work is required for any persistent-worker runtime and is usually the real cost. And before all of it: if the target app is Laravel, redirect the effort to Laravel Octane, which solves the same problem with first-party support and a far larger user base.

The decision ask: approve the spike and the benchmark, and defer the build-vs-buy call until you have latency/cost numbers and a clear-eyed read on maintenance risk.