Http Server Laravel Package

Product Decisions This Supports

1. Runtime model for the HTTP layer (build vs. buy vs. keep FPM). This package is a decision-enabler for "do we move off PHP-FPM's one-process-per-request model?" It is a non-blocking HTTP/1.1 + HTTP/2 server on the Revolt event loop, so a single worker handles many concurrent requests cooperatively. That is a distinct third option from (a) staying on FPM, (b) Laravel Octane on Swoole/RoadRunner/FrankenPHP, or (c) rewriting the hot service in Go/Node. A PM can frame it as "rent concurrency in PHP rather than buying it with more containers or a rewrite."

2. Real-time and streaming roadmap items. Server-Sent Events, streaming/chunked responses, long-polling, and WebSocket endpoints (via amphp/websocket-server) are first-class here rather than bolted on. This directly supports roadmap bets like live notifications, progress feeds for long jobs, collaborative editing, or dashboards — features that are awkward and connection-expensive under FPM.

3. "Aggregator" and gateway use cases — the strongest fit. The highest-leverage use case is a service whose job is waiting on many other services: a BFF/edge gateway, webhook ingress and fan-out, an internal API composition layer. With amphp/http-client, amphp/mysql, amphp/redis, a handler can issue N downstream calls concurrently instead of serially. That is a latency and cost story, not a language-purism story.

4. Capacity and infra cost planning. Because handlers are coroutines, throughput becomes a function of I/O wait rather than process count. This supports decisions about container sizing, autoscaling targets, and whether to reduce instance count — but only after a benchmark spike (see below), because the same property makes a single blocking call catastrophic.

5. Scope boundary: this is not a Laravel feature decision. Despite the brief, this is not a Laravel package. There is no service provider, no container/Blade/Eloquent/Sanctum integration, and no Octane driver shipping here. Routing, sessions, form parsing, and static files live in separate Amp packages you assemble yourself. The real product decision is whether to stand up a second PHP runtime profile alongside the Laravel monolith for one or two focused services — not whether to adopt a library inside the app.

6. Dependency and maturity signals to weigh, not ignore. MIT licensed, actively released, 1.3k stars, PHP 8.1+. The package itself shows 0 dependents in this registry snapshot, which reads as "small direct-adoption footprint" — but the underlying Revolt/Amp primitives are used broadly across the PHP tooling ecosystem (including PHPUnit's parallel runner), so the concurrency core is credible even where this specific server is niche.

When to Consider This Package

Adopt-capable criteria — all should be true:

• The workload is I/O-bound and concurrency-heavy. Many simultaneous connections, slow upstream dependencies, fan-out/fan-in, or long-lived streams. If your traffic is low-concurrency CRUD, this buys you nothing and costs you a paradigm shift.
• You can keep the hot path 100% non-blocking. The README's central warning is the whole risk model: any sleep, file_get_contents, mysqli_query, or blocking PDO call halts the loop and stalls every in-flight request. That means a non-blocking driver for every dependency (Amp's MySQL/Postgres/Redis/file/HTTP client, or amphp/parallel offload).
• You accept assembling the stack. Router, session, static content, form parser, CORS (third-party) are separate packages with their own maturity. Budget for integration and for writing your own error handler for anything beyond the default HTML page.
• The team will invest in the Future/coroutine/combinator mental model. This is the real adoption cost — larger than the install.
• You own the process lifecycle. Long-lived workers mean your own supervisor (systemd/Kubernetes), restart policy, memory-leak monitoring, graceful shutdown via signal handling, and TLS termination either in-process or behind a trusted proxy (createForBehindProxy() with an explicit trusted-IP list).
• You need HTTP/2 now and optionally nghttp2 FFI for lower memory/CPU.
• A spike cleared the gates: a 1–2 week prototype of one real endpoint, a load test against the current FPM/Octane baseline, and an intentional blocking-call test to see the blast radius.

Look elsewhere when:

• The product is a conventional Laravel monolith with Eloquent/PDO, Blade, queues, and the usual first-party packages. Octane (or plain FPM plus a queue) is the lower-risk answer; Horizon, Telescope, and most ecosystem packages assume a request-scoped or supported-runtime model.
• The team cannot absorb async debugging. Stack traces across coroutines and "why did one slow query freeze the server" incidents are a real operational tax.
• You need framework conventions more than raw throughput — validation, DI, auth scaffolding, migrations. You would be building a micro-framework.
• Hiring/community depth is a constraint. Swoole, RoadRunner, and FrankenPHP have larger mindshare and vendor-backed Laravel support; this is a smaller, expert-oriented community.
• You need HTTP/3, mature L7 proxy features, or serverless/managed hosting. This is a library, not an edge platform.
• The throughput gain is unproven. If a benchmark doesn't show a material win over the current architecture, the paradigm cost is unjustified.

How to Pitch It (Stakeholders)

One-paragraph summary for executives: We have evaluated amphp/http-server, an MIT-licensed, actively maintained async HTTP server for PHP 8.1+. It lets a small number of PHP workers hold thousands of simultaneous connections and wait on many downstream services at once, which is directly relevant to our streaming/real-time roadmap and to any service that is mostly waiting rather than computing. It is not a like-for-like Laravel add-on — it is a different runtime model with real operational preconditions. Recommendation: fund a short, time-boxed spike on one non-critical service, with a hard go/no-go benchmark, rather than a platform commitment.

For engineering:

• It is a credible, non-blocking HTTP/1.1 + HTTP/2 server with TLS, GZIP, middleware, streaming, and a companion WebSocket server — the primitives you'd need for SSE and real-time endpoints.
• The cost is architectural discipline: no blocking I/O on the server, non-blocking drivers for all data access, custom error handling, and process supervision for long-lived workers. One blocking call degrades every concurrent request — this must be enforced by review and tooling, not convention.
• Routing, sessions, and static serving are separate packages; we own the assembly and the integration surface.
• We should benchmark against our current stack and against Octane before committing.

For product/roadmap:

• Unlocks capabilities we currently de-scope or work around: live progress feeds, streaming responses, long-lived connections, low-latency aggregation of multiple backend calls.
• Could reduce infrastructure spend for I/O-heavy endpoints by raising per-instance concurrency — a hypothesis to validate, not a promise.
• Delivers nothing for standard CRUD screens; do not position it as a general platform upgrade.

Decision requested: approve a 2-week, one-service spike with defined success criteria (p95 latency and connections-per-instance vs. baseline; no blocking calls in the hot path; clean failure behavior under load). Outcome is a go/no-go memo, not a migration.