Http Server Laravel Package

Technical Evaluation

What this package actually is. hyperf/http-server is the HTTP server component of Hyperf, a coroutine-native PHP framework built on Swoole/Swow. It is not a Laravel package: there is no service provider, no publishable config, no facade, and no integration with Laravel's HTTP kernel, router, middleware pipeline, or container. It supplies the server bootstrap, request/response bridging (PSR-7/PSR-17), and dispatcher wiring that Hyperf's own framework layer consumes.

What v3.2.0 tells us. The release notes are a framework-wide changelog, not a component changelog. There is not a single http-server-specific entry in a 60+ item release note. This is decisive evidence for the core finding: the package has no independent surface, no independent versioning, and no independent change review. It ships as a passenger on the Hyperf monorepo train.

The release is a hard-breaking minor:

Architecture fit — poor as a Laravel dependency, unchanged. The component assumes:

• A PSR-11 container owned by Hyperf's DI, with Hyperf-specific annotations and #[Inject] semantics.
• A long-lived, coroutine-scoped runtime where each request executes inside a coroutine context (Hyperf\Context\Context), not a fresh PHP-FPM process.
• Hyperf's Config, EventDispatcher, and Server abstractions already registered.

Laravel's request lifecycle is synchronous and per-request; its container is not coroutine-aware. Grafting this component in means running a second application kernel alongside Laravel's, which is an architecture change, not an integration.

An under-noticed strategic signal. A meaningful share of v3.2.0's "Added" list is Hyperf re-implementing conveniences Laravel already has: Htmlable for responses, toJson on Jsonable, Macroable on Context, Pipeline::finally(), Collection::shift()/pop() multi-item, Arr::partition()/reject(), Fluent improvements. For a Laravel shop this is a direct cost signal: adopting Hyperf means rebuilding ergonomics you get for free, and maintaining them forward as the framework catches up.

Integration feasibility: low for the stated stack. Realistic options:

The only defensible reason to touch this package remains: the organisation is already committing to Hyperf for a new coroutine-based service. In that case it is a default dependency, not a selection.

Technical risk — revised upward.

• Adoption signal is weak. 10 stars, unknown/unspecified repository, composite score ~13. No independent community validation, no third-party forks, no external patch stream. Upstream is the only support channel.
• Breaking-change load per minor is high and broad. v3.2.0 breaks Carbon semantics, two config schemas, a public interface method, a dependency floor, and removes five-plus deprecated surfaces. This is a minor version. Treat every Hyperf bump as a migration project.
• Pinning this package pins the framework. Already true; now empirically demonstrated. You cannot take an http-server patch without inheriting the Carbon v3 semantics change and the logger/cache config rewrites.
• Metadata anomaly partly corroborated, still unverified. The earlier flag on the 2026-06-07 release date is consistent with content referencing PHP 8.4 polyfills and Symfony 7.4, but the exact tag type (stable vs. RC vs. placeholder) still needs registry verification before any lockfile references it.
• Documentation quality is a live risk. The Carbon BC section ships with copy-paste guidance where the wrong and right examples are byte-identical. A maintainer team that lets that through will also let migration notes through for config schema changes. Budget for reading source, not changelogs.
• Extension-level runtime dependency. Swoole 5.x (or Swow, now with an extra required binding) must be compiled and managed. Infrastructure commitment, not a Composer line item.
• Coroutine safety of existing code. Static state, request-data-holding singletons, blocking I/O — all misbehave under coroutine multiplexing. Still the largest hidden cost.

Key questions for the team. (Q1–Q3 revised in light of v3.2.0.)

1. Is the actual requirement "reduce per-request bootstrap cost," or "adopt a coroutine programming model"? Only the second justifies evaluating Hyperf — and v3.2.0 shows the second now carries a recurring breaking-change budget, not a one-off cost.
2. Who absorbs the v3.2.0 config migrations (logger, cache), the Carbon v3 semantic change, and the getQueueName() → getPoolName() rename — and on what schedule? If the answer is "nobody yet," the evaluation is premature.
3. Does any target environment run PHP 8.4 today, and if so, has the CSV escape change been audited? And does the service use Swow, in which case the ResponseEmitter binding is a required config step that fails silently if omitted?
4. Which exact Hyperf version does this release correspond to, and is 2026-06-07 a stable tag, an RC, or a metadata artifact? Confirm before pinning.
5. Who owns the Swoole/Swow build and runtime upgrades for the next 24 months?
6. Does any existing service already run Hyperf, or would this be the first? If none, v3.2.0 is the release that establishes your migration tax baseline.
7. Has Laravel Octane (Swoole/RoadRunner/FrankenPHP drivers) been benchmarked against the target workload? Nothing in v3.2.0 changes this comparison — Octane is unaffected by every item in this changelog.

Integration Approach

Stack fit. None at the application layer. Laravel and Hyperf are parallel ecosystems with incompatible lifecycles. The component's natural home is a new Hyperf service within a polyglot PHP estate, communicating with Laravel services over HTTP or a message bus.

Migration path. There is still no incremental path from a Laravel app to this package. v3.2.0 adds a mandatory pre-step: any PoC config written before this release must be rewritten to the new logger and cache schemas. Revised sequencing:

1. Confirm the performance hypothesis. Benchmark the existing Laravel service under realistic load; capture p50/p95 latency, requests/sec, memory per request.
2. Benchmark Octane first. Octane delivers most of the bootstrap-cost win with a Laravel-native API and no kernel rewrite. If Octane closes ≥70% of the gap, stop here. This release gives no reason to reconsider that gate.
3. If coroutines are genuinely required, scope a new, bounded service as a Hyperf proof of concept — pinned to a specific 3.2.x patch, with logger and cache configured in the v3.2 schema from day one and the Swow ResponseEmitter binding documented if Swow is used.
4. Model the upgrade tax explicitly before committing: take the v3.2.0 breaking-change list, multiply by historical minor cadence, and present that as an annual engineering cost line to the same approver who sees the Octane alternative.
5. Only then consider strangler-style extraction of high-throughput endpoints.

Compatibility. PHP ≥8.2 is now a hard floor (verify against the specific Hyperf 3.2 patch). Symfony ^6||^7, phpunit ^11, nikic/php-parser 5.6, Guzzle ^7, ES ^8||^9, protobuf ^3.6.1||^4.2. Swoole 5.x or Swow (with the required ResponseEmitterInterface binding). Strict PSR-7/15/17 compliance. Middleware, logging, and tracing must be re-implemented against Hyperf contracts; Laravel middleware does not port. Note the likely divergence: if the Laravel estate is on PHP 8.1 or Symfony 5, the Hyperf sidecar needs its own base image and cannot share the app image — a standing build-and-patch cost for a single service.

Sequencing recommendation. Unchanged in shape, tighter on scope: a spike with a kill gate, capped at 2–3 engineer-weeks, pinned to Hyperf 3.2.x. Success criteria: sustained throughput under a realistic mix, zero coroutine-context leaks over a 24-hour soak, a documented operational runbook, and a completed dry-run of one dependency upgrade end-to-end (to measure the real migration tax rather than estimate it). Absent all four, retain Laravel + Octane and revisit in 12 months.

Operational Impact

Maintenance. The package has no independent release cadence — it versions with Hyperf, and v3.2.0 is the proof: a framework-wide breaking release with zero component-specific entries. Upgrading means upgrading the framework, the DI container, the config schemas, and the runtime together. Revised budget: one coordinated migration per Hyperf minor is no longer sufficient — assume a multi-day migration per minor and a multi-week project per major. v3.2.0 alone requires: config rewrites (logger, cache), a source rename (getPoolName()), a Carbon v3 semantics audit, a PHP floor bump, a Symfony 6/7 and phpunit 11 alignment, and verification of five-plus removal sites. Low star count means no community patches; upstream issues are the only channel.

Support. MIT, community-supported, no vendor SLA. Internal ownership must be explicit: someone needs deep Swoole fluency and enough Hyperf fluency to read source because the release notes are unreliable (the identical before/after Carbon snippets are a concrete example). Identify that person before commitment. Additionally: the PHP 8.4 CSV escape warning and the silent-if-omitted Swow binding both argue for a documented internal "Hyperf upgrade checklist" rather than relying on upstream docs.

Scaling. Unchanged and still strong on paper: fixed worker pool, no per-request bootstrap, efficient connection handling, horizontal scale by adding pods. Capacity planning shifts from CPU-per-request to worker-count × memory-per-worker, and long-lived workers accumulate state. Right-sizing worker_num, max-request-per-worker, and pool sizes is a first-class operational concern with no PHP-FPM analogue. One genuine v3.2.0 positive: async-queue consumers can now auto-register from configuration instead of manual processes.php entries, which removes a recurring source of deploy drift.

Failure modes to instrument for.

• Event-loop blocking. Synchronous I/O (legacy PDO, file reads, sleep) stalls the entire worker. Detect via event-loop lag metrics.
• Coroutine context leakage. Request-scoped data surviving across coroutines causes cross-request data bleed — a correctness and potentially a data-isolation incident.
• Silent misconfiguration after upgrade. The v3.2 logger/cache restructures and the Swow ResponseEmitter binding do not fail loudly; they fail as missing logs, cache misses, or broken response emission. Add a post-upgrade smoke test asserting each channel and store resolves.
• Carbon v3 semantic drift. diffInDays() no longer defaults to absolute, and timezone resolution for createFromTimestamp() changed. This surfaces as subtly wrong business logic, not as an error. Audit every date computation on the service boundary.
• Memory growth. Long-lived workers accumulate references; without per-worker request caps, OOM arrives slowly and unpredictably.
• Connection pool exhaustion. MySQL/Redis pools are per-worker and finite; saturation surfaces as timeouts rather than clear errors.
• Graceful restart gaps. Deploys must drain in-flight coroutines; naive rollouts drop requests.
• Cold-start / readiness. Worker warm-up and health-check semantics differ from FPM; existing probes misreport.

Ramp-up. 4–8 weeks before a mid-level PHP engineer is productive, considerably longer before anyone debugs production incidents unaided. v3.2.0 adds a second ramp curve: even a fluent Hyperf engineer must re-learn the logger, cache, Carbon v3, and async-queue surfaces. The mental-model shift (coroutines, shared state, non-blocking contracts) remains the dominant cost, not the API. Plan a formal internal enablement track and pair the first service with someone who has Swoole production experience.

Bottom line. v3.2.0 does not change the verdict — it hardens it. For a Laravel shop, hyperf/http-server is not an integration candidate; it is a signal that the team is contemplating a framework-level shift, and this release quantifies what that shift costs per minor. The TPM recommendation: keep it out of the dependency graph, validate the performance requirement against Laravel Octane (untouched by every item in this changelog), and reopen only if a deliberate, separately-staffed Hyperf service is funded — with the v3.2.0 breaking-change list accepted up front as the recurring price of admission.