Http Laravel Package

Technical Evaluation

Architecture fit. psx/http is a contracts-only package: it defines PHP interfaces for HTTP messages, middleware, and clients, and ships essentially no runtime behavior. That makes it architecturally neutral but not architecturally aligned with Laravel. Laravel's HTTP story is already opinionated and layered: Symfony\HttpFoundation for the inbound request/response lifecycle, Illuminate\Http\Client (Guzzle-backed) for outbound calls, symfony/psr-http-message-bridge when PSR-7 interoperability is needed, and PSR-15 packages (middlewares/*, Laminas Stratigility) when a formal middleware pipeline is required. psx/http's interfaces are PSX-specific, not PSR-7/15/18. Adopting them means standing up a parallel HTTP abstraction alongside Laravel's rather than plugging into it.

Integration feasibility. Technically possible, practically awkward. Because it is interface-only, there is no service provider, no facade, no config, and no published Laravel adapter. Any integration requires us to author bidirectional adapters: wrapping a PSR-18/Guzzle client to satisfy the psx client interface, and translating Laravel middleware into psx middleware. There is no community prior art to borrow from — zero dependents means no reference implementations to validate our adapter design against.

Technical risk. Split verdict. Implementation risk is low: no behavior, no meaningful transitive dependency surface, Apache-2.0 (permissive, vendor-friendly), so a pinned copy cannot break the build through dependency resolution. Strategic risk is high: 3 stars, 0 dependents, single-maintainer project (the package exists to serve the PSX framework's own needs), and interfaces that will evolve on the PSX framework's release cadence rather than ours. Abandonment is the dominant failure mode, and it is not mitigable by us.

Key questions.

• What is the actual business driver for psx/http specifically, versus PSR-7/15/18 or Laravel's native abstractions?
• Are we integrating with an existing PSX-based system, or considering this greenfield? (Only the former plausibly justifies it.)
• Which concrete implementation will satisfy these interfaces in our stack, and who owns it?
• What is the maintainer's stated support/versioning policy, and what is the PHP version floor in composer.json?
• If the package is archived tomorrow, what is our exit cost given we will have already written adapters against these signatures?

Integration Approach

Stack fit. Poor. psx/http sits orthogonal to Laravel's request lifecycle rather than inside it. If the underlying need is "a clean middleware abstraction," PSR-15 is the correct target — it is standard, has multiple maintained implementations, and interoperates with Laravel via existing bridges. If the need is "a swappable HTTP client contract," PSR-18 is the correct target. Choosing psx/http buys us a bespoke vocabulary with none of the ecosystem leverage.

Migration path. Do not attempt to route the Laravel HTTP kernel through psx/http. If we proceed, confine it to a single bounded context — for example, an outbound-client contract inside one domain module — and implement it as an anti-corruption layer: our domain depends on psx interfaces, and thin adapters map to Guzzle/PSR-18 underneath. That keeps the blast radius to one module if we later swap the contract out for PSR-18.

Compatibility. The interfaces-only nature means no dependency conflicts with Laravel or Symfony, and no framework version constraints — the one genuine advantage. The real compatibility question is semantic, not syntactic: psx implementations carry behavioral assumptions (stream handling, header normalization, middleware ordering) that Laravel adapters will not automatically honor. These must be discovered through contract tests, not documentation.

Sequencing.

1. Re-derive the requirement; explicitly evaluate PSR-7/15/18 and Laravel-native options as the baseline.
2. If psx/http still wins, write a one-page ADR recording why, since this decision will be questioned repeatedly.
3. Pin an exact version and vendor the interface definitions (Apache-2.0 permits this) to insulate against repo deletion.
4. Build the adapter layer first, with contract tests covering message immutability, middleware ordering, and client error mapping.
5. Document the mapping table (psx concept → Laravel/PSR concept) before any feature work.
6. Re-evaluate at the next major Laravel upgrade; treat the package as a candidate for replacement, not a fixture.

Operational Impact

Maintenance. The code surface we own is small, but the maintenance obligation we inherit is adapter ownership. Every psx interface change — even a signature tweak — becomes our work, and we will get no advance notice beyond a commit in a low-traffic repository. Pin versions, vendor the contracts, and budget a recurring line item for adapter upkeep rather than assuming it is a one-time integration.

Support. Effectively zero external support: 3 stars and 0 dependents means no Stack Overflow corpus, no blog posts, no Laravel community familiarity, and no vendor SLA. Internal documentation is not optional — it is the entire support surface. Onboarding a contractor or new hire to this abstraction will require a written guide that we author and maintain.

Scaling. No runtime scaling concern; interfaces are a compile-time construct and impose no overhead. The scaling problem is organizational: every engineer who touches this module must learn a non-standard HTTP vocabulary on top of Laravel's and PSR's. That cost compounds with team size in a way that a PSR-based choice would not.

Failure modes.

• Abandonment: repository archived or maintainer steps away; interfaces freeze at an arbitrary point. Mitigated by vendoring, not eliminated.
• Interface drift: PSX refactors its contracts to suit the framework; our adapters break on a minor bump.
• Semantic mismatch: psx implementations assume behavior our Laravel adapters do not provide — the most expensive failure because it surfaces in production, not at build time.
• Cognitive collision: two coexisting HTTP abstractions cause engineers to reach for the wrong one; review burden rises and defect rate with it.
• False confidence from low risk score: the package's minimal code is read as "safe," masking that the risk is ecosystem and longevity, not implementation.

Ramp-up. High relative to delivered value. Engineers with PSR-7/15/18 experience get zero skill transfer into psx terminology. Realistically allow one to two days per engineer to become productive, plus an ongoing tax on code review and debugging. Contrast this with PSR-15, where ramp-up is near zero for anyone who has worked in the broader PHP ecosystem — which is the argument, as TPM, for redirecting the effort.

Recommendation. Score 0.075 with 3 stars and 0 dependents is consistent with what the code inspection shows: a competent, low-risk-in-isolation contracts package with no ecosystem and no Laravel path. Absent a specific, documented mandate to interoperate with PSX, I would not adopt it. Target PSR-18 for client contracts and PSR-15 for middleware; revisit psx/http only if a PSX integration requirement materializes, and then scope it to a single anti-corruption layer.