shahabzebare/laravel-nova-turbo
Laravel Nova Turbo is a performance-boosting package for Laravel Nova that streamlines and accelerates your admin panel, delivering faster load times and a smoother experience with minimal setup and configuration.
Architecture fit: Laravel Nova Turbo is a drop-in performance layer for Laravel Nova applications. Its core value proposition—lazy-loading resources and caching resource relationship metadata—fits cleanly into Nova's resource registration model without appearing to require forking Nova or modifying vendor code. For installations with large resource counts (the release cites 100+ resources), this addresses a known Nova pain point: the cost of bootstrapping and resolving all resources on every request. The package adds an application-level cache (PHP array files, opcache-friendly) and an explicit external-resource registration API (NovaTurbo::resources()), which is the right integration seam for modular monoliths and package-provided resources.
Integration feasibility: High for greenfield and standard Nova apps. Composer-installable, Laravel 10/11/12 and Nova 4/5 coverage means most current estates are in scope. Two artisan commands (nova:turbo-cache, nova:turbo-cache --clear) plus three config keys keep the operational surface small. The cache:clear auto-regeneration hook is convenient but is the main feasibility question mark: it couples package behavior to a framework command that is used in many different deployment and local workflows.
Technical risk: Moderate. Primary risks are cache correctness and invalidation, not runtime stability. Relationship mapping is inferred and cached; if resource relationships change (or are registered dynamically/conditionally), stale metadata could produce incorrect or missing relationship behavior. Second risk is deploy-time cache state across multiple app servers—PHP array file caches must be generated on each node or shared via a common release path. Third risk is that auto_refresh_in_dev creates a production/development behavioral divergence: lazy loading is disabled locally, so performance and edge-case behavior are only exercised in non-local environments. Fourth, this is a 1.0.0 initial release with no prior public hardening; benchmark claims (59% faster, 95% fewer resources loaded) are vendor-reported and tied to a 100+ resource profile that may not match our estate.
Key questions:
cache:clear, or also resource file changes, composer updates, and config changes?Stack fit: Strong fit for our Laravel + Nova stack, assuming Nova 4.x/5.x and Laravel 10–12. The package is additive: install, publish config, optionally register external resources, generate cache. No database migrations or schema changes are mentioned, which keeps rollback simple (remove package, clear cache).
Migration path: This is a new adoption, not a migration—there is no prior assessment and no legacy package to replace. Recommended path: (1) install in a non-production environment, (2) run nova:turbo-cache and validate the generated cache, (3) exercise resource index, detail, relationship, and action flows, (4) compare response times against baseline on a representative resource count, (5) promote to staging with production-like multi-node topology, (6) roll out to production behind a config flag.
Compatibility: Nova 4 and 5 plus Laravel 10, 11, and 12 covers the likely current estate, but we should confirm our exact Nova minor version and any Nova extensions (custom tools, cards, fields) that may rely on all resources being loaded. External resource registration via NovaTurbo::resources() needs an inventory of module/package-provided resources so none are silently omitted from the cache.
Sequencing: Config and resource-path discovery first; cache generation second; CI/CD integration third; development-mode configuration last. Treat the cache:clear hook as a separate decision—enable it only after confirming it does not conflict with existing deploy scripts that call cache:clear for unrelated reasons. Add a post-deploy nova:turbo-cache step explicitly rather than relying solely on the hook.
Maintenance: Low ongoing code maintenance, but non-zero cache lifecycle maintenance. Every deploy that changes resources, relationships, or config must produce a fresh cache. The package's cache versioning (invalidate on package update) helps for package upgrades but does not cover application-level resource changes. We should own a documented runbook: when to regenerate, how to verify, and how to clear.
Support: 1.0.0 with no track record. Support risk is the largest non-technical concern: unclear vendor responsiveness, unclear semantic-versioning guarantees, and dependency on Nova's internals for relationship detection. Pin the version, monitor releases, and avoid depending on undocumented behavior.
Scaling: The design scales well horizontally if the cache is generated per node or stored on shared storage. PHP array files with opcache are fast and avoid Redis/network overhead, but they are filesystem-local by default—multi-node and autoscaled environments need a deliberate strategy (bake into the release artifact, generate in container entrypoint, or share a volume). Large resource counts are exactly the target case, so the performance upside is highest where the operational care is also highest.
Failure modes:
resource_paths or NovaTurbo::resources() → resources disappear from Nova.cache:clear hook firing during deploy before code is fully released → cache built from mixed code state.Ramp-up: Low for developers (install, config, two commands), moderate for platform/DevOps (deploy sequencing, multi-node cache strategy, rollback procedure). Estimate: half a day for a pilot in staging, one to two days to productionize including CI/CD changes and runbook. Recommend a pilot on the highest-resource-count Nova application first, with explicit baseline metrics, and a rollback plan limited to disabling the package and clearing the cache.
How can I help you explore Laravel packages today?