Nova Filterable Cards Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova card extension: a PHP card base class plus a Vue 2 filter control injected into the card header. It reads Nova's dashboard filters query parameter, decodes it, and replays each filter's apply() against the card's metric query so the card's numbers are scoped to the selected criteria. Fit is essentially binary — it matters only if the back office runs Nova and we have a per-card filtering requirement that native Nova filters do not already satisfy. Two structural considerations dominate the decision. First, Nova 3+ introduced native filter-refresh behavior (refreshWhenFiltersChange()), which duplicates most of this package's reason to exist. Second, the 2018-era Vue 2 frontend does not survive Nova 4/5's Vue 3 transition without a rewrite. The TPM posture is therefore to treat this as a validated reference design and scoping input, not a component to depend on.

Integration feasibility. composer require is not a realistic path on a current stack. The package pins php ^7.1, laravel/framework 5.6|5.7, and laravel/nova ^1.0; --ignore-platform-reqs only moves the failure from dependency resolution to a blank card in production. There is also no service-provider asset registration — it is a library of card classes, so cards are registered the usual way in NovaServiceProvider::cards(). The feasible integration is source-level reuse under MIT: read the small, conventionally structured PHP/Vue implementation, extract the filter contract, and reimplement against current Nova card scaffolding. For a Nova-familiar developer that is a one-to-two-day clean-room build. Vendoring is defensible only for a genuinely pinned Nova 1.x/Laravel 5.x application, and even then via a mirrored repository.

Technical risk. Risk here is ownership and obsolescence, not code complexity. The repository is archived: no security response path, no maintenance, no compatibility work inbound, 58 stars, zero dependents, a single maintainer, and one experimental release (August 2018). Negligible field testing means any defect surfaces first in our environment. Any build that references the GitHub URL as a Composer vcs repository is a supply-chain item — deletion breaks builds. The substantive behavioral risk sits in the filter mechanism itself: date-range inclusivity/exclusivity, timezone handling, tenant and policy scoping, and composition with Nova's native filters. That is where a seven-year-old implementation is most likely to be subtly wrong, and where our own contract definition matters more than the reference code.

Key questions.

• Which Nova major are we on today, and is a Nova upgrade funded on the roadmap? If Nova 3+/4+/5 is current or planned, verify native filter-refresh behavior before spending anything.
• What exact requirement is unmet — per-card date range, plan, channel, tenant — versus cross-card filtering, saved views, drill-downs, or export? The latter is BI territory (Metabase, Looker, Redash), not a Nova card.
• Are we prepared to own a permanent internal fork, or would we end up depending on archived upstream? Only the first is defensible.
• Is the upstream repository already referenced anywhere in the build estate as a vcs source?
• What queries back the candidate cards, and are the filtered timestamp columns indexed? Table size and filter predicates determine whether this is self-service or dashboard latency.
• What is the filter contract: dimensions, policy/tenant scoping, composition with native filters, date boundaries, and timezone policy?
• Is Nova itself already licensed and paid for, or does this convenience pull in a second purchase?

Integration Approach

Stack fit. Laravel + Nova only. There is no framework-agnostic API, headless mode, or alternative admin-panel integration. If the organization standardizes on a different admin surface or a BI tool, this is not a candidate; the pattern may still inform requirements.

Migration path. In descending order of preference:

1. Reimplement in-house on current Nova card scaffolding, using this source as the behavioral reference for the filter UI and query wiring. Default choice.
2. Vendor the source into the application or a private path repository, retain the MIT header, rewrite Composer constraints to owned PHP/Laravel/Nova ranges, and rebuild assets on the current pipeline.
3. Fork to a private repository if more than one application needs it.
4. Adopt as-is only for a legacy Nova 1.x application, and then via a mirrored repository rather than the upstream URL.

Compatibility. Treat compatibility as per-Nova-major and verify rather than assume. Nova 1.x is the design target; Nova 2.x may work with constraint edits; Nova 3 requires registration and asset changes; Nova 4/5 requires a Vue 3 rewrite. Each step is engineering work, not a version bump — budget accordingly and do not let a ticket estimate imply otherwise.

Sequencing.

1. Half-day spike (decision gate). Confirm Nova version, inventory existing cards and filters, read the package source, and test whether native Nova filters already satisfy the requirement. If they do, close the gap at near-zero cost and stop here.
2. Decide reimplement vs. vendor. Default to reimplement unless a legacy Nova 1.x install makes the source a drop-in. Record the decision, the rationale, and the owner.
3. Neutralize upstream exposure. If any vcs reference exists, mirror the code into owned VCS and remove the upstream reference before the archived repository disappears.
4. Define and review the filter contract before build: dimensions, tenant/policy scoping, composition with Nova filters, date-range boundaries, timezones.
5. Build and validate in staging against realistic data volumes and date ranges, not a seeded demo dataset.
6. Close out. Retire residual upstream dependency, publish the decision record, and add an entry to the architecture/risk register.

Operational Impact

Maintenance. Adoption converts an external dependency into a permanent internal obligation. Every Nova upgrade, PHP upgrade, and frontend build-tool migration becomes our work, indefinitely, with no upstream to hand it back to. Absolute effort is modest given the small surface area — but it is an indefinite tail, and it competes with roadmap commitments. The archived status means zero compatibility work will ever arrive from the maintainer.

Support. No maintainer, no issue triage, no security advisories, negligible community. Internal escalation ends at whoever forked or reimplemented it. A TPM must name that owner explicitly and budget their time; an unowned fork sitting in the admin surface is a governance gap that will only be discovered during an incident or an upgrade crunch.

Scaling. Card rendering is client-side and scales trivially. The filterable behavior is where it bites: each card typically issues its own aggregate query, and re-querying on every filter change multiplies database load per dashboard view. With several cards over large tables, unindexed COUNT/SUM queries with date predicates will show up as dashboard latency long before application traffic is affected. Before rollout: confirm indexes on filtered timestamp columns, consider caching card results, and cap or debounce filter-triggered refreshes. Treat the dashboard's P95 load time as an acceptance criterion, not an afterthought.

Failure modes.

• Loud: Composer resolution failure on the next PHP/Laravel upgrade.
• Quiet: blank or silently empty card after a Nova upgrade (Vue 2 component under a Vue 3 runtime) — easy to miss in review, damaging in a leadership demo.
• Asset publishing or 404 failures after Nova tooling changes.
• Upstream repository deletion breaking builds that reference it via vcs.
• Date-range boundary and timezone bugs in legacy filter logic, particularly inclusive/exclusive end dates near month and quarter closes.
• Unbounded queries on large tables causing dashboard timeouts.
• Divergence between filter definitions on cards and on resources, producing metrics that disagree with the underlying list views — an credibility problem for the dashboard, not just a bug.

Ramp-up. Low. The codebase is small, conventionally structured, and readable by a mid-level Laravel developer in under a day. The real gate is Nova familiarity — card lifecycle, asset registration, metadata passing — not this package specifically. That low ramp-up cost is itself the argument for reimplementation: the effort to understand the package is most of the effort to replace it, and replacement removes the archived-upstream risk entirely. Budget the saved time into defining the filter contract and validating query performance, which is where the actual product and operational value sits.