Nova Mongodb Laravel Package

Technical Evaluation

Architecture fit francescoprisco/nova-mongodb targets a narrow but real gap: Laravel Nova 5 assumes an Eloquent/SQL persistence layer for several of its own subsystems (resource querying, action_events, notifications). This package substitutes MongoDB-backed implementations for three of them — the Nova resource base class (MongoDBResource), action event logging (ModelObserver + ActionEvent), and the notification inbox (NovaNotification + MongoNotifiable). That is an opinionated architectural bet: it does not merely add a MongoDB driver, it replaces Nova internals with package-owned equivalents. Any team adopting it is effectively forking a slice of Nova's behavior into a third-party dependency. Fit is strongest for greenfield MongoDB-first applications already running mongodb/laravel-mongodb and willing to accept Nova's SQL-flavored defaults being overridden; fit is poor for existing SQL-primary apps adding MongoDB as a side store.

Integration feasibility The dependency floor is coherent and modern: PHP 8.2+, Laravel 11/12, Nova 5, MongoDB 5.0+, mongodb/laravel-mongodb ^5.5. Installation is likely conventional (Composer + service provider + config publish), and the surface area is small and enumerable — seven components and six notification routes. The route set is additive under the existing /nova-api prefix, so it does not require re-architecting HTTP concerns. Feasibility risk concentrates in the swap points rather than the install: swapping the base resource class, adopting the notifiable trait on the User model, and enabling global observer registration all touch code the team already owns. Realistically a 1–2 sprint pilot on a single non-critical Nova resource is achievable; a full migration of an existing Nova installation is not.

Technical risk

• v1.0.0 with no release history. A single initial release, no minor/patch lineage, no stated test suite, CI, or coverage in the notes. Treat as pre-production maturity regardless of the version number.
• "Zero SQL dependencies" is likely overclaimed. Nova 5 itself ships SQL-oriented defaults (own migrations, metrics/lenses assumptions, action_events table). The package replaces some of these, but the claim should be verified against the full Nova feature matrix — dashboards, lenses, filters, metrics, and Nova's own notification delivery path are not mentioned as covered.
• Global observer auto-registration is a high-blast-radius behavior: every MongoDB model gains write-path side effects, which risks write amplification, latency on bulk operations, and silent recursion if observers themselves write.
• Custom nested transaction handling is the single largest correctness risk. MongoDB multi-document transactions require a replica set (or sharded cluster); standalone mongod deployments — common in dev and some PaaS setups — will not support them. Emulated nesting can produce partial commits that the application believes are atomic.
• Regex search on MongoDBResource raises both performance (unanchored regex is not index-supported, causing collection scans) and input-handling (regex injection / ReDoS) questions.
• Single-maintainer, single-package dependency on a vendor namespace — bus factor and continuity risk for anything on the critical path.

Key questions

1. What is the test suite, CI status, and coverage for the resource query builder and transaction handling? The release notes omit any mention.
2. Does the package fully replace Nova's action_events and nova_notifications tables, or coexist? What happens if both are present?
3. Which Nova features are explicitly not supported for MongoDB resources (lenses, metrics, filters, aggregated relations, pagination/sorting semantics)?
4. Is the nested transaction implementation true MongoDB sessions with startTransaction/commitTransaction, or application-level emulation? What is the guarantee under failure?
5. What is the production deployment assumption for MongoDB — replica set required, or is standalone supported with degraded guarantees?
6. Is MongoDBResource a drop-in for Laravel\Nova\Resource, or does it diverge on search, sorting, and eager loading?
7. How are regex search inputs sanitized, and are indexes expected on searchable fields?
8. What is the maintainer's stated support window and release cadence, and is there a public issue tracker?

Integration Approach

