Routing Laravel Package

Product Decisions This Supports

• Build vs Buy for non-Laravel routing: If we have standalone PHP services, CLI tools, or legacy Nette components needing two-way URL conversion, this replaces custom routing code and reduces maintenance.
• Hybrid architecture roadmap: Supports a framework-agnostic routing contract across Laravel and non-Laravel services without forcing a full framework migration.
• URL generation consistency: Useful when product needs deterministic URL construction (SEO, emails, shared links, API versioning) independent of request context; the same route definitions drive matching and constructUrl().
• Not a driver for core Laravel decisions: Middleware, model binding, rate limiting, signed URLs, and controller dispatch stay Laravel-native. Treat this as infrastructure for edge cases, not a replacement.

When to Consider This Package

• Adopt when: You maintain PHP 8.1+ services outside Laravel (or a legacy Nette app) that need two-way URL routing; you want domain/path scoping, regex constraints, defaults, and RFC 3986-compliant encoding; you need a small standalone router without Symfony/Laravel coupling.
• Consider for Laravel only as a tactical bridge: e.g., migrating legacy Nette routes behind a Laravel gateway, or sharing route definitions with a non-Laravel microservice. Do not use it as the primary router in a Laravel app.
• Look elsewhere when: The application is a standard Laravel app — Laravel’s router already integrates with the HTTP kernel, middleware, controllers, model binding, and URL generation. Avoid if you need PHP <8.1, require framework-level auth/CSRF/throttling inside routing, or depend on a large ecosystem/dependent count (this package has 0 dependents and 261 stars; niche adoption).

How to Pitch It (Stakeholders)

Executives: “This is not a replacement for Laravel’s routing. It is a small, maintained PHP routing library that can reduce custom code in ancillary services and legacy integrations. The business case is narrow: lower maintenance in non-Laravel components and safer migrations, not faster delivery of core Laravel features. Approve only if we have a concrete standalone service or legacy Nette surface; otherwise, standardize on Laravel’s native router.”

Engineering: “nette/routing provides clean two-way URL conversion (match() / constructUrl()) with path/domain scoping, constraints, defaults, and RFC-compliant encoding. It is framework-agnostic and static-analysis-clean. In Laravel, it is redundant and integration is awkward because Laravel’s router is tied to the HTTP kernel and middleware. Use it only for isolated services, CLI URL generation, or hybrid/legacy bridging; keep Laravel routing native for web and API features.”