Product Decisions This Supports
- Real-time roadmap (websockets, live notifications, presence, collaborative editing, streaming dashboards). Workerman is a pure-PHP async/event-driven server, so this package sits in the "can we keep real-time in PHP instead of adding a Node/Go service?" decision. It informs build-vs-buy against Pusher/Ably and against self-hosted Laravel Reverb.
- Runtime standardization for high-throughput or long-lived processes. Relevant to decisions about consolidating HTTP serving, background workers, and persistent connections onto one runtime layer (Workerman vs. Swoole vs. RoadRunner/Octane) instead of the default PHP-FPM + queue-worker model.
- Infrastructure cost and headcount. Pure PHP (no C extension, no second language runtime) lowers the operational and hiring bar versus Swoole or a separate Node service — useful input when comparing total cost of ownership, not just feature parity.
- Spike/discovery allocation, not production commitment. This is a
0.0.1 initial release with no feature description, no documentation, and no stated stability guarantees. The only defensible decision it supports right now is "spend a few days evaluating," not "put this on the critical path."
- Important scoping caveat for a Laravel shop: this is a Symfony bundle, not a Laravel package. Laravel does not consume Symfony bundles out of the box, so its practical value to us is as a reference implementation for wiring Workerman's process lifecycle into a container-managed app — not as a drop-in dependency. Any Laravel adoption implies adaptation work we would own.
When to Consider This Package
Consider it when:
- The team is on Symfony (or comfortable adapting bundle wiring) and wants Workerman's process lifecycle, configuration, and DI integration handled rather than hand-rolled.
- We have a concrete need for long-lived connections or high-concurrency endpoints — websockets, server-sent events, chat, notifications — and want to test whether staying in PHP is viable before adding a new runtime to the stack.
- We are already running Workerman and the remaining friction is boilerplate: service registration, config plumbing, start/stop lifecycle inside the framework.
- We want a cheap, reversible experiment: low license cost (open source), no new language, easy to throw away.
Look elsewhere when:
- The requirement is Laravel-native. Prefer Laravel Octane, Laravel Reverb, or RoadRunner — supported, documented, and already aligned with our framework's lifecycle. Do not adopt a Symfony bundle into a Laravel app to solve a Laravel problem.
- We need production guarantees: a 1.0+ version, changelog with substance, documentation, security policy, release cadence, or a maintainer with a support path.
0.0.1 with an empty changelog offers none of these.
- The real need is managed infrastructure with an SLA (Pusher, Ably, hosted Redis-backed queues). Operational simplicity may beat marginal hosting savings.
- The bottleneck is CPU-bound work. Async PHP servers improve concurrency and I/O multiplexing; they do not make heavy computation faster, and they introduce long-running-process hazards (memory growth, state leakage between requests).
How to Pitch It (Stakeholders)
For executives: This is a small, free, open-source integration layer for Workerman, a pure-PHP server that lets PHP hold open connections and handle high concurrency — the capability behind live updates and websockets. The strategic appeal is keeping real-time features inside our existing PHP stack instead of hiring for and operating a second runtime. The risk is maturity: this is a first 0.0.1 release with no documentation, no changelog detail, and no support commitment, and it targets Symfony rather than Laravel. My recommendation is a time-boxed, low-cost spike only — no production dependency, no roadmap commitment until we see the code, docs, and a maintainer track record. Budget a few engineer-days; success criterion is a working prototype and a documented list of what we'd have to own.
For engineering: Treat this as a reference for wiring Workerman's worker lifecycle into a DI container, not a dependency to composer require and forget. Expect API churn pre-1.0, absent docs, and no SemVer safety. If we proceed: pin the exact version, vendor or fork it, wrap it behind our own abstraction so it is replaceable, and write integration tests around startup/shutdown and request isolation. Benchmark against Octane/RoadRunner on our actual workload before drawing conclusions — and flag long-running-process risks (memory growth, static state, connection leaks) as first-class review items. Verify the 0.0.1 tag contents directly; the release notes contain no substantive information to evaluate.