Http Laravel Package

Technical Evaluation

• Architecture fit. roadrunner/http is a thin contract layer, not a framework. It implements the PSR-7 worker side of RoadRunner's request/response protocol: the Go server hands the worker a serialized request, the package hydrates a ServerRequestInterface, and it serializes the PSR-7 response back over Goridge. Its architectural value is that it lets any PSR-7-compliant PHP application (Slim, Mezzio/Laminas, custom PSR-15 middleware stacks, Nyholm/Diactoros/Laminas-based apps) run under RoadRunner with zero framework lock-in. It does not provide routing, DI, or middleware — those remain the app's responsibility. For Laravel or Symfony shops, this is the wrong layer: Octane and the Symfony Runtime component already wrap RoadRunner and you would bypass them at your peril.
• Integration feasibility. High. Composer install plus a worker bootstrap script plus a .rr.yaml; the package surface is small and the PSR-7 interfaces are frozen standards. The real integration cost is not this package — it is standing up the RoadRunner binary, worker lifecycle configuration, and a supervisor (systemd, Kubernetes, or the RR CLI). Any team already running PSR-7 middleware can be productive in days.
• Technical risk. Low technical risk, moderate ecosystem risk. The code path is stable and narrow; PSR-7 is a mature contract. But: 78 stars and 0 tracked dependents understate adoption (this is one of many small packages split out of the roadrunner-php org — roadrunner-worker, roadrunner-grpc, etc. — each individually modest), so treat those metrics as a data-quality signal rather than a demand signal. Mitigate by verifying Packagist download counts and the org's activity, not GitHub stars. The Last release: 2026-10-19 value is anomalous (future-dated) and should be reconciled before you put it in a dependency register.
• Key questions.
  1. Which PSR-7 implementation and PSR-15 middleware stack will the app standardize on?
  2. Is RoadRunner being adopted for performance, for its queue/HTTP/gRPC unified server, or opportunistically? The answer changes the migration scope.
  3. What is the pinning policy for the rr binary vs. the PHP client — do we track major versions together?
  4. Does the team already run Laravel Octane or Symfony Runtime, in which case this package is transitive infrastructure, not a direct dependency?
  5. Do we have anyone who will own a Go binary in the deployment pipeline?
  6. How will long-lived-worker state (singletons, static caches, opcache) be audited?

Integration Approach

• Stack fit. Correct choice for a PSR-7-native PHP 8.x application that is already containerized and behind a reverse proxy. Wrong choice as a first move for a Laravel or Symfony monolith — use Octane or the Symfony Runtime, which consume this package (or its siblings) internally. If the goal is "keep our PSR-7 code, swap the runtime," this is precisely the intended use case.
• Migration path. Do not do a big-bang cutover. Sequence as a parallel-path migration:
  1. Baseline current PHP-FPM latency/throughput on a representative endpoint set.
  2. Build a throwaway spike: one worker script, one .rr.yaml, one endpoint, run locally against the same code.
  3. Measure. Only proceed if the numbers justify the operational delta.
  4. Containerize the RR binary + worker alongside the existing image; deploy to staging behind the same ingress.
  5. Canary a slice of production traffic; keep the FPM deployment hot for rollback.
• Compatibility. Verify the version matrix up front: psr/http-message version, Goridge protocol version, RoadRunner binary version, PHP minor version. PSR-7 implementations are interchangeable, so the swap cost of Diactoros → Nyholm is low; the swap cost of an RR major version is not. Treat the binary and the client as a coupled pair in composer.json/image tags.
• Sequencing. Dependency spike (week 1) → runtime ownership decision: who ships the binary, who owns .rr.yaml (week 1–2) → worker bootstrap and config committed to the repo (week 2) → load test against the FPM baseline (week 3) → staging soak with fault injection (week 3–4) → canary → full cutover or abandon. Build the abandon decision into the plan at the load-test gate.

Operational Impact

• Maintenance. Low churn on the package itself — it tracks PSR-7 and Goridge, both slow-moving. The real maintenance burden is the RoadRunner binary: image rebuilds, config drift, version bumps, and the CVE cadence of an embedded Go server. Budget for that; it does not appear in composer.lock. MIT license removes legal friction.
• Support. Community-driven under the RoadRunner/Spiral Scout umbrella; there is commercial support available for RoadRunner proper. With a small public footprint, expect to resolve issues from source and from the RR docs rather than from Stack Overflow. Plan for one or two engineers to become the internal subject-matter experts; do not assume you can hire this skill.
• Scaling. Scale-out is worker-pool replication — horizontally by adding containers or num_workers, not by tuning PHP-FPM pm.max_children. This is mechanically simple on Kubernetes but requires that the application hold no per-request state in memory between requests. Memory is the recurring operational cost: long-lived workers accumulate leaks, so max_jobs/recycle policies and RSS-based restart thresholds must be configured deliberately, not left at defaults.
• Failure modes.
  • Worker crash → RR respawns it; ensure this is alarmed, not silently absorbed, or you will lose crash signal.
  • Hung request → per-request timeout in .rr.yaml; without it, a single stuck worker degrades the pool.
  • Memory leak → OOMKill under a restart policy that masks the underlying leak; treat RSS growth as a bug, not a tuning knob.
  • PSR-7 response malformation → opaque 500s at the Go layer; log the worker side, since the server logs will not explain it.
  • Opcache/static-state staleness → code deploys that don't take effect until workers recycle; wire RR reload into the deploy hook.
  • Binary/client version skew → protocol errors at boot, which are loud and easy to diagnose; pin versions to make them impossible.
• Ramp-up. For PHP developers already writing PSR-7/PSR-15 code: roughly a day to be productive, a sprint to be confident. The mindset shift is the long-lived worker model — developers must internalize that globals, statics, and singletons persist across requests, which is a class of bug that does not exist under FPM. For platform/ops: moderate, driven entirely by owning a Go binary and its supervisor configuration, not by this package. The TPM-facing risk is the ops ramp-up, not the developer ramp-up; staff accordingly.