Amp Laravel Package

Technical Evaluation

Architecture fit — poor as a general dependency, viable as a bounded concurrency kernel. amphp/amp is not an integration package; it is a primitives layer (futures, cancellation, Amp\async() coroutines over PHP 8.1 fibers) that delegates scheduling to Revolt's global event loop. Its entire value proposition depends on the process running non-blocking I/O. Laravel's default runtime is the opposite: one blocking request per PHP-FPM process, sequential execution, and a data layer (PDO, curl via Guzzle, phpredis) that blocks the calling stack. Dropping Amp into a Laravel request without also replacing the I/O path yields zero concurrency and adds a new mental model plus a global event loop for nothing. The fit becomes real only where a single request or CLI job must fan out to many independent I/O operations — aggregate several upstream APIs, query multiple read replicas, or coordinate cache lookups — and only if every call on that path is backed by an Amp-native driver (amphp/http-client, amphp/mysql, amphp/postgres, amphp/redis).

Integration feasibility — composer-install trivial, adoption cost material. composer require amphp/amp revolt/event-loop will resolve cleanly on any Laravel 10/11 app (PHP 8.1/8.2 satisfy the requirement, no extensions needed). The cost is not the install but the rewrite of the I/O path for whatever you touch. Eloquent and the DB facade are out of scope — you do not get concurrent Model::query(); you get concurrent raw queries through amphp/mysql in a separate connection pool, which means duplicating connection configuration, transaction handling, and query-building logic outside the ORM. That is a substantial bespoke adapter, not a package integration. The realistic integration shape is a thin internal service object that returns Futures, with Future::await() at exactly one boundary, so the rest of the application remains synchronous and unaware.

Technical risk — moderate to high, concentrated in three areas.

1. Silent head-of-line blocking. Any blocking call inside a coroutine (a stray file_get_contents, an Eloquent call, sleep(), a logging handler that writes synchronously) stalls the whole event loop, not just one task. This failure is invisible in code review and appears only as latency under concurrency.
2. Runtime model collision. Octane with Swoole brings its own coroutine scheduler and blocking hooks; running Revolt's loop inside a Swoole worker creates two competing schedulers with no supported bridging story. RoadRunner and FrankenPHP worker mode are less hostile but still own the worker lifecycle, so loop ownership and shutdown ordering must be designed rather than assumed.
3. Cancellation discipline. Cancellation is a first-class primitive here but nothing enforces it. If it is not threaded from request disconnect through to every in-flight future, background work outlives the client and quietly consumes worker capacity.

