Laravel Route Statistics Laravel Package

Technical Evaluation

Architecture fit: Laravel-native request instrumentation via middleware or request macro, persistence in a database table, optional time-bucket aggregation. It fits a Laravel monolith or API service that needs lightweight route-level usage telemetry: route popularity, authenticated vs unauthenticated traffic, per-user/team usage, status distribution, and unused-route discovery through route:stats and route:unused. It is not a product analytics platform, APM tool, or dashboard; value depends on an internal reporting layer over the package’s tables.

Integration feasibility: Low implementation complexity for a Laravel team: Composer install, publish migration/config, run migration, then choose global middleware, route middleware, or ad-hoc $request->routeStatistics(). The package supports Laravel 10–13 and PHP 8.2–8.5 on v4.x, with older major versions covering older Laravel/PHP combinations. Queued logging, route context such as team_id, and artisan reporting are available. Main feasibility constraint is operational discipline, not code integration.

Technical risk: Global middleware on high-traffic routes can add DB write load and latency. Logged fields include user_id, ip, route parameters, status, and timestamps, creating privacy/retention obligations. Storing route parameters can capture sensitive values. Selective middleware makes route:unused misleading because unlogged routes appear unused. Route renames or URI changes reduce longitudinal comparability. The package is niche: 238 stars, no dependents, small maintainer footprint, and a dependency on bilfeldt/laravel-request-logger; compatibility releases are proactive, but there is no enterprise SLA or built-in dashboard/export/alerting.

TPM take: Adopt tactically for route usage insight and deprecation/cleanup decisions, not as a strategic analytics foundation. Pilot on a bounded set of route groups, measure DB and latency impact, define retention and PII rules, and budget internal effort for reporting.

Key questions: Which product or operational decisions will this instrumentation inform? Is global logging required for route:unused, or is selective logging acceptable? What traffic volume and DB write capacity exist? Which fields are prohibited or require masking? What retention period satisfies privacy and analytics needs? Will queued logging be used, and are workers monitored? Who owns dashboards, SQL reports, and aggregation/purge schedules? How are multi-tenant and user identifiers modeled? What is the accepted route-naming convention for stable reporting?

Integration Approach

Stack fit: Strong fit for Laravel 10–13 applications on PHP 8.2–8.5 using v4.x. Confirm framework, PHP, database, queue, and middleware configuration before adoption. The package should sit alongside existing Laravel middleware and use the application database; no separate infrastructure is introduced unless queued logging is enabled.

Migration path: Map the application to the compatibility matrix before installing. Laravel 8–9 uses v1.x; Laravel 10 can use v2.x or v4.x; Laravel 11 can use v3.x or v4.x; Laravel 10–13 should target v4.x. Laravel 12 requires v4.2+; Laravel 13 requires v4.3+; PHP 8.5 requires v4.4+. If the platform is older, either pin the last compatible major or upgrade Laravel/PHP first; do not force v4 onto unsupported stacks.

Compatibility checks: Validate route middleware aliases, global middleware ordering, user model relationship config, JSON/parameter handling, migration columns/indexes, and queue worker behavior in staging. Test under realistic traffic because synchronous logging changes request-path DB behavior. Confirm whether the application uses route names consistently; unnamed routes fall back to URIs and will fragment reporting.

Sequencing:

1. Define the decisions and KPIs: top routes, adoption, unused routes, unauthenticated usage, team usage, error-rate context.
2. Inventory routes and classify high-value vs high-volume vs sensitive routes.
3. Install and migrate in staging with production-like data volume.
4. Publish config and choose logging scope: global only if route:unused completeness is required; otherwise route-group middleware.
5. Add context such as team_id, but minimize route parameters and PII.
6. Enable queued logging and aggregation/purge schedules if supported by the config and operational model.
7. Validate records, query performance, and artisan commands against known traffic.
8. Roll out to a small production route group, compare latency/DB impact, then expand.
9. Build a lightweight reporting layer using SQL/BI or internal admin screens; expose route:stats and route:unused to product/ops.
10. Review retention, access controls, and reporting cadence after 30 days.

Rollback: Disable middleware or request macro first; retain the table for audit/history unless policy requires purge. Coordinate migration rollback with data-retention decisions.

Operational Impact

Maintenance: Low code surface and MIT licensing reduce vendor lock-in. Compatibility releases for Laravel 12/13 and PHP 8.4/8.5 indicate active upkeep, but the project is small and maintainer-dependent. Pin the version, monitor releases, and assign an internal owner for upgrades and schema changes.

Support: Community support through GitHub issues, not an SLA. Internal runbooks should cover migration, middleware scope, aggregation/purge jobs, queue failures, and reporting queries. Escalation to the maintainer should not be assumed for production incidents.

Scaling: The main scaling cost is database growth and write throughput. Aggregation reduces row volume, and queued logging can smooth request-path impact, but queue backlog becomes a separate failure mode. High-traffic global logging requires capacity testing, indexing review, and a retention policy. Per-route/per-user/per-status/time-bucket cardinality drives table size; IP and parameter storage increase both privacy risk and storage.

Failure modes: Missing migration or misconfigured middleware causes silent data loss. Synchronous DB writes can fail or slow requests if not handled defensively. Queue workers can lag or drop jobs. Aggregation/purge jobs can fail silently and inflate storage. Selective logging can produce false “unused route” conclusions. Route renames fragment history. Sensitive route parameters or IP addresses can create compliance exposure. User deletion or model changes can affect relationships. Dashboard absence means teams may collect data without acting on it.

Ramp-up: Laravel engineers can integrate in hours; TPM and analysts need SQL/BI skills to turn logs into decisions. Product/ops training should cover interpretation limits, route naming, retention, and privacy rules. A practical rollout is a 1–2 week pilot on selected route groups, followed by a go/no-go review on DB growth, latency, data quality, and at least one concrete decision enabled by the reports.