Http Server Laravel Package

Product Decisions This Supports

• Build vs. buy for the HTTP transport layer. This package is the "buy" side of a narrow decision: it replaces the hand-rolled socket-accept → parse → dispatch → serialize loop with a small dependency, letting us own routing, middleware, and business logic instead. As with the Innmind ecosystem generally, expect PSR-7 request/response messages and a server as a plain callable — no container, no kernel, no framework conventions to learn.
• "Framework or not" spikes for new PHP services. Useful as a concrete reference point when evaluating whether a new internal service needs Laravel/Symfony at all, or just a long-running worker with an HTTP facade. It is cheap to read end-to-end, which makes it a good artifact for a 1–2 day architecture spike.
• Adding an HTTP surface to worker-shaped processes. The main legitimate product use case: a queue consumer, cron-style daemon, or CLI tool that needs a small /health, /metrics, or admin endpoint without standing up a full web app alongside it.
• Long-running runtime roadmap. If we are moving off PHP-FPM toward persistent workers (Octane, RoadRunner, Swoole, FrankenPHP), this package is a data point on what "own the loop" costs versus what the managed runtimes abstract away.
• Testability as a design constraint. A callable server (Request in, Response out) means handlers are unit-testable without booting a kernel or faking the SAPI. That is a real ergonomic win worth citing even if we don't adopt the package.
• Do not use this to justify a production dependency. With 0 stars, 0 dependents, and a single-maintainer lineage, the composite score (~15.9) reflects an absence of adoption evidence. The higher opportunity sub-score (~35) says the problem space is attractive — not that this library has won it.

When to Consider This Package

Adopt (or, more realistically, pilot) only when all of these hold:

• The team is already fluent in immutable PSR-7 messages and explicit composition — no DI container, no annotations, no magic. This style is productive if you like it and hostile if you don't.
• The surface area is small and internal: low QPS, a handful of routes, a blast radius you can reason about on one screen.
• You genuinely want to own routing and middleware and are prepared to write the pieces a framework would have given you.
• You can absorb the maintenance risk: one maintainer, no community Q&A, no downstream projects to learn from, and release metadata that should be verified before you pin a version (the listed last-release date is forward-dated relative to today, which is a data-quality flag, not a feature).
• Someone on the team will actually read the source. There is no meaningful ecosystem of tutorials, blog posts, or Stack Overflow answers to fall back on.

Look elsewhere when:

• You need production confidence signals. Zero dependents means zero public evidence that anyone runs this in anger. No CVEs, no advisories, no track record of security responsiveness.
• You are already on Laravel. Laravel Octane over the existing kernel is the lower-risk path to the same outcome; adopting a parallel HTTP stack means two request lifecycles to reason about and a debugging story that doesn't match anything else in the codebase.
• You need throughput guarantees. Swoole, RoadRunner, and FrankenPHP are battle-tested on connection handling, backpressure, and graceful reload. This package is not competing there and shouldn't be evaluated as if it were.
• You need conventions, not seams. Auth, sessions, validation, ORM, admin UI, queues — everything a framework gives you is now your problem, and that cost is invisible in a spike and very visible in month three.
• You need a vendor relationship or SLA. MIT with one maintainer is fine for a spike and thin for a revenue path.

How to Pitch It (Stakeholders)

For executives: This is a small, permissively licensed PHP library that handles the HTTP plumbing for long-running PHP services. The cost to try it is a day or two; the cost to depend on it is meaningful, because it has no visible production users and effectively one maintainer. Recommendation: fund a time-boxed spike to sharpen our build-vs-buy position on persistent PHP runtimes, and keep the production path on Octane or RoadRunner unless the spike produces something surprising.

For engineering: Treat it as a seam, not a framework. PSR-7 in, response out, server as a callable — which makes handlers trivially testable and removes the kernel from the equation. In exchange, we own routing, middleware, error handling, graceful shutdown, and the transport edge cases. The pitch is legibility and testability, not performance or features.

The honest one-liner: interesting architecture, unproven dependency. Borrow the ideas now; borrow the code only if the spike proves the ideas and we accept single-maintainer risk in writing.