Http Server Laravel Package

Technical Evaluation

What this package actually is. amphp/http-server is not a Laravel package and should not be evaluated as one. It is a process-owning, non-blocking HTTP/1.1 and HTTP/2 application server built on the Revolt event loop and Amp v3 coroutines (PHP fibers). Installing it via Composer is trivial; adopting it means giving up PHP-FPM's request-per-process model and the implicit guarantees Laravel is built on. The correct framing for the portfolio is: "a candidate runtime for a narrow set of high-concurrency surfaces," not "a library we add to the app."

Architecture fit. Strong fit for workloads defined by long-lived connections and high fan-out: WebSocket servers, server-sent events, streaming APIs, webhook ingestion, notification fan-out, and internal high-RPS JSON endpoints. Poor fit for anything that resembles a conventional Laravel CRUD application, because the library's central constraint is explicit and absolute: no blocking I/O in the handler. Nearly all of PHP's built-ins (PDO/mysqli, file_get_contents, curl_exec, sleep, the blocking Redis extension) halt the whole worker, which in a single-threaded event loop stalls every concurrent request, not just the offending one. Laravel's Eloquent, its filesystem adapter, its cache and queue drivers, and most of its ecosystem packages are blocking by default. The README's own sleep(5) example is precisely the failure mode a Laravel team will hit on day one.

The escape hatches exist but each carries cost: amphp/mysql, amphp/postgres, amphp/redis, amphp/file, amphp/http-client for non-blocking I/O, and amphp/parallel to push genuinely blocking work to a worker pool — which reintroduces IPC serialization overhead and a second failure surface.

Integration feasibility. Mechanically feasible, architecturally expensive:

• No PSR-7/PSR-15 bridge. Amp\Http\Server\Request/Response are Amp-native. It exposes a PSR-7 UriInterface, but there is no drop-in Symfony HttpFoundation or Laravel request adapter. You write the adapter, and it becomes load-bearing infrastructure you own forever.
• You re-implement platform capabilities. Routing, sessions, body/form parsing, static files, and CORS are all separate packages (some third-party). Laravel supplies all of this out of the box; here it is an assembly exercise with its own version matrix.
• Two HTTP stacks, two mental models. If the sidecar shares auth, session, or cookie semantics with the Laravel app, those contracts must be defined explicitly (signed JWTs, a shared session store, or a token introspection call — the last of which must itself be non-blocking).

Technical risk. Medium-to-high, concentrated in four places:

1. Head-of-line blocking. A single stray blocking call degrades the entire worker. This is a code-review-enforceable invariant, not a config toggle, so it needs linting/static analysis and reviewer discipline.
2. Bus-factor and version churn. Amp v2→v3 was a fibers-driven, breaking rewrite. Pin the major version and budget for migration work; the maintainer base is small and there is no commercial support tier.
3. Ecosystem signal. The supplied metadata shows 0 dependents, which is almost certainly a data artifact (the router, session, and WebSocket packages depend on it) but must be verified on Packagist before it is used as a go/no-go input. Do not let a composite score of ~41 substitute for this check.
4. Proxy/header trust. createForBehindProxy() requires a trusted-proxy allowlist and a ForwardedHeaderType. Misconfiguration here silently breaks client-IP logging, rate limiting, and audit trails — a security-adjacent defect, not a cosmetic one.

Key questions for the evaluation. What are the concurrency and latency targets that PHP-FPM + OPcache demonstrably cannot meet? Do we need HTTP/2 and WebSockets in the same process, or can a managed service cover it? What percentage of the target endpoints touch the database, and can those paths use amphp/mysql/amphp/postgres? Have we benchmarked Laravel Octane (Swoole/RoadRunner/FrankenPHP) first — it solves persistent-worker performance with far less disruption? Who owns this runtime in production, and do we have an exit plan if the project stalls?

Integration Approach

Stack fit. Treat this as an adjacent runtime, not a replacement runtime. It owns its own process and its own listening socket; it cannot be hosted inside php-fpm or as a Laravel service provider. The viable shape is a Composer package inside the same monorepo (or a sibling service), deployed as a separate container behind the same load balancer, sharing auth contracts and observability conventions with the Laravel application.

Recommended architecture — sidecar first. Stand up the Amp server for exactly one bounded surface: WebSocket/SSE fan-out or a single high-RPS streaming endpoint. Laravel remains the system of record, the admin surface, and the home of all business logic. The sidecar handles connection lifecycle and transport only, and reaches back to Laravel through a non-blocking HTTP client for authorization decisions, caching the result briefly to keep fan-out cheap.

