Nova Databoards Laravel Package

Technical Evaluation

Architecture fit. nova-bi/nova-databoards is a Laravel Nova tool that mounts a bespoke dashboard-builder UI (Vue components) over an Eloquent-backed metric aggregation layer. Architecturally it only fits a narrow shape: a server-rendered Laravel monolith on Nova 2.x/3.x where analytics are already expressed as Eloquent queries against the primary application database. It does not fit headless/Inertia/Livewire-first stacks, multi-tenant SaaS with strict row-level isolation, or teams standardizing on an external warehouse (BigQuery, Snowflake, Postgres read replica) as the analytics source of truth. Treat it as a reference implementation of "dashboards inside the admin panel," not as a platform component.

Integration feasibility. Low without a fork. The archive date (2020-07) places it in the Laravel 6/7 and Nova 2/3 era; its Composer constraints will not resolve against Laravel 9+/Nova 4+, and Nova 4's tool registration and Vue 3 migration will break the front-end tooling. There are no upstream maintainers to accept a PR, so any integration work is a permanent private fork. Realistic effort for a viable PoC: 1–2 engineer-weeks (dependency patching, Nova API migration, one representative dashboard end-to-end).

Technical risk. High.

• Abandonment risk (materialized): no security patches, no PHP 8+ compatibility work, no transitive dependency hygiene. Any CVE in its locked dependency tree is yours to remediate.
• Framework coupling: tightly bound to Nova's private, licensed front-end conventions; a Nova major upgrade is a forced rewrite, not an upgrade.
• Authorization surface: dashboard definitions typically encode query scope; without a clear policy layer, a mis-scoped dashboard is a cross-tenant data-leak vector. This must be treated as a security-reviewed component, not a UI convenience.
• Query performance: request-time aggregation against the OLTP primary is a latent production incident.

Key questions for the team.

1. What Nova and Laravel majors are actually running in production today, and is there a funded Nova upgrade inside 12 months?
2. Is the business requirement "dashboards for internal ops users" (Nova-adjacent) or "customer-facing analytics"? The latter disqualifies this package outright.
3. Do we already have a BI surface (Metabase, Looker Studio, Redash) that would satisfy 80% of the need at zero maintenance cost?
4. Who owns the fork — named engineer and on-call rotation — and is that accepted by engineering leadership?
5. Are metric definitions already codified anywhere, or would this package become the accidental system of record for KPIs?

Integration Approach

Stack fit. Compatible only with: PHP 7.2–7.4, Laravel 6.x/7.x, Nova 2.x/3.x, MySQL/Postgres primary. Incompatible in practice with PHP 8.1+, Laravel 9+, Nova 4+, and any environment enforcing composer audit or SBOM gates. If the estate has already moved past Laravel 8, this is a no-adopt for anything beyond reading the source.

Migration path. Three options, in order of preference:

1. Do not integrate — harvest. Read the metric/dashboard schema and UI patterns, reimplement the 2–3 dashboards that matter as native Nova cards or a small Livewire/Vue island on the current stack. Lowest long-term cost.
2. Private vendored fork. Fork to an internal Git host, publish via Private Packagist/Satis, pin an exact commit, patch Composer constraints and the Nova tool registration, add a policy layer, and wire metric queries to a read replica. Accept a standing ~10–15% of one engineer's capacity as maintenance.
3. Full adopt as-is. Rejected: unresolved dependencies, no security posture, no upgrade path.

Compatibility validation sequence (2–3 day spike, before any commitment):

• composer why-not against the target Laravel/Nova versions; record the exact conflict set.
• Boot the tool in a throwaway Nova instance; confirm route registration, menu entry, and asset publishing.
• Execute one real metric query against a read replica with production-shaped data volume; measure p50/p95 latency.
• Probe authorization: confirm a low-privilege Nova user cannot enumerate or render dashboards they shouldn't see.

Sequencing. (1) Requirements audit — confirm no existing BI tool already covers the need. (2) Spike above; produce a go/no-go memo with measured latency and conflict list. (3) If go: fork, patch, security review, staging deployment behind a feature flag. (4) Production rollout limited to internal staff only. (5) Set an explicit sunset/replace-by date at adoption time.

Operational Impact

Maintenance. This is the dominant cost and it is entirely yours. There is no upstream. Budget: dependency/security patching on a quarterly cadence, a forced re-evaluation at every Laravel or Nova major, and unplanned breakage from PHP minor upgrades. A defensible rule is that the fork must never be more than one framework major behind — which, given the 2020 codebase, is already violated at adoption.

Support. No vendor, no maintainer, 21 stars and archived means no meaningful community to escalate to. Internal support means an engineer who has read the source becomes the sole knowledge holder — a bus-factor-1 risk. Document the metric DSL and query path as a hard prerequisite to production.

Scaling. Watch three axes:

• Query load: dashboards hitting the OLTP primary will scale linearly with viewer count and will contend with transactional traffic. Mitigate with a dedicated read replica plus a caching layer (Redis, short TTL on aggregates).
• Data volume: if the metric layer issues COUNT/SUM over unindexed or growing tables, latency degrades silently over months. Add query-time budgets and alerting.
• User concurrency: the Nova tool renders server-side per request; there is no push/streaming model, so N viewers = N query executions.

Failure modes to instrument for.

• Silent framework-upgrade breakage — the tool simply stops rendering after a Nova bump; needs a smoke test in CI.
• Cross-tenant data exposure via an over-broad dashboard definition — highest-severity failure, must be covered by an authorization test and audit logging.
• Dashboard timeouts / primary-DB saturation during month-end or reporting peaks.
• Transitive dependency CVE with no patch path — forces an unplanned emergency fork or removal.
• Knowledge loss — original author leaves, fork becomes unmaintainable, dashboards become zombies that nobody dares delete.

Ramp-up. For a Laravel developer already fluent in Nova: 2–4 days to be productive, plus 1 week to become the internal owner. For anyone else: substantial, because the metric/query model is undocumented and must be reverse-engineered from source. Add a half-day of onboarding for the security review findings and the read-replica query path.

TPM recommendation. Score 1.80 with the package archived since 2020 makes this a reference-only asset. Approve a 2–3 day evaluation spike to harvest patterns and confirm no existing BI tool covers the requirement. Do not approve production integration unless the estate is genuinely pinned to Nova 3 / Laravel 7 with a funded migration already scheduled — in which case the fork is a stopgap with a named owner and a hard sunset date, not a platform decision.