Nova Filterable Metrics Laravel Package

Technical Evaluation

Architecture fit. This package is a narrow adapter between two extension points Nova already exposes — Nova filters and Nova metric cards — not a new subsystem. It adds a fluent ->filters() call to Trend, Value, and Partition cards so filters already registered on a dashboard can be applied to those cards and rendered as native dropdowns and date pickers. The fit test is binary and cheap: if the estate runs Nova and the internal reporting need is "let ops, finance, or support slice an existing metric themselves," this closes a real gap at near-zero build cost. If there is no Nova dependency, or metrics live in a separate BI tool, there is no architectural relevance and the evaluation ends there.

The genuine architectural value is consistency. Today a resource table and a metric card on the same dashboard can show different numbers for the same apparent scope. Unifying both behind one filter model is a trust fix, not just a UX nicety — it removes the recurring "why don't these match?" conversation.

Integration feasibility. High. Installation is Composer plus chaining ->filters() on a card; there is no service provider registration, asset publishing, config file, or schema change. A realistic validation is a branch, one card wired to one existing filter, and a smoke test against a known query. Effort is measured in hours, not sprints — which is precisely why the lifecycle risk below dominates the decision rather than integration cost.

Technical risk. The dominant risk is not technical integration — it is lifecycle. The repository is archived, last released 2023-03-31 (v1.3.0, which added Nova 4 support), with 24 stars and zero dependents. That reframes the decision from "adopt a dependency" to "adopt and steward a small piece of code," and the TPM should price it that way:

• No forward compatibility. Nova 5, Laravel 11/12, and future PHP constraints will not be patched upstream. The Composer constraint becomes a silent blocker on the admin-stack upgrade path — discovered, typically, mid-migration.
• No security or bug triage. MIT permits a fork, which is the realistic mitigation, but a fork is an indefinite internal maintenance line even if that line is thin.
• No community backstop. Zero dependents means no third-party test coverage and nobody else to notice a break.
• Nova coupling and licensing. It inherits Nova's release cadence and per-seat licensing. Confirm Nova license coverage in CI and staging regardless of this package.
• Bounded blast radius. It touches internal admin/reporting UI only — no customer-facing surface, no write paths, no external contracts — which caps the severity of most failure modes.

Key questions.

• Is archived status a hard exclusion in our dependency governance, or is a fork/vendor path acceptable — and who is the named owner?
• Do we have Trend/Value/Partition metrics that need filter parity today, or is this solving a hypothetical?
• Does the current Composer constraint already block our next Nova/PHP/Laravel upgrade?
• Do filters translate correctly into the metric's aggregation, or will they silently mis-filter and produce plausible-but-wrong numbers?
• What is the in-house effort to reimplement ->filters() on Nova's metric API — days or weeks? That is the real comparison, not "$0 vs. free."
• Has Nova since shipped native metric filtering? If so, the decision collapses to zero and we close the ticket.

Integration Approach

Stack fit. Best fit is a Laravel app on Nova 4, Laravel 9/10-era, PHP 8.0+, where internal dashboards already use Nova metric cards and the team has invested in Nova filters as the standard filtering UX. The value proposition is reuse: the entire benefit comes from attaching filters the team already maintains. With no filters in place there is nothing to attach it to. Poor fit for non-Nova apps, customer-facing analytics, or teams standardizing on a separate BI layer.

Migration path. Treat as a small, reversible adoption with an explicit exit:

1. Inventory existing Nova metrics and filters; confirm the target cards are Trend/Value/Partition.
2. Fork under the org (MIT permits) and pin to a tagged commit or the fork — never consume dev-main from an archived upstream.
3. Wire one card to one filter in a branch; verify rendering and metric output against a known query.
4. Validate a non-trivial date filter and one multi-filter card.
5. Merge through normal review, keeping the pin as the rollback.

Compatibility. Diff the fork's composer.json constraints against our current Nova major, PHP, and Laravel versions, plus every other Nova package in the graph. Because upstream is archived, pin exactly and record the pin in the dependency register with a review date. The last release targeted Nova 4; Nova 4.x minor changes can alter filter and card APIs without notice, so verify behavior on our specific version rather than trusting the README. Before any of this, confirm Nova doesn't already do this natively — if it does, the decision is zero-cost and this evaluation is moot.

Sequencing. Keep this off the critical path for platform upgrades. Land it before a Nova major upgrade, so it is one known, pinned, tested dependency, rather than discovering it during one. If a Nova 5 migration is forecast, fold the fork-or-replace decision into that upgrade epic rather than leaving it as a separate backlog item that surfaces as a blocker.

Operational Impact

Maintenance. Low effort but non-zero and indefinite, because there is no upstream. That is the core TPM framing: the cost is not installation, it is standing ownership. Budget a light annual review of the fork against Nova/Laravel/PHP releases and its Composer constraints, and require a named owner. An unowned fork rots silently and resurfaces as a blocked upgrade mid-migration — worse than having no filtering at all.

Support. No vendor support exists. Internal burden is small because the surface is narrow and the users are internal staff. A short runbook suffices: what broke, where the fork lives, how filters map to metric queries, how to roll back the pin. The real support risk is misleading numbers — a filter that applies incorrectly to an aggregate produces a believable but wrong chart, which erodes dashboard trust faster than a visible error ever does.

Scaling. Effectively a non-issue at runtime. Nova metrics ride admin traffic; there are no public routes, jobs, or queues. Watch only for expensive filter-generated aggregate queries on high-cardinality tables — a user clicking through filters can trigger repeated heavy scans. That is query design the team controls, not a package scaling ceiling.

Failure modes.

• Silent miscalculation — filter applied but aggregation not correctly constrained. Highest-severity mode; gets the most QA attention.
• Upgrade blockage — pinned constraint blocks a Nova/Laravel/PHP bump, discovered mid-migration.
• Abandonment drift — a Nova minor release breaks rendering (empty dropdown, card error) with no fix path except the fork.
• Filter incompatibility — a filter built for resource query building doesn't translate to a metric aggregation, yielding a no-op or error.
• Orphaned fork — owner leaves, no notes, code becomes unexplained surface area.
• UI inconsistency after a Nova upgrade — filter controls render differently or stop appearing as Nova's card frontend evolves.

Ramp-up. Roughly half a day for a Nova-familiar developer to install, wire one card, and validate a filter; add a day if the team is also forking and documenting ownership. The TPM should frame adoption as "a small internal utility we now own," not "a dependency we took on," and gate it on a named owner plus a one-line decision record stating when the fork is retired in favor of in-house code or a Nova-native capability. The leverage is real but narrow: this is the cheapest way to test whether self-serve filtering actually drives dashboard usage before funding a BI purchase or a custom reporting service. It is worth a polish-sprint slot, not a roadmap headline, and never something external or contractual reporting depends on.