Stack fit Best fit: Laravel 11/12 application with MongoDB as the primary datastore via mongodb/laravel-mongodb, Nova 5 as the admin surface, and a small, well-understood domain model. Poor fit: SQL-primary applications where MongoDB is a secondary store (the package's "zero SQL" posture conflicts with the rest of the app), or applications relying heavily on Nova lenses/metrics. Confirm the pinned versions match the target app exactly — the package supports a single major of each dependency, so there is no compatibility slack.

Migration path Adopt incrementally, never as a big-bang swap:

1. Add the package and configure the custom connection in a non-production environment.
2. Enable observer registration for one non-critical model first, and verify action event volume and write latency.
3. Introduce MongoDBResource for one new or low-traffic Nova resource; keep existing SQL-backed resources untouched.
4. Apply MongoNotifiable to User only after the notification routes are verified end-to-end (list, read, unread, read-all, delete, delete-all) — six routes, all requiring explicit test coverage.
5. Defer any migration of existing SQL-backed Nova resources until the pilot has run a full release cycle.

Compatibility Hard constraints: Nova 5 only, Laravel 11–12 only, PHP 8.2+, MongoDB 5.0+. There is no stated backward-compatibility commitment. The package replaces Nova internals via subclassing rather than patching, which is safer under Nova upgrades but means every Nova minor release needs re-validation of MongoDBResource against upstream changes. Confirm the mongodb/laravel-mongodb ^5.5 pin does not conflict with the version the app already uses — a shared dependency floor is the most likely Composer blocker.

Sequencing Phase 0 — evaluation: read the source for the transaction and observer implementations (not just the README); run the existing test suite locally; confirm replica-set availability in staging. Phase 1 — isolated pilot: one resource, one model, observer enabled, behind a feature flag. Phase 2 — notification subsystem: enable MongoNotifiable for a subset of users, verify route behavior and Nova UI consistency. Phase 3 — expand: onboard remaining MongoDB resources, one per PR, with rollback defined as reverting the base class and disabling observer registration. Phase 4 — decommission any duplicated SQL tables only after a full quarter of stable operation.

Operational Impact

Maintenance The package owns implementations of Nova-internal behavior, so the maintenance burden is not "keep a dependency updated" but "track Nova releases and validate a fork of its behavior." Budget a recurring review task per Nova minor release. If the maintainer stops publishing, the team inherits roughly seven components including a custom connection class and a base resource — non-trivial to absorb. Recommend pinning to an exact version, vendoring/committing the lockfile, and evaluating an internal fork or a composer.json patch layer as a contingency.

Support Support is single-maintainer and community-based; the release notes disclose no SLA, no security policy, and no issue-triage commitment. Escalation paths are effectively self-service. Mitigate with internal ownership: assign a named engineer as the package owner and require a written understanding of the transaction and observer code paths before production exposure. Anything on the critical path should not depend on upstream responsiveness.

Scaling Two scaling concerns dominate. First, regex-based search without anchors forces collection scans — at scale this degrades non-linearly and will not be caught in pilot-sized datasets; ensure searchable fields are indexed and that the resource uses anchored or $text-style queries where possible, and load-test with production-order-of-magnitude collections. Second, observer-driven action logging writes on every CRUD operation, roughly doubling write volume on mutated models and inflating storage; plan for a capped or TTL-indexed ActionEvent collection and monitor write latency. Custom nested transaction handling adds session overhead under concurrency. Read scaling depends on the underlying replica set, not on this package.

Failure modes

• Transactions fail on standalone MongoDB — partial writes presented as atomic; the highest-severity failure and the one most likely to surface only in production.
• Observer recursion or amplification — an observer write triggers further writes; manifests as latency spikes or unbounded collection growth.
• Nova upgrade breaks MongoDBResource — silent behavioral drift in search, sorting, or pagination rather than a hard failure; detected only by regression testing.
• Notification route drift — Nova's own expectations diverge from the custom routes, producing missing or duplicated notifications in the UI.
• Composer conflict on mongodb/laravel-mongodb — installation-time blocker, low severity but high friction.
• Maintainer abandonment — deferred but cumulative risk; no immediate failure signature.

Ramp-up Low for installation (conventional Composer flow, small surface area, clear component list). Moderate for correct usage (subclassing Nova's resource base and enabling global observers demands familiarity with Nova internals). High for safe operation (understanding the nested transaction semantics, replica-set requirements, and regex search characteristics requires reading source, not documentation — the release notes describe what exists but not how it behaves under failure). Estimate 2–3 days for a competent Laravel engineer to reach productive use on a pilot, plus 1–2 days of source review by a senior engineer before any production exposure. Given v1.0.0 maturity, single-maintainer support, and an unverified "zero SQL" claim, recommend pilot/experimental status with feature-flagged rollout and no placement on the critical path until a stable maintenance and test signal exists.