Middleware Dispatcher Laravel Package

Product Decisions This Supports

• Standards-alignment vs. framework-native debate. This package is a concrete, BSD-licensed PSR-15 dispatcher. It lets you evaluate whether your middleware layer should be tied to a framework's HTTP kernel (Laravel's Pipeline/Kernel) or written against the PSR-15 interface. That is a real architecture decision, not a library choice.
• Cross-framework middleware reuse. If your organization runs Laravel alongside other PSR-15 stacks (Slim, Mezzio, Yii3, custom runtimes, RoadRunner/Swoole workers), a PSR-15 dispatcher is the seam that makes middleware portable. Adopting it enables "write the middleware once, run it in three services" as a roadmap item with a measurable payoff.
• Build vs. buy for a pipeline. A dispatcher is a small, well-understood piece of code. This package is the "buy/borrow" option against 200–400 lines of in-house pipeline code. The decision is less about features than about maintenance ownership and standards conformance.
• Vendor and ecosystem risk assessment. At ~17 stars and a 0.39 opportunity score, this is a low-mindshare dependency tied to one framework community. It is a useful datapoint for a dependency-approval or "single-maintainer package" policy review — a decision your team will face repeatedly, not just here.
• Migration and modernization planning. Relevant if you are moving a service toward Yii3 or toward a framework-agnostic HTTP layer, or extracting middleware out of a legacy monolith into a shared edge pipeline (auth, request IDs, rate limiting, tenant resolution).
• Not a Laravel feature decision. Be explicit: this is a Yii-ecosystem package that happens to be PSR-15 compliant. It does not solve a Laravel problem Laravel has not already solved. Do not let it onto a Laravel roadmap as a capability unlock.

When to Consider This Package

Consider it when:

• Your architecture already standardizes on PSR-15 as the middleware contract, and you need a dispatcher that is deliberately thin, framework-neutral, and easy to reason about.
• You are building or maintaining shared middleware libraries consumed by more than one runtime, and you want them to not import Laravel's Illuminate\Pipeline.
• You are in or moving toward the Yii3 ecosystem, where this is a first-party-style component with a coherent sibling set (PSR-7 factories, DI, router).
• You want a reference implementation to validate your own pipeline semantics (ordering, short-circuiting, error handling) before writing or reviewing internal code.
• Your team is comfortable vendoring or forking a small dependency and owning it if upstream stalls.

Look elsewhere when:

• The application is Laravel-native. Laravel's HTTP kernel, middleware groups, priority ordering, terminable middleware, and route-level middleware are integrated with the container, routing, and testing helpers. Swapping in a raw PSR-15 dispatcher means bypassing that integration and hand-wiring what you already get for free. The cost is real; the benefit is usually zero.
• You need SLA, security response commitments, or enterprise support. A 17-star, single-community package will not provide them, and its release cadence is not a substitute for a support contract.
• Your middleware pipeline is on a critical request path with hard latency budgets and you need benchmarked, well-characterized performance — the community evidence base here is thin.
• You want batteries-included behavior: DI auto-wiring, attribute-based middleware, route-scoped pipelines, observability hooks. This is a dispatcher, not a framework.
• Your dependency policy flags low-adoption packages. Expect this to trip it.

How to Pitch It (Stakeholders)

For executives: This is not a product feature; it is a small, permissively licensed (BSD-3-Clause) plumbing library that standardizes how HTTP middleware is composed. The strategic value is interoperability — it would let us write request-handling logic once and run it across different PHP frameworks and runtimes, rather than duplicating it per framework. The risk is concentrated: it is a young, low-adoption package (roughly 17 stars) maintained by a single community, with no commercial support. My recommendation is not to adopt it as a production dependency for our Laravel services, where the framework already provides an equivalent and better-integrated mechanism. It is worth a short evaluation spike only if we commit to a cross-framework middleware strategy, in which case we should treat it as code we may need to own.

For engineering: PSR-15 is the right contract, and this is a clean, minimal implementation of it. In a Laravel codebase, adopting it means stepping outside the HTTP kernel — you lose middleware groups, priority ordering, terminable middleware, and the testing ergonomics that come with the framework. Only do that if portability across PSR-15 runtimes is an explicit requirement. If it is, pin the version, review the source (it is small enough to read end-to-end in an afternoon), and plan for the possibility of vendoring or forking. Do not build product logic that depends on its specific behaviors without tests that lock those behaviors down. And if the real goal is "our middleware should be reusable," the cheaper move is often to depend on the PSR-15 interfaces and keep our own dispatcher, rather than take on this package's maintenance trajectory.