Http Server Laravel Package

Product Decisions This Supports

• Runtime and architecture choice for new PHP services: This remains the HTTP server layer of Hyperf, a coroutine-based PHP framework on Swoole/Swow. Adopting it is a decision to run a persistent-worker, coroutine runtime rather than the shared-nothing PHP-FPM model most Laravel teams use. Nothing in v3.2.0 changes that trade-off.
• Platform upgrade planning (new, material): v3.2.0 is a major-adjacent breaking release, not a patch bump. It changes logger and cache config structures, renames JobInterface::getQueueName() to getPoolName(), switches Carbon behavior to v3 semantics, removes long-deprecated shims, and raises the PHP floor to >=8.2. Treat upgrades as a scheduled platform migration with a regression budget, not a routine composer update.
• Business-logic risk review for date/time handling: The Carbon v3 change is the highest product-risk item. Carbon::createFromTimestamp() no longer falls back to date_default_timezone_get(), and diffInDays() no longer returns an absolute value by default. Any billing, SLA, trial-expiry, reporting, or aging logic that relies on these needs an audit — sign flips fail silently and produce wrong numbers, not errors. This is a PM-visible correctness risk, not just an engineering detail.
• Build vs. buy for HTTP plumbing: Still supplies routing, middleware, request/response handling, and DI/annotation integration. Teams on Hyperf should not rebuild these primitives. New contracts (Htmlable for responses, toJson on Jsonable) are incremental ergonomics, not reasons to adopt.
• Service roadmap for high-concurrency endpoints: Unchanged. Relevant where throughput, connection handling, and reduced per-request bootstrap cost matter; it is infrastructure, not a differentiated product feature.
• Data-store roadmap expansion (new): Added database-sqlserver plus Elasticsearch 8.x and 9.x support. This widens supported backends and search versions, which matters if the roadmap includes enterprise customers on MSSQL or an Elasticsearch 9 migration. It is a capability unlock, not a mandate.
• Queue/async operating model (new): Async queue consumers can now auto-register from configuration instead of manual processes.php entries, and queue names can be specified per job. This reduces boilerplate and makes per-tenant or priority queue separation cheaper to operate.
• Framework standardization: If Hyperf is an approved stack, this is a default platform component, not a separate product bet. If Hyperf is not approved, this package should not drive adoption on its own.

When to Consider This Package

Consider it when:

• The team has already selected Hyperf or is running a formal Hyperf proof-of-concept; this component is part of that framework's core HTTP stack.
• You need a coroutine/persistent-worker HTTP runtime and accept the operational implications: worker lifecycle, memory management, graceful reloads, observability, and different debugging patterns.
• You need routing, middleware, and request handling consistent with Hyperf's DI and annotation conventions.
• Upgrade readiness (new): you can satisfy PHP >=8.2, plan for the logger and cache config restructures, migrate any getQueueName() overrides to getPoolName(), audit Carbon timestamp/timezone and diffInDays() usage, and re-verify removed items (laminas-mime, CacheableSupportsMethodInterface, JobMessage BC serialization, and other v3.2-removed deprecated code).
• You can absorb the dependency floor changes: Symfony ^6.0 || ^7.0, PHPUnit ^11, nikic/php-parser 5.6, Guzzle ^7, protobuf ^3.6.1 || ^4.2. These constrain other packages in the same application.
• You are comfortable with framework-level lock-in and can pin versions and validate upgrades against the broader Hyperf release set.
• Provenance: v3.2.0 references concrete github.com/hyperf/hyperf PRs and a coordinated framework-wide release, which is strong evidence of an official, actively maintained source. This meaningfully reduces — but does not fully close — the earlier concern about an unknown repository and low standalone star count for the split package. Confirm the split package registry matches this release train before adopting.

Look elsewhere when:

• The product is a Laravel application. This is not a Laravel package and will not integrate as a normal Laravel HTTP kernel replacement. Use Laravel's own HTTP layer, Octane, or a dedicated runtime if performance is the concern.
• The team needs a standalone PSR-7/PSR-15 server without Hyperf's conventions and DI model.
• The organization requires commercial support, broad hiring pools, or mature Laravel-ecosystem tooling.
• The operational team cannot own Swoole/Swow extensions, persistent-worker tuning, and coroutine-safe code review.
• You cannot take the upgrade now (new): running PHP 8.1 or below, or unable to schedule the config and Carbon migration, is a reason to defer — not to run an unpinned older minor on a new build.

How to Pitch It (Stakeholders)

Executive summary: hyperf/http-server is not a drop-in Laravel package; it is the HTTP server component of the Hyperf coroutine framework. Its value is high-throughput PHP services on a persistent-worker runtime; its cost is a different operational model, framework lock-in, and a narrower hiring/tooling ecosystem. v3.2.0 reinforces the lock-in and upgrade-cost side of that ledger: it is a breaking release with restructured logging and cache configuration, a renamed async-queue API, Carbon 3 timezone and date-diff semantics, and a hard floor of PHP 8.2.

For engineering: Treat this release as a platform migration. Required work: migrate logger and cache config to the new default + channels / stores shapes; rename JobInterface::getQueueName() to getPoolName(); audit every Carbon::createFromTimestamp() and diffInDays() call site (sign and timezone behavior changed); verify Swow deployments add the ResponseEmitterInterface binding; sweep for removed deprecated code and dropped packages. Upside for the roadmap: SQL Server support, Elasticsearch 8/9 support, config-driven async queue consumer registration with per-job queue naming, a NonCoroutine test attribute, and Htmlable/Jsonable response contracts. The 2026-06-07 release is consistent with an actively maintained framework, and the PR trail points at the official Hyperf repository — still confirm the split package is published from the official organization and matches this release train.

Recommendation: Approve only as part of a broader Hyperf platform decision; do not introduce it into a Laravel codebase. If Hyperf is already strategic, adopt v3.2.0 deliberately: pin versions, allocate a migration sprint covering config, async-queue, and date/time logic, and run a bounded proof-of-concept on worker lifecycle, memory stability, graceful shutdown, observability, and rollback. Prioritize the regression pass over the date/time-dependent features (billing, SLAs, expiry, reporting) — those failures are silent. If the organization cannot operate Swoole/Swow services or cannot schedule the upgrade, defer and stay on a pinned, supported prior line.