Migration path. Do not attempt a "port Laravel to Amp" project. It is unbounded and fails on the blocking-I/O constraint. The tractable path is endpoint-by-endpoint extraction of a new surface, never a rewrite of an existing one. If the goal is general application throughput rather than real-time capability, Octane is the lower-risk answer and this evaluation should conclude "no" early.

Compatibility checklist before any code is written:

• PHP 8.1+ is a hard floor — confirm the platform standard is already there.
• Verify the release tag and semver line on Packagist/GitHub; the date in the supplied metadata should be confirmed against the live registry before pinning.
• Confirm the middleware we need exists: router (amphp/http-server-router), body parsing, sessions, static content, and third-party CORS. Enumerate each as a separate dependency with its own maintenance status.
• Decide TLS termination explicitly. HTTP/2 in browsers is effectively TLS-only, so either the server terminates TLS (cert rotation, cipher config, renewal automation land on us) or an upstream proxy does, and we use createForBehindProxy() with a correct trusted-IP list.
• Optional nghttp2 FFI acceleration: treat as a tuning step, not a prerequisite; it adds a native dependency to the image.

Sequencing.

1. Spike (2–3 weeks). Run the README sample behind the real proxy, reproduce the blocking-I/O failure deliberately, and measure concurrency and memory against the current PHP-FPM baseline on the actual target endpoint.
2. Thin adapter + one endpoint. Build the Laravel-facing adapter (request/response mapping, auth, structured logging) and ship one non-critical surface to staging.
3. Observability and runbooks. Establish metrics, health checks, signal-based graceful shutdown, and a documented "this endpoint is on Amp" map before any customer traffic.
4. Production pilot behind a feature flag with a fallback path to the PHP-FPM implementation.
5. Decide. Expand only if the pilot shows a measured win the existing stack cannot deliver; otherwise retire the spike and close the ticket with the benchmark as the record.

Operational Impact

Maintenance. This is infrastructure, not an application dependency, and it will be maintained like infrastructure. Expect a permanent internal owner responsible for the runtime, the adapter, and the dependency graph of companion Amp packages. Version upgrades are planned work items with a staging rehearsal, not routine composer update noise — a major-version bump in Amp has historically been a breaking change across the whole call stack.

Support model. Community-supported OSS under MIT, no vendor SLA, no security-response commitment. The practical mitigation is version pinning, an internal fork-or-patch capability, and a documented fallback to the PHP-FPM implementation for the pilot surface. Escalate the bus-factor question to architecture review rather than absorbing it silently.

Scaling. Each worker is single-process and single-threaded; concurrency comes from cooperative scheduling, not parallelism. Scale out with more workers/Supervisor units and horizontally behind the load balancer. CPU-bound work — PDF generation, image processing, heavy serialization, synchronous encryption of large payloads — must be offloaded to amphp/parallel or to a queue, or it will serialize the worker. Memory is the sharper edge: long-lived WebSocket connections and per-coroutine buffers accumulate, so set and monitor connection ceilings (the direct-access constructor defaults to 10 connections per IP, 1,000 total, 1,000 concurrent requests — validate these against real traffic and expected NAT/proxy client-IP collapse).

Failure modes to instrument and runbook:

• Blocking call in a handler → whole-worker stall, latency cliff across unrelated requests. Detect with per-request duration histograms and a static check in CI.
• Unhandled exception or fatal in the event loop → worker death, all connections dropped at once. Requires process supervision with restart and connection-drain semantics on deploy.
• Connection-limit exhaustion behind a proxy or NAT, surfacing as 503s from a single source IP.
• Blocking logging. Writing to a synchronous log handler inside the loop reintroduces the problem; logs must go through a non-blocking stream or a UDP/agent sink.
• Silent Forwarded/X-Forwarded-For misconfiguration → wrong client IPs in logs, rate limits, and audit records.
• Graceful shutdown. Deployments must send SIGTERM and let in-flight requests finish; a hard kill on a streaming service is a visible customer incident.

Ramp-up. The real cost is cognitive, not licensing. Engineers must think in fibers and the event loop: understanding that a request handler is a coroutine, that await-style suspension is where interleaving happens, and that shared mutable state across coroutines is a hazard. Budget 2–4 weeks of structured onboarding for two to three engineers, plus a written internal standard covering the blocking-I/O prohibition, the approved non-blocking client libraries, and the adapter contract. Debugging across fibers produces less familiar stack traces, and there is no Laravel Telescope/Debugbar equivalent — expect slower incident diagnosis until the team has lived through a few. That learning investment is only justified if the pilot demonstrates a capability gap the current stack genuinely cannot close.