Dynamic Dashboard Laravel Package

Technical Evaluation

Architecture fit. This is a Filament panel plugin, not a framework-level dependency. It registers through the standard Panel::plugin() contract, so it attaches at the presentation layer of one panel and does not touch routing, authentication, tenancy, or the domain model. Its functional scope is deliberately narrow: widget registration, a picker UI, drag-and-drop arrangement, and per-user layout persistence. That is a leaf node in the dependency graph — replaceable, isolatable, and low-coupling, provided we introduce a seam (WidgetRegistry) rather than scattering WidgetClass::class strings across providers.

Integration feasibility. Medium-low effort, high uncertainty. The mechanical path is short: composer require, publish config, publish migrations, php artisan migrate, register the plugin. The uncertainty is not installation — it is that documentation consists of one line of release notes, so vendor/lara-zeus/dynamic-dashboard/src is the actual specification. Budget a timeboxed spike (3–5 engineer-days including source read) on a non-customer-facing panel to validate the full loop: register a widget → reorder it as a non-admin → refresh → log out and back in → confirm persistence. That single loop de-risks the majority of the integration.

Technical risk. Ranked by expected cost:

• Version coupling (highest). 5.0.0 exists solely to add Filament 5 support. Majors in this package are welded to Filament majors. Adopting ahead of, or separately from, our Filament 5 upgrade destroys the rollback point. Filament 3/4 shops should stop here.
• Vendor viability. 16 stars, 0 dependents, single maintainer, one-line changelog for a major. This is "viable with a fork fallback," never a safe default. The mitigation is a pinned constraint plus committed lockfile plus a minimal customization diff surface, so a fork is a day of work rather than a month.
• Schema ownership. Per-user layouts are production user data. The published migration may be a JSON column on users or a dedicated table; an upstream upgrade may alter or drop it. Decide before commit whether we copy the migration into database/migrations/ and own the table name.
• Authorization surface. If users can self-select widgets, the widget list is an access-control boundary. The package manages layout; it has no knowledge of our data boundaries. Every data-bearing widget needs its own canView() / policy / scoped-query enforcement. Hiding a widget in the picker is not authorization. This is the most likely source of a product-visible incident and should get a design review before any user-facing rollout.
• Render isolation. If an exception in one widget takes down the page, any widget with an external dependency or a slow aggregate becomes a dashboard-wide availability risk.
• Orphaned layout rows. Removing a widget from the registry does not clean persisted references. Failure mode is silent blank cards; we must choose filtered-read-at-render or a cleanup command before it happens.

Key questions to answer before commit.

1. What are the exact Filament/PHP/Livewire floors in composer.json, and does it strictly require Filament 5?
2. Does the plugin expose a programmatic widget-registration API, or is config file the only entry point?
3. Is layout persistence a JSON column on our users table or a package-owned table we cannot rename?
4. Is widget rendering isolated per widget, or does one exception blank the page?
5. What routes/assets does the plugin register, and are they gated by panel middleware and policy?
6. Can the default layout be role-based or seeded, or only a single global default?
7. Can we toggle between the dynamic page and Filament's stock dashboard per panel without a deploy?

Integration Approach

Stack fit. Adopt only inside an existing Filament 5 panel. It brings no value outside Filament, and pulling in Filament in order to use this package is backwards. Blast radius should stay admin-only — staff-visible outages are recoverable; customer-facing ones are not. Do not reuse the package's layout logic outside Filament panels.

Compatibility gate. Verify the constraint before any code is written: composer show lara-zeus/dynamic-dashboard --all. Pin ^5.0 and commit the lockfile. If we are on Filament 4, the package does not enter the plan until the Filament upgrade. The package bump and the Filament bump land as one ticket with one rollback point.

Migration path.

1. Inventory first. Classify every existing dashboard widget as (a) works unchanged, (b) needs re-registration, or (c) needs a rewrite. Class (c) is our schedule risk, not the package's — surface it before the estimate is committed.
2. Seam. Create app/Support/Dashboard/WidgetRegistry.php as the single source of widget classes and feed it into whatever registration point the plugin exposes. Every future widget becomes a one-line diff in one file, and a fork or replacement becomes cheap.
3. Fallback flag. Add a per-panel config toggle between the dynamic dashboard and Filament's stock dashboard. A package regression becomes a flag flip, not a revert-and-redeploy.
4. Schema decision. Inspect the published migration before migrating. If the package owns a table we cannot rename, copy the migration into database/migrations/ and own it.
5. Authorization review. Gate widgets server-side, inside the widget. Run the spike against a restricted-role user and confirm a forbidden widget is not reachable by adding it directly.
6. Incremental port. One panel at a time, behind the flag, starting with a stat card or chart.

Sequencing. The ordering constraint that matters is: Filament 5 upgrade → package install → spike → authorization review → per-panel rollout. Never install the package before the Filament bump, and never run two layout models in parallel — dual-running produces conflicting UX and duplicated widget code, and that cost lands on product, not engineering.

Testing posture. Test the loop, not the library: panel boots, widget renders, reorder persists across sessions, restricted user cannot see a forbidden widget, and query counts stay within budget on production-sized data. A short Livewire/feature test per behaviour is sufficient; adjust assertions to whatever routes the package actually registers.

Operational Impact

Maintenance. Recurring cost is a major-version migration every time Filament ships a major. Each upgrade requires diffing published config, migration, and view/asset tags before composer update, plus a theme rebuild and view re-publish — Filament majors routinely rework CSS/JS. Track this as a standing line item in the admin roadmap, not a one-off. Keep customizations confined to published config and views so the fork diff stays small.

Support. There is effectively none: MIT, single maintainer, no SLA, no documented security disclosure path, and a one-line changelog for a major release. Assume we learn behavior by reading and diffing source. Mitigations: internal docs/widgets.md documenting our widget contract ("how to add a dashboard widget"), a named owner for the dependency, and a dependency-policy record of the "viable with fork fallback" classification so the decision is not re-litigated each quarter.

Scaling. The load profile is per-user layout reads on every dashboard request plus drag-and-drop assets. Watch the widget query budget rather than the package's own overhead — the expensive part is what our widgets query on production-sized data. Whether layouts live in a JSON column on users or a dedicated table affects row width, index strategy, and how much of the user table we touch on unrelated queries; resolve it before committing to schema.

Failure modes and responses.

Ramp-up. A new developer cannot onboard from documentation that does not exist. Ramp cost is one source-reading pass plus our internal widget contract doc; realistically one week to first productive widget, less for subsequent ones. The upside is that the package's scope is small enough to fully understand — the risk is comprehension time, not complexity. Approve the spike in a non-customer-facing panel; do not commit to revenue-linked surfaces until the spike and the widget-authorization review both clear.