Laravel Nova Metrics Polling Laravel Package

Technical Evaluation

Architecture fit. The package is a thin presentation-layer add-on for Laravel Nova: it adds automatic polling/refresh behavior to Nova metric cards (value, trend, partition). It touches no domain logic, no persistence, and no public API of the host application. Structurally that is a good fit — the blast radius is limited to the Nova dashboard surface, and adoption can be opt-in per metric card rather than global.

Integration feasibility. Integration is standard Laravel package ergonomics: composer require, optional config publish, and per-metric opt-in (trait/attribute or a polling()-style call on the metric class). The real constraint is not Laravel — it is Nova. Nova is a paid, closed-source dependency with its own release cadence and its own Vue/asset toolchain, so the effective compatibility matrix is PHP × Laravel × Nova × Node build toolchain, and only one of those four is addressed by this release.

Technical risk. Low, on the evidence available. The 1.0.4 → 1.0.5 delta is described as a single change — Laravel 13 support — which for a package of this shape almost certainly means a widened illuminate/* / laravel/framework constraint in composer.json plus a CI matrix entry. That is a constraint-only change: no runtime API changes, no migration, no config schema change, no asset rebuild implied. Semver is respected (patch bump for a compatibility widening).

The residual risks are:

• Nova-side compatibility is unaddressed. For a Nova card package, the Laravel version is the weaker half of the compatibility question. Nova's card component contract and front-end build are the more likely breakage point, and the release notes say nothing about it.
• Constraint widening can silently move the floor. A widened Laravel constraint sometimes drops older Laravel/PHP support in the same edit. This needs verification, not assumption.
• "Laravel 13 support" may mean pre-release support. If Laravel 13 is not yet GA at the time this shipped, the constraint may resolve to a dev/@beta stability flag, which is not acceptable for a production pin.

Key questions.

1. What is the exact composer.json diff — is this purely additive, or did the minimum PHP/Laravel/Nova floor move?
2. Which Nova major version(s) does 1.0.5 declare, and was the Nova constraint touched at all?
3. Is Laravel 13 GA, and is the constraint stable-flagged or dev?
4. Is there CI coverage for the Laravel 13 leg, or is the constraint merely declared?
5. Does the package's own front-end asset build still work against the current Nova asset pipeline?
6. What is the licence, and is the package forkable if the maintainer stops? (Single-maintainer project.)

Integration Approach

Stack fit. Targets Laravel applications running Nova with metric-heavy dashboards. It is a convenience/UX package, not infrastructure — it should be classified as a low-criticality dependency and never allowed to block a framework upgrade.

Migration path. From 1.0.4 to 1.0.5 the migration is a composer update fidum/laravel-nova-metrics-polling and nothing else. No code edits, no config changes, no data migration, no asset republish. Teams not on Laravel 13 gain no functional benefit from this release; it is a maintenance pickup only, and there is no reason to rush it beyond staying current.

Compatibility. Validate with composer why-not fidum/laravel-nova-metrics-polling 1.0.5 and a dry-run update against the real application, not a scratch project — the Nova constraint is the one most likely to conflict. Confirm the resolved PHP floor against the oldest runtime still in the fleet.

Sequencing.

1. Diff composer.json between 1.0.4 and 1.0.5 tags; confirm additive-only and record the declared minimums.
2. Dry-run the update in a branch against a representative app; inspect the full resolution, especially Nova.
3. Run the existing test suite plus a dashboard smoke test on staging: every polling metric renders, intervals are honored, no console errors.
4. Observe one full business cycle of staging traffic (see scaling below) before promoting.
5. Pin the exact version in composer.lock, promote, and note the Nova version paired with it in the dependency register.

If the team is not yet on Laravel 13, this is a low-urgency "keep current" update — schedule it with the next routine dependency sweep rather than as a standalone change.

Operational Impact

Maintenance. Very low day-to-day. The package is small, stable, and its churn is driven by upstream framework releases rather than by its own feature roadmap — this release is a textbook example (one PR, framework support only). The genuine maintenance concern is bus factor: this is a single-maintainer community package with no commercial backing. The correct mitigation is not process but contingency: confirm the licence permits forking, and confirm the integration is shallow enough that a fork or a hand-rolled replacement is a days-not-months exercise. It is.

Support. GitHub issues only, best-effort, no SLA. Acceptable because the package is non-critical and the failure mode is degraded dashboard UX, not application downtime. Do not let it become load-bearing for anything user-facing outside Nova.

Scaling. This is the operational risk that actually matters, and it is independent of the version bump. Polling converts a passive dashboard into a repeating query generator. Load scales as (concurrent dashboard viewers) × (polling cards per view) ÷ (polling interval). Nova metric cards frequently sit on top of expensive aggregate queries against transactional tables. A dashboard left open on a wall display or a dozen tabs is a steady, non-decaying background load that will not appear in request-rate dashboards unless it is looked for. Set intervals conservatively (minutes, not seconds) for anything non-trivial, and cap the number of polling cards per dashboard.

Failure modes.

• Database load amplification — the headline risk; manifests as slow aggregate queries and elevated DB CPU with no matching application traffic spike.
• Silent degradation on Nova upgrade — a Nova front-end change breaks the card component; the metric renders blank or static with no server-side error. Nothing alerts on this, so it is caught only by a human looking at the dashboard.
• Long-lived tab leakage — browsers left open indefinitely accumulate polling timers; interval drift and duplicate in-flight requests are common in this class of package.
• Dependency-floor drift — a future constraint widening quietly raises the minimum PHP/Laravel and blocks a security patch on an older app.
• Abandonment — no upstream fix for a future Nova/Laravel break; requires fork or removal.

Ramp-up. Low. A mid-level Laravel developer can integrate and tune this in an afternoon; the learning curve is Nova metric internals, not this package. Budget additional time for whoever owns database performance to size polling intervals against real query cost — that is the part that gets skipped and the part that causes incidents.