Middleman Laravel Package

Product Decisions This Supports

• Build vs. buy for the middleware pipeline itself. This is a ~300-line dispatcher doing one thing: take a PSR-7 request, run it through an ordered list of PSR-15 middleware, return a PSR-7 response. If a decision is on the table between writing our own dispatch loop and pulling in a dependency, this package represents the "small, single-purpose, no-framework" end of the spectrum — worth pricing against writing and maintaining the equivalent in-house.
• Framework-agnostic architecture bets. Because it is PSR-15/PSR-7 only, adopting it is an implicit decision that the HTTP layer should be portable across frameworks (Slim, Mezzio, Laravel via a bridge, custom kernels). That is a strategic call about lock-in, not just a library choice, and it should be made at the architecture level rather than per-feature.
• Packaging a reusable HTTP kernel. If the roadmap includes shipping an SDK, an internal shared service template, or an embeddable API layer that customers or other teams mount into their own app, a standards-based dispatcher is the low-friction integration surface. This package's container-driven middleware resolution (resolve middleware by class name through PSR-11, lazily) supports exactly that "drop our stack into your app" use case.
• Roadmap scoping for the HTTP layer. Committing to PSR-15 means future middleware (auth, CORS, rate limiting, request IDs, tracing) are written to an interface rather than to Laravel's Closure-based pipeline. That affects hiring, code review criteria, and how third-party middleware can be reused. It also constrains us: we would not get Laravel's handle/terminate lifecycle, route middleware aliases, or $next($request) ergonomics for free.
• Evaluating consolidation options. With 0 dependents and a last release in July 2021, this is a candidate for the "adopt with a fork clause" bucket rather than a strategic dependency. The decision it informs is whether the pipeline is commodity code we should own outright.

When to Consider This Package

Adopt it when all of the following hold:

• The application (or the package we are publishing) is already PSR-7/PSR-15 native — Slim, Mezzio/Laminas, a custom kernel, or a Laravel app that has deliberately added a PSR-7 bridge.
• We want a minimal dispatcher, not a framework: no routing, no DI container, no error handler, no emitter bundled in. We supply the container (PSR-11) and the middleware; it supplies the ordering and the loop.
• We want lazy, container-resolved middleware so expensive middleware is only instantiated when it actually runs, and so middleware can declare dependencies in its constructor.
• The middleware set is small and stable — a handful of cross-cutting concerns rather than dozens of route-scoped layers.
• We are comfortable vendoring or forking a small, quiet library. The code is small enough to audit and own; the release cadence is not a signal of active maintenance.

Look elsewhere when:

• The stack is stock Laravel. Laravel's Illuminate\Pipeline and HTTP kernel are Closure-based, not PSR-15. Bridging means adding symfony/psr-http-message-bridge plus a PSR-7 implementation, converting requests and responses at the boundary, and losing terminate(), route middleware parameters, and middleware groups. That is real complexity for a dispatcher we already have.
• We need more than dispatch. No routing, no PSR-15 RequestHandler bootstrapping, no error middleware, no response emitting — relay/relay, middlewares/runner, laminas/laminas-stratigility, or a micro-framework gives a fuller story.
• Dependency health is a gate. 92 stars, zero dependents, one release in 2021, and a low opportunity score mean no community backstop. If our policy requires active maintenance, a security response process, or a maintainer we can escalate to, this fails the gate.
• We need PHP 8.x guarantees. Verify compatibility explicitly rather than assuming; the last tagged release predates wide PHP 8 adoption.

How to Pitch It (Stakeholders)

To executives: This is a tiny, standards-based piece of plumbing — not a platform commitment. It lets us order and run HTTP middleware against the industry-standard PSR-15 interface instead of a framework-specific one, which means our HTTP layer can move between frameworks and can be handed to partners without asking them to adopt Laravel. It is roughly 300 lines of dependency-free code, so the downside is bounded: worst case we fork it, which is cheaper than the meetings required to evaluate a larger framework. Recommendation: not a strategic dependency — treat it as commodity code we are willing to own. Low stars, zero dependents, and a 2021 release date mean we should not assume the community maintains it for us.

To engineering: Use it if we are already PSR-7/PSR-15 and want a dispatcher that does exactly one thing: resolve middleware from the PSR-11 container on demand and run the chain. It gives us lazy instantiation and constructor injection for middleware with no framework attached. Do not reach for it inside a stock Laravel service — the PSR bridge cost exceeds the benefit, and Laravel's pipeline already covers us. If we adopt, pin the version, vendor the source, and add a short internal note on the fork path and PHP 8 compatibility. Budget half a day to read the whole library; it is small enough that "we understand all of it" is a realistic claim, which is the main reason to prefer it over a heavier alternative.