Nova Global Filter Laravel Package

Technical Evaluation

Architecture fit

• Solves a real, narrow gap in Laravel Nova: filters defined on a Resource (filters() → Laravel\Nova\Filters\Filter) apply to the resource index request only. Metrics (Value, Trend, Partition) and custom cards calculate in isolated requests and have no native awareness of that filter state. The package claims to bridge that gap.
• Fit is conditional on already running Nova (paid license) with dashboards or cards that are semantically paired with a filtered resource. Outside that shape — plain Laravel, non-Nova admin panels, or dashboards that don't mirror resource views — it is inert.
• Surface area appears small (a filter broadcaster + card-side resolver), which is good for reviewability but also means the value proposition rests entirely on one integration point behaving correctly across Nova versions.

Integration feasibility

• Low mechanical friction: Composer install, service-provider auto-discovery, MIT, no obvious schema changes. A single developer can wire a proof-of-concept in a day.
• Low evidentiary friction: 0 stars, 0 dependents, no reference implementations, and the scoring signals (0.03 / opportunity 33) are small-sample noise rather than validation. There is no public evidence that anyone besides the author has run this against a production Nova instance.
• Realistic onboarding cost is not "install and go" — it is a 1–3 day spike plus a read of the source to confirm it does what the description says.

Technical risk — HIGH

• Bus factor 1. Single maintainer, no co-maintainers, no visible CI/test story to lean on.
• Undocumented upstream contract. Nova is closed-source; the filter request payload (base64-encoded JSON keyed by filter class) is an internal format. Any package that parses or transports it is coupled to Nova internals and can break on a minor Nova release without a deprecation path.
• Serialization hazards. Filters may return closures from apply() or depend on request/user context. Any transport that assumes scalar values will silently mis-apply those filters.
• Separate-request state problem. Cards compute during their own AJAX request, after the resource index request is gone. State must be persisted somewhere (session, cache, signed query param, card meta). That is where correctness and cross-user leakage live — and Nova filters are frequently used to encode authorization scope ("my team only"), so a bug here is a data-exposure incident, not a cosmetic defect.
• Silent-wrong-number class of failure. The worst outcome isn't an exception; it's a card quietly showing unfiltered totals that an exec quotes in a meeting.

Key questions to resolve before any commitment

1. Which Nova versions (4.x vs 5.x) and PHP/Laravel versions are actually supported, and is that asserted in tests or just prose?
2. How is filter state transported — query param, session, cache, or published into card meta? Is it keyed per user and per resource?
3. Are filters whose apply() returns a closure or reads $request->user() handled correctly?
4. What is the invalidation story when a user changes filters, navigates away, or switches tenants?
5. Does it interoperate with dashboard-level filters, or only resource-index filters?
6. Multiple resources on one dashboard — whose filter state wins?
7. Maintainer responsiveness: issue history, commit cadence, willingness to take PRs.

Integration Approach

Stack fit

• Laravel 10/11/12 + Nova 4/5, PHP 8.1+. Additive only: no migrations expected, possibly a publishable config. Fits cleanly alongside existing Nova tooling.
• Strategically, treat this as source you are adopting, not a dependency you are consuming. With zero dependents there is no upstream community to absorb breakage on your behalf.

Migration path

• Greenfield-additive; no data migration. The meaningful decision is provenance: composer require from Packagist, or fork into an internal namespace (Acme\NovaFilterBridge) with your own tests and README.
• Recommend the fork if you adopt at all — it converts an unmaintained external risk into a small, owned, reviewable piece of code.

Compatibility

• Pin an exact version; do not float. Add a CI contract test that applies the same filter to a resource index and to a Value metric and asserts identical counts — this is the only reliable guardrail against Nova-internal drift.
• Gate Nova upgrades behind that test. Review Nova's release notes for filter/request changes before every bump.

Sequencing

1. Spike (1–2 days, non-production): one filter + one metric, verify the state actually reaches the card's query.
2. Security review: transport mechanism reviewed by whoever owns tenancy/authorization. Block on this.
3. Pilot: one internal, low-stakes dashboard, behind a feature flag, with the contract test running in CI.
4. Adopt or revert: if adopted, fork, add tests, write a one-page internal README.
5. Expand only after surviving one Nova upgrade cycle intact.

• Fallback worth pricing first: a first-party base card class (~100 lines) that reads Nova's filter payload directly and reapplies it. Often cheaper than owning a third-party abstraction, and you keep full control of the security-sensitive part.

Operational Impact

Maintenance

• Effectively you own the code. Budget ~1–2 dev-days per quarter to track Nova releases, plus unplanned incident time. There is no vendor, no security-patch pipeline, no CVE process.

Support

• None. GitHub issues from one maintainer; 0 dependents means no Stack Overflow answers, no Slack threads, no blog posts. Your team is the support tier, and the only documentation is the source.

Scaling

• Each card computes in its own HTTP request. If filters are re-evaluated per card, a dashboard with N cards pays N× the filter query cost — watch dashboard latency and DB load as card count grows.
• If state is cached per user, cache cardinality scales as users × resources; plan for eviction and TTL.

Failure modes (ranked by severity)

1. Silent numeric drift — cards show unfiltered totals; nobody notices until a decision is made on bad numbers. Mitigate with the index/card parity contract test and a periodic assertion.
2. Cross-user or cross-tenant filter bleed — filters carrying authorization scope leak data between cards or users. Highest business impact; block on security review.
3. Card render exception — one bad filter value takes down the whole dashboard.
4. Nova upgrade breakage — abrupt, with no upstream fix timeline.
5. Abandonment — release history stops; the fork becomes the only path forward.

Ramp-up

• Technically shallow: a Nova-fluent developer understands the mechanics in a few hours.
• Practically expensive: no docs, no examples, no community means due diligence is the onboarding. Budget spike + security review before any commitment.

Bottom line: a plausible solution to a genuine Nova limitation, but with 0 stars, 0 dependents, and a single maintainer, it presents as unvalidated sample code rather than a supportable dependency. Fund a two-day spike and price the ~100-line in-house alternative in parallel; adopt only if the spike plus security review both pass, and only as a forked, internally tested component.