Amp Laravel Package

Product Decisions This Supports

• Build vs. buy for async I/O: Choosing whether to build concurrency primitives in-house (custom futures, callback plumbing, timeout handling) or adopt a proven MIT-licensed primitive. amphp/amp is the "buy" answer for futures + cancellation in PHP; it deliberately does not own the event loop (Revolt does), so the decision splits into two: adopt Amp for primitives, adopt Revolt for scheduling.
• Latency/cost roadmap for I/O-bound features: Any feature that fans out to multiple backends (search, pricing, recommendations, profile hydration, third-party enrichment) can be modeled as "sequential sum of waits" vs. "max of waits." This package makes the second option a library-level choice rather than an architecture rewrite.
• API aggregation / BFF layer: Future\await(), awaitAnyN(), awaitFirst(), and awaitAny() map directly to product behaviors — best-effort partial results with awaitAnyN, fail-fast with await, race-a-mirror with awaitFirst. That is a product decision (graceful degradation) expressible in a few lines of code.
• SLO and timeout policy: Explicit Cancellation objects make "abort downstream work when the client disconnects or the budget expires" a first-class, enforceable policy rather than best-effort cleanup. Supports decisions about strict deadlines, retry budgets, and load-shedding.
• Long-running / real-time capability roadmap: A credible path (with amphp/socket, amphp/http-server, amphp/websocket) toward workers, queues, SSE, and WebSocket endpoints that are hard to do cleanly on request-per-process PHP-FPM.
• Throughput-driven capacity planning: Fewer worker processes doing more concurrent I/O can reduce instance count. This is a concrete input to infrastructure spend and scaling decisions.
• Architecture standardization: Deciding whether the org standardizes on one async model (Amp/Revolt fibers) instead of accumulating a mix of Swoole, ReactPHP, and ad-hoc curl_multi. Standardization is a maintainability and hiring decision as much as a technical one.
• Deprecation/migration planning: Amp v3 dropped generator-based coroutines in favor of PHP 8.1 fibers. That constrains our minimum PHP version — a support-matrix and customer-compatibility decision, not just a dev-tooling one.

When to Consider This Package

Consider adoption when:

• Workloads are I/O-bound, not CPU-bound. Concurrent HTTP calls, DB queries, socket reads, stream processing. Fibers are cooperatively scheduled — a CPU-heavy loop still blocks the whole process.
• You are on PHP 8.1+ (hard requirement) and can commit to that floor organization-wide.
• You need cancellation and timeouts as real semantics, e.g. user navigates away, request budget exceeded, or a race winner is found — and you want those to propagate rather than leak.
• You are writing CLI workers, daemons, scrapers, queue consumers, or internal services where a long-lived process is acceptable and desirable.
• You are already in, or willing to enter, the Amp ecosystem. Amp's value compounds with amphp/http-client, amphp/socket, amphp/mysql. Alone, amphp/amp is a primitives library without batteries.
• You want no C extensions. No Swoole/parallel/pcntl requirement lowers deployment friction on managed PHP hosts and container images.
• You can accept a transitive dependency on revolt/event-loop and evaluate it as part of the same decision — the README is explicit that you should install Revolt directly.

Look elsewhere when:

• The application is a conventional blocking request/response app. Laravel/Symfony controllers on FPM with modest traffic rarely justify the cognitive and debugging load. Instrument first; optimize later.
• You want a batteries-included runtime for an existing framework. Laravel Octane (Swoole/RoadRunner) or FrankenPHP solves the "keep the app booted" problem with far less code change than rewriting call paths as coroutines.
• Work is CPU-bound. Use amphp/parallel or a job queue (amphp/* alone won't help) — or step outside PHP.
• The team has no async experience and no capacity to build it. Fiber code fails in unfamiliar ways: blocking calls silently poison the loop, DeferredFuture leaks appear as hangs, and stack traces cross suspension points. Budget for enablement, not just a Composer line.
• You need a large, framework-blessed integration surface. Amp is low-level; expect to write adapters for HTTP clients, ORMs, and logging. If nobody in the org has done this, the hidden cost is real.
• Regulatory or longevity constraints require multi-vendor backing. Amp is essentially a single-organization (AMPHP) ecosystem. Assess bus-factor and consider whether ReactPHP's broader contributor base matters more than API ergonomics.

Due diligence items before committing: (1) The reported dependents: 0 is almost certainly a registry-metadata artifact — treat true adoption as indirect through Amp's sibling packages and verify on Packagist/GitHub before reading it as a red flag. (2) Confirm release cadence against the changelog; a 2026-07-26 release with active tags is a positive maintenance signal, but pin minor versions and read upgrade notes, since v2→v3 was breaking by design. (3) Prototype one real feature end-to-end (e.g. a 5-way fan-out endpoint) and measure p50/p95 plus error-handling clarity, rather than benchmarking a synthetic loop.

How to Pitch It (Stakeholders)

For executives (one paragraph): We spend a meaningful share of our request time waiting — on databases, third-party APIs, and internal services — and we pay for servers that sit idle while waiting. amphp/amp is an MIT-licensed, actively maintained PHP library that lets the application do other work during those waits, using standard PHP 8.1+ features with no server extensions or new infrastructure. It also gives us enforceable timeouts and cancellation, which directly improves reliability and reduces wasted spend on abandoned work. The cost is a modest, one-time engineering investment in patterns and training, and it is reversible: it's a Composer dependency, not a platform commitment. Recommended next step is a time-boxed spike on one high-fan-out endpoint to quantify the latency and cost impact before any broader commitment.

For engineering leadership: This is the right primitive layer for concurrency in modern PHP. Fibers (8.1+) remove the callback/"function color" tax that made earlier async PHP painful — code reads synchronously but schedules cooperatively. Future with map/catch/finally, plus await, awaitAll, awaitAny, awaitAnyN, and awaitFirst, covers the composition patterns we actually need. First-class Cancellation solves timeout and client-disconnect cleanup properly. Scope honestly: this is a primitives library, not a framework. The event loop is revolt/event-loop and must be evaluated alongside it; real leverage comes from the sibling packages (http-client, socket, mysql, postgres). It is fiber-based cooperative concurrency, so any blocking call anywhere still blocks the loop — we need linting/review discipline and a clear rule that blocking I/O is banned inside coroutines. It also sets a PHP 8.1 minimum, so confirm that aligns with our support matrix and hosting.

For the sponsor/decision-maker: Three points. Value: lower p95 latency and fewer instances for I/O-heavy paths, plus better failure behavior under partial dependency outages. Risk: concentrated in one small ecosystem with a low-level API that has already had a breaking major version; mitigated by version pinning, an abstraction seam at our service boundary, and a spike before rollout. Ask: approve a two-week, one-engineer spike on a single fan-out endpoint with a go/no-go gate based on measured p95 improvement, code-review clarity, and onboarding time for a second engineer. If the spike fails, we lose two weeks and keep the current design.