Nova Google Autocomplete Laravel Package

Technical Evaluation

Architecture fit. The package is a single Laravel Nova field class (YieldStudio\NovaGoogleAutocomplete\NovaGoogleAutocomplete) that wraps the Google Places JavaScript autocomplete widget and writes the selected formatted address onto one model attribute. Architecturally it is additive, not invasive: it touches the Nova form layer only, requires no migrations of its own, no service provider bootstrapping beyond registration, and no changes to application domain code. From a TPM's perspective, this is the cheapest possible integration shape — a one-line field declaration in a fields() method — which means the decision cost is almost entirely about supply risk and API ownership, not engineering effort. The fit is good if and only if the product requirement is "address capture inside Nova admin forms." It is not a fit for public-facing checkout, address verification, geocoding, or structured component extraction without forking.

Integration feasibility. Feasible in an afternoon for a spike: composer require yieldstudio/nova-google-autocomplete:^1.3, publish config/assets, add a Google Places key to config/services.php, declare the field, save a record. The real feasibility question for a TPM is not "can we wire it" but "do we have an owner for a Google Cloud billing account, per-environment restricted keys, quota caps, and a CSP exception for https://maps.googleapis.com?" Those are cross-team work items — finance/cloud ops, security, and platform — that typically take longer than the code. Budget the calendar time there, not in the field declaration.

Technical risk. Concentrated in five places, and a TPM should track each explicitly:

1. Supply position — high. Repository is archived, last release 2023-08-16, 12 stars, 0 dependents, scored 0.42. There will be no upstream Nova 5 / PHP 9 compatibility fix. Adoption is a freeze-in-time commitment.
2. Licence — unresolved. NOASSERTION means GitHub cannot identify the licence file. This is a legal gate before merge into any shared repo, not a technical detail.
3. Silent failure modes — medium. Missing or stale compiled JS, a lapsed API key, exhausted quota, or a strict CSP all produce the same outcome: the field renders and saves free text with no suggestions and no error. Data quality degrades invisibly.
4. Behavioural edge cases — medium-low. dontStore() explicitly breaks the address preview and clear control (documented in 1.3.0 notes). Clear semantics (null vs '' vs no-op) are undocumented and need empirical verification because downstream whereNull, unique, and exports care.
5. Mapping claims — unverified. The "maps street, city, postal code, country onto model attributes" claim is the thing most worth proving on real international addresses before any reporting or export depends on it.

Key questions to resolve before commitment.

• Who owns the Google Cloud project, the billing relationship, and the per-key quota/budget alerts?
• Has legal cleared the NOASSERTION licence for use in our repo, and for redistribution if we fork?
• Do we adopt pinned-as-vendored, or fork the field class into App\Nova\Fields on day one? (Recommendation: fork if more than one resource uses it.)
• Which single low-risk resource is the pilot, and what is the rollback?
• Does our CSP allow maps.googleapis.com in script-src and connect-src in every environment?
• What is the named review trigger that forces a re-evaluation — next Nova major, PHP major, or a blocking bug?

Integration Approach

Stack fit. Correct target stack is Laravel + Nova with a browser-side Google Places key and one nullable address string column. The package assumes Nova conventions (nova:publish, field assets, fields(Request $request)), so it will not port to Filament, Livewire, or a custom admin panel. If the admin surface is anything other than Nova, this package is out of scope and the equivalent is a direct Places API integration with our own error handling and caching.

Migration path. None required — this is a net-new field on existing resources, not a replacement. The only data migration is retroactive: pre-existing free-typed addresses are not backfilled or validated. Sequence the work as:

1. Legal/licence review of NOASSERTION (gate, parallel).
2. Google Cloud project, restricted key per environment, quota caps, budget alert (gate, parallel).
3. Spike in staging: install, publish, add field to a Venue-style resource, save a real suggestion, dd() the model to see exactly which attribute receives what. This spike is the decision point — it answers the mapping question empirically before design commits to one column or five.
4. Fork or pin decision, and write it down.
5. Pilot on one internal resource with one nullable column and operator-facing ->help() text stating that free-typed addresses are not saved.
6. Expand resource-by-resource only after the pilot's data quality is measurable.

Compatibility. Do not trust the 2023 composer.json constraint. Install in staging against our exact Nova, Laravel, and PHP versions and exercise the full matrix: render, suggest, select, save, preview, clear, and the dontStore path. Treat any gap as a fork trigger, not a support ticket — there is no upstream to file it with.

Sequencing for structured data. Start with the single formatted-address column. Only add City / Postal Code / Country Text fields if step 3 proved the package actually populates them across international addresses. Do not let reporting requirements be written against structured components before that verification lands.

Fallback design (build into the pilot, not later). Because the field degrades to a plain text input, accept human-typed addresses as a legitimate state server-side, and consider a source column (autocomplete vs manual) so you can later measure whether the field actually improved data quality. Without that flag, the initiative has no success metric.

Testing strategy. Feature tests assert on outcome (record saves and persists), never on the widget. Google Places JS will not load reliably in CI; drive browser tests with a plain type() and assert persistence — which conveniently also covers the degraded path.

Operational Impact

Maintenance and ownership. There is no upstream maintainer. Assign an internal owner at adoption and record the fork trigger conditions (Nova major, PHP major, unfixable bug) in the dependency register. If the field lands on more than one resource, fork the class into App\Nova\Fields\GoogleAutocomplete immediately — the cost is one copy-paste now versus an unplanned blocking composer update later. Pin the exact version either way.

Support surface. Expect operator-reported "it's broken" issues that are actually quota, key restriction, CSP, or stale assets. Pre-empt them: a short internal runbook covering "no suggestions appearing" → check network tab for the Places script, check console for CSP blocks, check key/quota in Google Cloud. Also pre-empt the dontStore() preview/clear limitation by labelling it in the field's help text — otherwise it will be filed as a bug repeatedly, and a future maintainer may "fix" it by silently storing data, which is the worst possible resolution.

Scaling and cost. Google Places bills per keystroke-session, so spend scales with form usage and number of address fields, not with record count. A resource with three address fields multiplies cost. Mitigations to own centrally: per-environment HTTP-referrer-restricted keys, enable only the APIs actually used (Places, not the full Maps suite), per-key quotas, and a project budget alert. An unrestricted browser-side key is simultaneously a cost exposure and an abuse vector — this is a security review item, not an ops nicety.

Failure modes to instrument.

The unifying risk: every failure mode looks like a working text box. Nobody files a bug about a text box. Add a small client-side canary that logs suggestion-request failures so quota exhaustion is discovered in logs rather than in an operator's spreadsheet six weeks later.

Ramp-up. Low for developers (one class, one field declaration; the class is the documentation since the README is thin) and low for operators (type, pick a suggestion). The real ramp-up cost is organisational: cloud billing setup, security review of the browser-side key, legal review of NOASSERTION, and deciding who owns the dependency on an ongoing basis. Estimate a day of engineering for the pilot and one to three weeks of calendar time for the gates.

Bottom line for the roadmap. Safe to absorb as a contained admin convenience on one or two internal resources with an internal owner, a pinned version or fork, a restricted key, and monitoring. Not safe as a platform-level bet, not safe without licence clearance, and not safe to let reporting or exports depend on structured components the package has not been proven to populate. Give it roadmap weight proportional to a utility, not a capability.