Openswoole Bundle Laravel Package

Product Decisions This Supports

• Runtime/performance investment: Deciding whether to move a Symfony workload off PHP-FPM request-per-process bootstrapping onto a long-lived OpenSwoole worker model. The bundle is the integration layer that makes this a configuration and DI concern rather than a rewrite, so it directly informs the "do we invest in a persistent PHP runtime this year" decision.
• Build vs. buy on real-time features: OpenSwoole gives you WebSockets, coroutines, tickers, task workers, and async I/O in-process. The bundle lets you keep WebSocket/streaming/notification fan-out inside the Symfony codebase instead of standing up a separate Node or Go service. That is a genuine build-vs-buy fork in the roadmap (one stack vs. polyglot edge).
• Infrastructure cost model: Fewer worker processes, no per-request framework bootstrap, tighter memory control per event loop. This supports the roadmap item "reduce compute cost per request" with a measurable hypothesis rather than a rewrite proposal.
• Consolidating background work: Task workers and tickers let small async jobs (webhook dispatch, cache warming, queue draining, scheduled jobs) live beside the HTTP layer — a decision about whether to keep a separate worker tier (Supervisor + queue consumers) or collapse it.
• Roadmap sequencing for async endpoints: If the roadmap contains streaming responses, server-sent events, or long-poll endpoints, adopting a coroutine-capable runtime now avoids a later migration. This package flags whether that sequencing is cheap or expensive.
• Platform standardization / golden path: Whether the platform team publishes a supported Symfony runtime profile (Docker image with the OpenSwoole extension, health checks, graceful reload) as a paved road for product teams.
• Vendor-fork posture: With 3 stars and 0 dependents, the real product decision this supports is make-or-fork: adopt as an internal fork under MIT, or abstract the runtime behind symfony/runtime so the choice is reversible. That is a governance decision, not just a technical one.

When to Consider This Package

Consider it when:

• The team is already PHP/Symfony-heavy and needs concurrency, WebSockets, or async I/O without adding a second language or service tier to the stack.
• Traffic profile is high enough that per-request bootstrap cost (container build, autoloading, config parse) is a measurable share of latency or CPU spend.
• You need long-lived connections (WebSockets, SSE, streaming) and want them co-located with existing Symfony auth, DI, and domain code rather than rebuilt in another stack.
• You have ops maturity for long-running processes: extension compilation in the base image, process supervision, graceful reload on deploy, memory-growth monitoring, and stuck-coroutine detection.
• You can absorb the dependency risk: MIT license, small maintainer base, thin adoption. Plan to pin a version, read the source, and own patches — or wrap it so swapping to RoadRunner, FrankenPHP, or the more established Swoole bundle is a contained change.
• Code you would run is coroutine-safe: no shared mutable statics across requests, no blocking sleep/sync network calls in hot paths, no reliance on per-request global state that assumptions were built on.

Look elsewhere when:

• You need a supported dependency with an SLA, a large contributor base, or published production case studies. Three stars and zero dependents means the social proof is essentially self-referential.
• Hosting is serverless/FaaS or shared/managed PHP where you cannot install a PECL extension or keep processes alive.
• The application leans on third-party libraries known to be coroutine-unsafe, or on extensions that block Swoole's hooks.
• The real driver is raw throughput and nothing async — RoadRunner or FrankenPHP deliver most of the bootstrap savings with a larger ecosystem and simpler migration.
• The team has no appetite for debugging event loops, coroutine context, and memory leaks in a long-lived process. The operational tax will exceed the savings at low-to-moderate traffic.
• You are pre-product-market-fit and need speed of iteration over runtime efficiency.

How to Pitch It (Stakeholders)

For executives: This is a runtime option, not a product feature. It lets our Symfony services hold long-lived connections and handle concurrency in-process, which means real-time capabilities and higher throughput without hiring for or operating a second language stack. The financial case is compute cost per request plus avoided complexity of a separate Node/Go edge service. The caveat is maturity: this specific bundle is a small, low-adoption open-source project. My recommendation is not "adopt this bundle" but "validate the persistent-PHP runtime direction on one service, behind an abstraction that keeps the decision reversible," and treat the bundle as an implementation detail we can fork or replace.

For engineering: The bundle wires OpenSwoole into Symfony's kernel and DI — HTTP server, task workers, tickers, WebSocket handlers, graceful shutdown. The value is that our existing container, routing, security, and domain code stay as they are. The work is not the integration; it is everything around it: an image with the extension, a supervisor and deploy story with graceful reload, request-scoped state discipline (no leaking statics across coroutines), coroutine-safe I/O on hot paths, and instrumentation for memory and event-loop lag. Treat the dependency as vendored: pin it, read it, and put a thin runtime interface in front so RoadRunner, FrankenPHP, or the established Swoole bundle remain drop-in alternatives.

Shared risk framing: Low stars and zero dependents means no community backstop. That is acceptable if the integration surface is thin and the runtime is swappable, and unacceptable if product teams start importing Swoole-specific APIs throughout the domain layer. Gate adoption on one bounded service, a stated throughput/latency hypothesis, and a defined exit cost. If the pilot does not show a clear win in cost or capability, revert — the abstraction should make that a sprint, not a quarter.