Router Laravel Package

Product Decisions This Supports

• Build vs. buy for request routing. Routing is commodity infrastructure. Aura.Router (MIT, ~500 stars, active as of Apr 2025) is a candidate to buy into rather than hand-roll — but only in a PSR-7/PSR-15 context, not inside Laravel.
• Framework-lock-in strategy. If the roadmap includes a possible move off Laravel (or a shared core across Laravel and non-Laravel services), this package is a concrete artifact for a "portable HTTP layer" decision. Its route-map-in-code model keeps routing definitions transportable.
• Scoping a greenfield service or microservice. For a standalone PHP service that will never be a Laravel app, this supports a decision to ship a thin PSR-7 app with explicit route maps, per-route middleware, named-route URL generation, and HTTP method override.
• Legacy modernization sequencing. When a monolith is being strangled one endpoint at a time, this supports the decision on whether the new surface area uses an explicit, framework-agnostic router or inherits the host framework's.
• Non-decision / default. Given a low opportunity score (26.12) and zero listed dependents, the honest PM output is often: no decision needed — routing is saturated, and Laravel's built-in router already covers named routes, model binding, middleware groups, signed URLs, rate limiting, and route caching. This package is not a differentiation lever; it is a plumbing choice.

Practical note for the decision record: this is not a Laravel package in any integration sense. It is a framework-agnostic router targeting PSR-7/PSR-15. Adopting it inside a Laravel codebase means deliberately stepping outside Illuminate\Routing conventions, which is a meaningful architectural commitment, not a Composer require.

When to Consider This Package

Adopt-consideration criteria:

• The application is not Laravel — a standalone PSR-7/PSR-15 stack, a service extracted from a framework, or a deliberately framework-neutral core library.
• The team prefers route maps defined in code/config (explicit, greppable, reviewable in diffs) over attribute- or annotation-driven routing.
• You want a small dependency surface with no framework coupling and no license cost.
• You need per-route middleware pipelines, named-route URL generation, HTTP method override, HEAD/OPTIONS handling, and optional route segments — and are comfortable assembling the surrounding stack yourself.
• Portability is a stated architectural goal, so a router that survives a framework swap has real option value.

Look elsewhere when:

• The product is Laravel-first. Use Illuminate\Routing. Re-implementing model binding, middleware groups, route caching, signed URLs, and rate limiting on top of a foreign router is negative ROI.
• Dispatch performance is a hard requirement. Symfony Routing's compiled matcher and FastRoute are the benchmarks to beat; routing is usually a small share of request time, but if it is on the critical path, evaluate them head-to-head.
• Ecosystem gravity matters. Zero listed dependents means thin community validation, scarce hiring signal, few Stack Overflow answers, and a bus-factor risk concentrated in a small set of maintainers. For a long-lived product, that is a real TCO line item.
• You need batteries: OpenAPI/Swagger generation, attribute-based route discovery, route-list tooling, or deep framework integration. Laravel, Symfony, and Spatie's attribute router are the mature answers.
• You cannot own the glue. This package gives you a router, not an application kernel; someone must own PSR-7 implementation choice, middleware dispatcher, and error handling.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed plumbing library for URL routing — not a strategic platform bet. It carries no license or vendor cost and keeps our HTTP layer portable across frameworks. The trade-off is support risk: it has a small maintainer base and little downstream adoption, so we would be largely on our own for troubleshooting. Recommended position: not for our Laravel applications, where the framework's router is already richer and free; a reasonable candidate only if we deliberately build a framework-neutral service or shared core. No budget impact either way.

To engineering: Aura.Router is a clean, mature PSR-7/PSR-15 router — explicit route maps, named routes, per-route middleware, method override, active releases. It is genuinely good at what it does. It is also not a Laravel package: adopting it means opting out of Illuminate\Routing (model binding, middleware groups, route cache, signed URLs, rate limiting) and owning the PSR-7 implementation and middleware dispatch ourselves. If we have a standalone service or a portability mandate, it is worth a spike; if we are building a Laravel feature, this is a distraction. Ask before adding it to any Laravel codebase.