Data quality caveat. Two signals in the supplied metadata are unreliable and should be re-verified against Packagist and GitHub before any decision: "Dependents: 0" is implausible for a 4.4k-star foundational package that virtually every amphp/* library depends on, and a last-release date of 2026-07-26 cannot be genuine. Treat the score (59.4, opportunity 54.0) as directional only.

Key questions for the team.

• What is the measured latency and wall-clock cost of the specific workload we intend to accelerate? If a page's serial I/O is under ~200ms, concurrent execution buys nothing visible.
• Has Illuminate\Http\Client\Pool (concurrent request batching) or the Concurrency facade been evaluated first? Both solve the most common Laravel fan-out cases with zero new runtime semantics, and the Pool in particular covers the majority of Amp's practical value here.
• Are we running Octane, and if so under which server? Swoole is close to disqualifying.
• Do we have an owner willing to maintain an internal adapter layer indefinitely, including a major-version migration of both Amp and Revolt?
• Is PHP 8.1+ universal across all deploy targets and CI images, including any legacy service sharing the monorepo?

Integration Approach

Stack fit — narrow and deliberate. Target only workloads that are unambiguously I/O-bound and high-fan-out: an aggregation endpoint calling 5–15 upstream services, a CLI/queue job enriching records from several APIs, or a health-check/probe path that must hit many dependencies with a short deadline. Explicitly out of scope: anything CPU-bound (that is amphp/parallel, a separate and much heavier decision), anything needing Eloquent's identity map, relationship loading, or model events, and any code path reached from a standard web request that we are not prepared to make fully non-blocking.

Migration path — adapter pattern, one boundary, feature-flagged. Build App\Concurrency\AsyncRunner (or a small internal package) exposing plain synchronous methods that internally construct the event loop scope, dispatch Amp\async() tasks, Future\await() them, and return ordinary arrays or DTOs. Callers see no Future types, no Cancellation, no Revolt imports. This keeps the blast radius to one class and lets us revert by changing one binding. If the workload is genuinely long-running or must sustain high connection counts, the lower-risk alternative is a separate amphp/http-server service behind HTTP, leaving Laravel untouched — more operational surface, but no runtime coupling and no risk to the main application.

Compatibility — verified constraints.

• PHP 8.1+; rules out Laravel 9 and any 8.0 CI image.
• Requires revolt/event-loop as a sibling dependency — pin both, since their majors move together.
• No PHP extensions required; ev/uv/event only matter above ~1024 concurrent descriptors.
• Conflicts with Swoole coroutines under Octane; requires validation under RoadRunner/FrankenPHP worker mode before use in any Octane deployment.
• Third-party libraries on the async path must be fiber-safe (no static caches keyed on request state, no $_SERVER reads after suspension). Audit anything touched after an await.

Sequencing.

1. Spike (1–2 weeks). Port one high-fan-out endpoint in a branch using raw amphp/http-client, measure p50/p95 against the existing Http::pool() implementation. Gate: material latency win under realistic concurrency.
2. Adapter + guardrails (1 week). Land AsyncRunner, a coding standard forbidding blocking calls in async paths, and a static-analysis rule or grep check for file_get_contents/sleep/PDO in App\Concurrency.
3. Single production workload (2–4 weeks). Behind a config flag, with explicit timeouts and a Cancellation sourced from request lifecycle. Roll out to a small traffic percentage.
4. Second workload or stop. Broaden only if the first is clean for a full release cycle. Do not generalize to DB access until an amphp/mysql adapter is proven separately.
5. Defer event-loop-centric architecture (amp HTTP server, amphp/parallel) to a distinct decision with its own assessment.

Operational Impact

Maintenance — low code churn, high cognitive load. Amp's public surface is small and stable, but v3 was a ground-up rewrite from generator coroutines to fibers; a v4 will likely be breaking again. Budget for a coordinated Amp + Revolt major upgrade roughly every 18–24 months, plus a review of every internal async path against whatever semantics change. The adapter layer is the thing we own; treat it as production code with a named maintainer, not as glue.

Support — community-only. MIT-licensed, maintained by the AMPHP organisation, no commercial SLA, no vendor to escalate to. Issue turnaround depends on a small group of maintainers. Acceptable for a bounded internal use; not acceptable if the concurrency layer becomes load-bearing for revenue-critical paths without a documented fallback.

Scaling — helps with concurrency, not capacity. Fibers reduce wall-clock latency for I/O fan-out within a single process but do nothing for CPU throughput; a single core is still a single core, and CPU-bound work inside a coroutine starves everything. Watch three limits: file descriptors (default soft limit ~1024 constrains concurrent sockets), memory per suspended fiber (small but non-zero, and multiplied by concurrency), and, under Octane, per-worker memory that no longer resets between requests. Enforce a concurrency cap at the adapter level rather than allowing unbounded Amp\async() spawning.

Failure modes to instrument for.

• Loop stall. A blocking call serializes all coroutines; symptom is uniform latency inflation across unrelated concurrent tasks. Mitigation: periodic loop-lag watchdog that logs when a tick exceeds a threshold.
• Orphaned work. Futures without propagated cancellation continue after client disconnect, holding connections and worker capacity. Mitigation: mandatory Cancellation parameter, deadline on every adapter call.
• Swallowed exceptions. Amp errors surface on await(); a future that is never awaited, or a catch() that returns a default, silently loses failures. Mitigation: adapter always awaits or explicitly discards with logging; forbid fire-and-forget except through a helper that records errors.
• Double event loop. Under Octane, EventLoop::run() in a context where the loop is already running throws; under FPM the loop must be started and drained within the request. Mitigation: adapter owns loop lifecycle and asserts it, never callers.
• Shutdown with pending futures. Process exit mid-flight leaves partial writes and half-open connections; treat any async path that mutates state as requiring explicit drain-on-shutdown.
• Third-party fiber unsafety. Global or static state in a library touched after a suspension point leaks across coroutines within the same worker. Mitigation: keep the async segment dependency-light and pure I/O.

Ramp-up — 1–2 weeks to productive, 1–2 months to safe. The futures/cancellation model reads like synchronous code, which is the trap: it looks safe to a developer who does not yet know that one blocking call poisons the loop. Required onboarding: "what color is your function" framing, the cooperative-scheduling model, a hands-on exercise stalling a loop deliberately, and the review checklist (no blocking I/O, cancellation threaded, bounded concurrency, no unawaited futures). Pair that with an ADR recording why Amp was chosen over Http::pool() and the Concurrency facade, so the next engineer does not re-litigate it or, worse, remove the guardrails.

TPM recommendation. Conditional. The composite score (59.4) and a 54.0 opportunity rating fairly reflect a mature, well-regarded, narrow-purpose library. For a typical Laravel product, the correct answer is to reach for framework-native concurrency first and treat amphp/amp as a specialized tool for one or two proven high-fan-out I/O paths, isolated behind an internal adapter with a named owner. Adopt it as a platform-wide concurrency foundation only if we are separately committing to an async runtime (amp HTTP server or equivalent) — in which case that is a different decision, with a different assessment, and a much larger operational bill.