Nova Dashboard Manager Laravel Package

Technical Evaluation

Architecture fit This is a Nova tool (admin-panel plugin), not a standalone BI layer. It only fits if Laravel Nova is already licensed and the target users live inside the Nova admin surface. It adds a dashboard-composition layer on top of Nova's native dashboard/card primitives — so the real architectural question is whether it replaces native cards() + dashboard customization with something meaningfully better, or just wraps it. Given a low opportunity score (1.89) and 21 stars, the differentiation over Nova's built-in dashboards is probably modest. If analysts or external customers need dashboards, this is the wrong tool — reach for Metabase/Superset instead.

Integration feasibility Mechanically low-friction: Composer install, service provider auto-discovery, Nova::tools()/Nova::cards() registration, publish config + migrations + compiled assets. The friction is not installation, it's version alignment and source legibility. With a single-maintainer, 21-star package, expect to read the source rather than the docs. Feasible as a bounded spike; not feasible as a hands-off dependency.

Technical risk

• Staleness is the dominant risk. Last release 2023-09-15. Nova 4 and Nova 5 diverge significantly at the front-end (Nova 3 = Vue 2; Nova 4+ = Vue 3/Inertia), so a tool built for an older Nova branch cannot be assumed to work on a current one. Verify the composer.json constraints for laravel/nova before anything else.
• Bus factor 1. No crowd-sourced fixes, no vendor. Community is too small to outsource patch discovery.
• Query surface. "Dashboard" implies user-defined data sources. Whether widgets are Eloquent/query-builder or raw SQL materially changes the security posture (injection, unbounded scans, privilege escalation for dashboard authors).
• Authorization scoping. No evidence of multi-tenant or per-user scoping of dashboard visibility; must be verified against Nova policies/gates.
• Migration footprint. Tools that publish migrations create tables in the app database — upgrade and rollback ordering becomes a deploy concern.
• Mitigating factor: MIT license means forking is legally clean and technically viable. That converts "abandonware risk" into "ownership cost," which is a manageable trade.

Key questions

1. Which Nova major versions are supported in composer.json? Does it install on the current Nova release?
2. What are the PHP/Laravel constraints — does it resolve on the current PHP and Laravel majors?
3. How are widget data sources defined: Eloquent/query builder, config, or raw SQL? Any arbitrary code execution path?
4. Does dashboard visibility reuse Nova authorization (policies/gates), and is it tenant-aware?
5. Any tests, CI, or static analysis in the repo? (Absence implies we inherit all regression risk.)
6. Who consumes dashboards — internal admins only, or customers? This decides whether the plugin is sufficient or a dead end.
7. Is upstream responsive to issues/PRs, or would we become the de facto maintainer on day one?

Integration Approach

Stack fit Laravel + Nova + MySQL/Postgres. Two hard prerequisites: a paid Nova license per environment, and a front-end build chain compatible with the Nova branch in use. The front-end compatibility question is the gating item — if the tool targets Nova 3, adopting it means porting the Vue layer to Nova 4/5, which is a rewrite, not an upgrade.

Migration path Treat it as an internal fork, not an upstream dependency:

• Fork into a private repo, add a VCS composer repository entry, and pin to an internal tag.
• Never depend on the public Packagist release in production paths.
• Publish assets from source in CI so compiled bundles don't drift between environments.

Compatibility Build an explicit matrix (PHP × Laravel × Nova × package tag) and pin all four. Validate with a throwaway application and composer why-not before touching the real admin app. Assume the answer is "current Nova is unsupported" until proven otherwise.

Sequencing

1. Confirm Nova/Laravel/PHP baseline and upstream constraints — 1 hour, decides go/no-go on the spike.
2. Timeboxed spike in a disposable app: install, publish, migrate, author one dashboard against real data — 2–4 days.
3. Security review of the widget data-access and authorization layer before any pilot.
4. Fork under org ownership; add CI (tests, static analysis, style), bump and pin dependencies.
5. Internal pilot: one team, 2–3 dashboards, behind a feature flag.
6. Build-vs-buy checkpoint against native Nova cards and embedded BI, then decide on wider rollout.

Keep the tool feature-flagged and out of the critical deploy path so a failed Nova upgrade degrades dashboards, not the admin application.

Operational Impact

Maintenance Adoption equals ownership. Budget roughly 1–2 engineer-days per quarter for dependency hygiene, and materially more on any Nova major upgrade (front-end porting risk). Assign a named owner before the pilot; unowned forks rot faster than the upstream did.

Support No vendor, no SLA — GitHub issues only, with a small community. Requires an internal runbook covering install, asset publishing, migration rollback, and dashboard authoring conventions. Define the SLA you'll offer consumers yourself.

Scaling Dashboard widgets fan out into N queries per page view. With M concurrent admins this is usually fine (admin traffic is low), but unbounded date ranges and unindexed widget queries will surface as DB pressure and slow admin pages. Mitigate with query timeouts, a read replica for widget data, and caching of expensive widgets. This package is not a high-concurrency reporting engine and shouldn't be treated as one.

Failure modes

• Nova upgrade breaks the tool's JS → blank dashboards or Nova boot failure.
• Published migrations collide or roll back out of order during deploys.
• Long-running widget queries hang the admin panel and load the primary DB.
• Authorization gap exposes dashboards across users or tenants.
• Upstream goes fully dark; a security issue never gets patched.
• Compiled assets diverge between environments if built outside CI.

Mitigations: fork + CI, hard version pins, feature flag, query timeouts and caching, authorization tests in the fork's suite, documented rollback.

Ramp-up One engineer needs ~1–2 weeks to become productive across Nova internals (tools, cards, Vue/Inertia) plus the fork's code. Dashboard authors need lighter onboarding but heavier governance: certified metric definitions, naming conventions, and a review step, or the org ends up with a sprawl of contradictory numbers.

Bottom line: viable only as an owned fork, only if the Nova version gap is closed cheaply, and only for internal admin-facing dashboards. The score profile (2.27 overall, 1.89 opportunity) matches what the repo evidence shows: a thin layer over native Nova capability, with maintenance risk that outweighs its feature delta unless the spike proves otherwise.