Nova Text Filter Laravel Package

Technical Evaluation

Architecture fit. This is a leaf dependency on the admin surface, not a platform component. It ships a Nova filter contract implementation — an abstract PHP filter class plus a Vue input component — that plugs into Nova's existing filter lifecycle. It adds no search service, no index, no new data store, and no write path. That makes it architecturally cheap to adopt and cheap to remove. It fits only when the admin surface is already Nova, the target data is Eloquent-backed (including relationships and qualified columns), and the need is column-targeted search alongside Nova's global search. It does not fit any requirement for faceted filtering, saved views, cross-model search, or high-volume ranked search — those are a different architecture (Scout/Meilisearch/Postgres full-text), not a bigger version of this.

Integration feasibility. The happy path is short and well understood: composer require, provider auto-discovery, nova:filter scaffolding, reparent to the package base class, register in filters(). A competent Laravel developer gets a working filter in hours, not days. The real cost is verification, not construction: confirming the installed Nova major matches the package's composer.json constraints, confirming the apply() signature (NovaRequest vs. the older Request — a mismatch is an immediate fatal), and confirming the frontend component actually mounts after asset publishing. Feasibility is high; certified feasibility requires a staging spike against the exact Nova/Laravel/PHP/driver matrix you deploy.

Technical risk. Two distinct risk classes, and they should be tracked separately.

• Dependency risk. 11 stars, 0 dependents, a single release dated 2023-04-01, community support only, no SLA. Assume limited upstream maintenance and plan accordingly. This is acceptable for an internal admin filter with a small blast radius; it would not be acceptable for anything customer-facing or revenue-adjacent.
• Usage risk. The package supplies the input; the query semantics are yours. The recurring failure patterns are well documented: blank input degenerating into LIKE '%%' full-table scans, unescaped %/_ in user input silently broadening matches, ungrouped orWhere clauses OR-ing past authorization scopes and soft deletes, driver-dependent case sensitivity (MySQL _ci collation vs. Postgres LIKE/ILIKE), and leading-wildcard LIKE being unable to use a B-tree index. Every one of these is preventable with a shared internal base class — which is the single highest-leverage decision in this assessment.

Key questions.

1. What Nova major is installed, and does the package constraint admit it? What does the base class declare for apply()?
2. Which database driver and collation run in production? MySQL-developed filters behave differently on Postgres.
3. Which resources and lenses get the filter, and what are their current row counts? What threshold triggers graduation to indexed/full-text search?
4. Who is the named internal owner of this dependency, and what is the pre-agreed trigger to vendor, fork, or replace it with a ~30-line in-house filter?
5. Does the asset publish step (nova-text-filter-assets / nova:publish) exist in the deploy pipeline, and is public/vendor/ artifact handling covered?
6. Is this additive, or does it replace an existing custom filter that needs parallel-run comparison?

Integration Approach

Stack fit. Laravel + Nova only; if the admin surface isn't Nova, this package provides nothing and the assessment ends. The fit is strongest where the team already extends Nova filters and has a place to put shared filter base classes (App\Nova\Filters). The package's own surface should stay small: one internal abstract class, concrete filters of a few lines each, and no logic in the package subclass itself.

Migration path. Where no filter exists today, adoption is purely additive — no data migration, no schema change, no backfill, no user-facing cutover. Where it replaces existing custom filter classes, treat it as a behavior change: run old and new in parallel in staging, diff result sets on representative records, and compare query plans before switching. The absence of a migration burden is precisely why this is a low-cost probe rather than a project.

Compatibility. Verify, don't assume. Pin the exact package version, commit composer.lock, and re-run the spike against the deployed matrix. Three concrete checks: (a) the apply() signature against the installed Nova major; (b) the component property on the base class against what actually compiles into public/vendor/ after a Nova upgrade; (c) case-sensitivity behavior settled once in the base class against the production driver, not the developer's local MySQL.

Sequencing.

1. Spike (1 resource, internal, modest table). Install, generate a filter, reparent, register, confirm the input mounts, blank input returns unfiltered results, and query plans are acceptable on production-like data.
2. Build the internal base class. Blank short-circuit, addcslashes escaping (with explicit ESCAPE where the driver requires it), grouped orWhere closure for multi-column matches, and a match-mode hook (contains / starts / exact) so semantics aren't hardcoded per filter.
3. Validate resource and lens registration. Lens screens are where component resolution most often breaks; catching that in staging rather than after rollout is the point of this step.
4. Instrument usage. Nova filter/action event hooks or a lightweight log on the index request. Usage data is what converts this from "installed" to "justified."
5. Decide gate. Measured usage → greenlight broader rollout or graduate to faceted/saved views/external search. No usage → stop, having spent roughly a day.
6. Add Nova upgrades to the revalidation checklist. This is a standing obligation, not a one-time step.

Operational Impact

Maintenance. Low volume, non-zero obligation. The package is stable but unmaintained-by-default; the internal base class is the real asset and the real maintenance surface. Name an owner in the decision record, note the license, and define the fork-or-replace trigger in advance. Mitigation cost is genuinely small — the replacement is a small in-house Nova filter — so the governance burden should be proportionate, not ceremonial.

Support. Community only, no vendor escalation path. Support therefore resolves internally by design, which is acceptable here precisely because the abstraction layer sits in your codebase. The knowledge concentration risk (one developer understanding the apply()/component coupling) should be addressed by keeping the base class small and reviewed.

Scaling. This is the binding constraint and a design decision, not a tuning exercise. Leading-wildcard LIKE cannot use a B-tree index, so the filter belongs on modest admin tables. Agree the row-count threshold before rollout and document which resources are permitted to use it. When volume grows, keep the identical TextFilter UI and route the query inside apply() to Scout, Meilisearch, or Postgres full-text — the UI contract survives the backend swap, which is what makes this a safe first step rather than a dead end.

Failure modes and detection.

Ramp-up. Developer onboarding is measured in hours: the package is small, the README plus the abstract class in src/ answer the three questions you can't safely guess (component name, apply() signature, matching hooks). The actual learning curve is the gotcha list above, which is why it should live in the internal base class and its docblock rather than in individual filters or tribal knowledge. Frame the whole adoption to stakeholders as internal productivity tooling with a bounded blast radius — an admin-panel filter, not a search roadmap — and it stays correctly scoped against customer-facing priorities.