Nova Dynamic Resources Laravel Package

Technical Evaluation

Architecture fit opscale-co/nova-dynamic-resources is a Laravel package that extends Laravel Nova by allowing resource fields to be defined dynamically (schema/config-driven) rather than hard-coded in PHP resource classes. It fits cleanly into the standard Laravel package model — service provider registration, Nova tool/field bootstrapping, and config publishing — so it composes with an existing Nova installation without altering the host application's domain layer. The v1.12.0 addition of a multiselect catalog-backed field strengthens the fit for admin panels where selection options are data-driven (e.g., taxonomy, product catalogs, lookup tables) instead of enumerated in code, which is the primary reason teams adopt dynamic resource packages in the first place.

Integration feasibility The change is additive and shipped as a minor version (1.12.0), so integration effort is low: no migration is required for existing field definitions, and adoption is opt-in per field. Feasibility is high provided the team already runs Nova at a compatible major version and has a working dynamic-resource schema. The catalog-backed behavior implies the package resolves option sets from application data or a configured provider — the main integration work is confirming that resolution path (Eloquent model/query vs. custom resolver) matches how the host app models its catalogs.

Technical risk

• Low: breaking-change risk — semver minor, feature-only commit, no deprecations listed.
• Moderate: data-shape risk — multiselect persists arrays; existing pivot/JSON columns and API serializers must accept array payloads for fields that adopt the new type.
• Moderate: performance risk — catalog-backed option loading on large catalogs can introduce N+1 or unbounded option queries in index/detail views; needs pagination/search support confirmation.
• Moderate: dependency risk — the release notes are terse (single commit, no docs/changelog detail), so behavior around validation, null handling, and maximum selection counts is undocumented in the note itself.

Key questions

1. How is the catalog source declared — config array, Eloquent model class, or custom resolver contract — and is it cached?
2. Does the field support server-side search/pagination for large catalogs, and what are the default limits?
3. How are stored values represented (array of IDs, array of {id,label} objects) and are they stable across catalog mutations (renamed/deleted entries)?
4. Is there built-in validation for max selections, allowed values, and orphaned IDs?
5. Are there Nova version constraints introduced or changed by this release?
6. Is the feature covered by tests and documented beyond the commit message?

Integration Approach

Stack fit Assumes Laravel + Nova with the package already or newly installed via Composer. The multiselect field is a Nova field type surfaced through the package's dynamic schema, so it requires no changes to the host application's controllers or routing. If catalogs live in Eloquent, the field can reuse existing models; if they live behind a service or external API, a resolver/adapter will be needed.

Migration path

1. Pin to ^1.12 in composer.json and run composer update opscale-co/nova-dynamic-resources in a branch.
2. Verify the package's published config/assets are current (vendor:publish --force only where safe).
3. Add a single pilot field using the new multiselect type in a non-critical resource.
4. Confirm storage: add or reuse a JSON/text column or pivot table if arrays are persisted; write a backfill only if converting existing single-select fields (not required for net-new fields).
5. Roll out to remaining resources once the pilot is validated in staging.

Compatibility Minor release with no stated breaking changes; existing dynamic field definitions should be unaffected. Confirm the installed Nova major version remains within the package's supported range, and validate that array-valued fields serialize correctly through any existing API resources, exports, or Nova filters.

Sequencing Pilot field → staging validation (persistence, validation, catalog resolution) → confirm option-loading performance on the largest catalog → production rollout per resource → documentation update for internal field-definition conventions. Keep the previous version pinned in the lockfile for a fast rollback window.

Operational Impact

Maintenance Low incremental maintenance: one dependency bump plus internal docs for the new field type. Catalog-backed fields shift some ongoing ownership to whoever maintains the catalog data — option hygiene (renames, deprecations, deletions) now has UI-visible consequences, so a data-ownership convention is worth defining.

Support Anticipate support requests around "my saved selections disappeared" (catalog entries deleted/renamed) and "the dropdown is slow" (large catalogs without search). Because the release note is thin, the team should treat upstream docs/source as the source of truth and capture internal notes from the pilot.

Scaling Primary scaling concern is option-volume, not request-volume: catalogs in the thousands of entries require server-side search and pagination to stay usable. Stored arrays also grow index/detail payloads and can complicate filtering and reporting queries; consider whether multiselect values need a normalized join table for analytics.

Failure modes

• Unbounded catalog query degrades Nova index performance.
• Orphaned IDs after catalog deletions produce blank or partial labels.
• Array payload rejected by a string column or strict validator.
• Cache staleness if catalog options are cached and not invalidated on writes.
• Rollback to a pre-1.12 version while multiselect fields exist leaves unresolved field types in dynamic schemas — sequence rollback with field removal.

Ramp-up Minimal for developers already familiar with the package (new field type in an existing schema DSL). Expect a short learning curve for admins defining dynamic resources, and roughly half a day of engineering to pilot, validate, and document.