Nova Databoards Laravel Package

Getting Started

Before anything else, verify it still installs. The package is archived (last release July 2020) and targets the Nova 3.x / Laravel 6–7 / PHP 7.2–7.4 era. Try composer require nova-bi/nova-databoards in a throwaway branch first; if dependency constraints fight your locked laravel/nova version, stop and evaluate the fork path before sinking time into it.

Minimal path:

composer require nova-bi/nova-databoards
php artisan vendor:publish --provider="NovaBi\\Databoards\\ToolServiceProvider"
php artisan migrate

Then register the tool in app/Providers/NovaServiceProvider.php:

public function tools()
{
    return [
        new \NovaBi\Databoards\Databoards(),
    ];
}

Where to look first, in this order:

1. src/ — the tool class, any Databoard/widget models, and the policies. This tells you what the persistence layer actually looks like and whether "databoards" are DB rows or config.
2. database/migrations/ — the published migrations are the real schema documentation. Read them before you design anything on top.
3. routes/ and src/Http/ — Nova tools are thin controllers; this is where the query logic that powers a board lives, and therefore where the performance and authorization bugs are.
4. resources/js/ and the tool's resources/views/ — to see whether the frontend is a compiled Vue bundle you cannot easily change.

First use case to prove out: replace the default Nova dashboard with a single databoard for one team — three or four metric cards over one or two tables — and confirm (a) the queries run in acceptable time, (b) a non-admin user sees only what they should. Do not start by building a shared analytics surface for the whole company; you'll learn the authorization model the hard way.

Implementation Patterns

Treat databoards as data, not code. Because boards are persisted records, the reliable workflow is: create the board by hand in a staging environment, export the rows, and commit them as a seeder. Hand-clicked dashboards are the classic thing that exists in production and nowhere else, and when you rebuild an environment you lose months of configuration.

// database/seeds/DataboardSeeder.php
// Create in staging → dump → commit. Idempotent via updateOrCreate on a stable slug.

Separate "board layout" from "query logic." The package's cards are configuration; the numbers behind them are yours. Put each metric in a small, testable class or query scope in your app, and have the board reference it. When someone asks why a number looks wrong, you want to open one file, not click through a UI.

Scope every board to a tenant or role. The common pattern in Nova analytics tools is a board visible to whoever can reach the tool. If your app is multi-tenant, either:

• give each tenant its own board records and filter by the authenticated user's tenant in a policy, or
• keep one board and enforce scoping inside the queries.

Pick one deliberately. Mixing them is how cross-tenant numbers leak.

Pair with Nova's native metrics for anything you can't verify. The built-in Value/Trend/Partition metrics are maintained; this package is not. For the handful of numbers leadership actually looks at, having a known-good Nova metric alongside the databoard is a cheap sanity check during rollout.

Precompute heavy aggregates. Board pages fire every card's query on load. For anything touching events or logs tables, roll up into a daily summary table on a schedule and point the cards at that.

// app/Console/Commands/RollupDailyMetrics.php — schedule daily at 01:15
// Then databoard cards query the summary table, indexed on (tenant_id, date).

Frontend changes go through the build, not the published assets. If you need to restyle, edit resources/js, run the package's npm run prod, and republish — editing compiled files in public/vendor/ works until the next composer install or deploy.

Gotchas and Tips

Archived means you own the maintenance. Pin the exact version ("nova-bi/nova-databoards": "1.0.x" not ^1.0), or vendor it into your repo with a path/VCS repository entry so you can patch it. Any fix you make is a private fork — track the diff.

Nova 4 and Vite will break this. Nova 4 moved to Vite and changed the tool bootstrapping; a 2020 tool's compiled assets and webpack assumptions generally do not carry over. If you're upgrading Nova, budget for either a rewrite or removal. Same for PHP 8.1+ — deprecation warnings from 2020-era code become errors fast.

Published migrations are a one-way door in most teams. Publish them, review them, and commit them into database/migrations alongside your own — don't rely on php artisan migrate picking up the package's internal path. If you roll back without the package installed, you'll leave orphaned tables.

Timezone bugs are the number-one "the dashboard is wrong" complaint. Grouping by DATE(created_at) in the DB uses the DB session timezone; PHP uses config('app.timezone'). Settle on one, ideally by converting in the query (CONVERT_TZ) or storing a UTC date column. Check a board's numbers against a raw SQL query across a midnight boundary before you trust it.

Watch the query count. Open the board with Telescope or Debugbar on a seeded database. A board with eight cards is eight round trips minimum, often many more if the package loops per-card. Missing composite indexes on (tenant_id, created_at) on large tables is the usual culprit.

Authorization is the sharp edge. Verify explicitly, as a non-admin user:

• Can they see the tool in the sidebar at all?
• Can they see boards belonging to another role?
• Can they hit the tool's routes directly by URL?

If the tool ships no policies, add your own Gate checks in a service provider rather than trusting navigation-level hiding.

Caching, if the package offers it, is config-driven and easy to mis-set. Check for a published config file and confirm the cache TTL and store — a board cached to the file store behaves differently across multiple app servers than you expect. Clear it deliberately after data backfills.

Extension points are limited, so design around the package rather than into it. The reliable seam is the data: your own models, query scopes, and summary tables. Custom card types or view overrides are possible in Nova tools but are the first thing to break on upgrade — avoid them unless the board is a throwaway.

Have an exit plan. For a 21-star archived package, assume it's a stopgap. If the databoards are load-bearing for the business, scope a replacement — a simple Livewire/Inertia page with a handful of cached aggregate queries delivers most of this functionality with none of the maintenance risk.