Channel Laravel Package

Product Decisions This Supports

The decision this actually informs: whether and where to adopt in-process concurrency primitives in a Laravel codebase.

• Architecture: choose the right communication boundary. This package provides in-process message passing between fibers/coroutines — producers and consumers inside the same PHP process, same worker, same memory space. That makes it a tool for intra-process coordination, not service-to-service messaging. This distinction should be the first line of any internal write-up, because the intuitive-but-wrong framing ("replace HTTP calls between our microservices with channels") will get approved by people who don't read the code and then fail in production. Channels cannot cross a process boundary; there is nothing to serialize to.
• Build vs. buy vs. wait. The realistic "buy" alternatives are: (a) Swoole\Channel, (b) hand-rolled fiber + queue plumbing, (c) Revolt/Amp primitives directly, or (d) doing nothing and keeping the code sequential. What this package buys is runtime-agnostic channel semantics (buffered/unbuffered, blocking/non-blocking send/receive, iterable consumption, explicit close) on top of the php-standard-library async layer — so you're not pinned to Swoole's API surface. If you're not already on an async runtime, "wait" is the correct answer and this evaluation can be shelved.
• Roadmap: is async PHP a real commitment or a spike? Adopting this package is a small, reversible bet that only pays off if the larger async bet (RoadRunner/Swoole/FrankenPHP worker mode + fibers) is already funded. Treat it as a trailing indicator of that commitment, not a leading one. Do not adopt this to create an async strategy.
• Use cases that survive scrutiny:
  • Fan-out within one job/request: issue N independent I/O calls (multiple upstream APIs, sharded DB reads) and join results — the classic case where sequential latency dominates.
  • Bounded worker pools in long-lived workers: a fixed set of consumers pulling from a shared channel, with buffer size acting as the backpressure knob for memory.
  • Multi-stage pipelines: fetch → transform → persist as connected channels, so slow stages can't unbounded-buffer into OOM.
  • Graceful shutdown: close semantics give a defensible "drain then stop" behavior for dequeued workers on deploy — a real operational win over exit mid-job.
  • Deterministic async testing: replace a real network dependency with an in-memory channel to make concurrent code testable without live services.
• Use cases that should be rejected at review: cross-service messaging, "replacing Redis/RabbitMQ," durable work distribution, anything that must survive a process restart, and anything requiring polyglot consumers. Those are queue/bus problems. Route them to Laravel Queues.
• Positioning decision to make explicitly: define the internal rule before piloting — channels for coordination inside a worker; queues for work that must survive; HTTP/message bus for crossing machines. Publishing that rule is more valuable than the package itself, because the failure mode here is developer confusion about which primitive to reach for, not a bug.

When to Consider This Package

Adopt if:

• You already run a persistent-worker runtime (RoadRunner, Swoole, FrankenPHP worker mode) or fibers via Revolt, and you have a measured latency problem caused by sequential I/O inside a single unit of work.
• You need bounded, backpressured coordination that Laravel's queue system models poorly — e.g., a pool of consumers where buffer size must cap memory.
• You want the channel API to be portable across runtimes rather than committing to Swoole\Channel, which is a runtime lock-in.
• You're prepared to wrap it behind your own interface (a thin ChannelFactory/adapter) so a future swap to Revolt, Swoole, or a rewrite costs days rather than a refactor.

Look elsewhere if:

• You need durability, retries, or at-least-once delivery. Messages here die with the process. Use Laravel Queues, Redis, or a broker.
• You need cross-process, cross-container, or cross-language communication. Use NATS, RabbitMQ, gRPC, or SQS. This is not a substitute and no amount of wrapping makes it one.
• Your deployment is request-per-process PHP-FPM with no fiber usage. There is no concurrency to coordinate; the package is dead weight.
• The team has no async debugging experience. Deadlocks and buffer-starvation bugs are diagnosed by reasoning about scheduling, not by reading stack traces. Underestimate this at your peril — it is the single largest hidden cost.
• You need SLAs, commercial support, or a large pool of Stack Overflow answers. The split repo shows 1 star and 0 dependents; the real project is the php-standard-library monorepo, so the star count is misleading — but the operational point stands: you are your own support tier.
• You need built-in observability. There are no metrics, timeouts, or backpressure telemetry documented. If you can't instrument buffer depth and blocked consumers yourself, you can't operate this in production.

Diligence before committing (half a day, not a sprint):

1. Read the docs and release notes on the umbrella php-standard-library repo — this package's release notes are one-line pointers, so the split repo tells you nothing about breaking changes.
2. Read the channel tests to establish actual close/error semantics (what does a send to a closed channel do? a receive on empty-but-open?).
3. Confirm it works under your runtime, not a generic one — behavior differs across Swoole, RoadRunner, and plain fibers.
4. Pin an exact version and wrap it. A single-maintainer-adjacent dependency should never be imported directly across the codebase.
5. Verify licensing/attribution fit — MIT, so low friction, but record it in your dependency register.

How to Pitch It (Stakeholders)

For executives — frame it as a contained optimization, not a platform play.

"We're evaluating a small library that lets parts of our worker code do several I/O operations at once instead of one after another. It's a targeted fix for specific slow paths, roughly a few days of engineering, MIT-licensed, and fully reversible. It is not a replacement for our queue or message infrastructure, and it doesn't change our architecture."

Be explicit about what it is not, because the attractive-sounding version of this pitch is false. An exec who approves it believing it replaces Redis will judge the team on a promise the technology can't keep. The credible outcome statement is: "reduce tail latency on N identified code paths; no infrastructure change; no new operational surface."

For engineering leadership — lead with blast radius and the honest tradeoffs.

"This gives us Go-style channels for coordination inside a single worker process. It's genuinely useful for worker pools, pipelines, and running independent I/O in parallel.

Three things to be clear about: (1) It's in-process only — zero value for service-to-service communication, so it does not touch our messaging architecture. (2) No persistence — anything in flight is lost on restart, which is fine for coordination and unacceptable for work. (3) The real cost isn't the library, it's the async debugging skill — deadlocks and buffer starvation are hard to diagnose, so this only makes sense where we already run persistent workers.

Recommendation: pilot on one non-critical path — parallel enrichment calls in a single job, or drain-on-shutdown for one worker type — behind our own adapter interface, with a named owner and a rollback plan. Keep it off the critical path until we've operated it for a release cycle."

For developers — show the shape, name the sharp edges.

"Channels are a coordination primitive: producers and consumers on either side of a single in-process boundary, with the buffer size as your backpressure knob. Buffered or unbuffered, blocking or non-blocking send/receive, foreach to consume, explicit close.

Use it for: parallel independent I/O in one unit of work, bounded worker pools, multi-stage pipelines, clean shutdown of long-running workers. Do not use it for: anything that must survive a restart, anything that leaves the process, anything another language needs to read.

Two rules. Wrap it — nobody imports the library directly; everything goes through our adapter. Instrument it — if you can't see buffer depth and blocked-consumer counts, you can't debug it at 3am."

One line to keep out of every deck: "This lets our microservices talk to each other without HTTP." It doesn't, and shipping a pilot on that premise guarantees a failed evaluation of what is otherwise a reasonable, narrowly-scoped library.