Nova Google Polygon Laravel Package

Technical Evaluation

Architecture fit yieldstudio/nova-google-polygon is a single-purpose Laravel Nova custom field: a PHP Field subclass that renders a Vue component wrapping the Google Maps JavaScript API polygon drawing tools, and persists the resulting geometry (typically a GeoJSON Polygon/MultiPolygon coordinate array) into a JSON or text column on the underlying Eloquent model. It fits cleanly only in the narrow intersection of: (a) a Laravel app running Nova, (b) an admin-only workflow where a human draws or adjusts a boundary, and (c) an organisation already holding a Google Maps Platform billing account. It is not a geo-querying library — it does not do spatial indexing, PostGIS, or point-in-polygon lookups. Any spatial logic (intersections, containment, area) has to be built separately on top of the stored payload.

Integration feasibility Mechanically the integration is trivial: composer require, register the field on a Nova resource, ensure the package's compiled assets are published, and supply a Maps JS API key. A competent Laravel developer can have it rendering in a form in under a day. The friction is entirely around the edges: the API key must be provisioned, restricted by HTTP referrer, and enabled for the right Maps APIs; the field must be validated (it will happily accept null or malformed geometry); and detail/index views need a decision because a raw coordinate array is meaningless in a table.

Technical risk This is the dominant concern. The repository is archived, with the last release in July 2023 — before Nova 5 — and zero dependents and 5 stars, meaning effectively no community validation and no external bug reports to learn from. The score of 0.1475 reflects that abandonment, not necessarily code quality. Concretely:

• Nova version lock. Nova 5 changed field/asset build conventions (Vite replacing Laravel Mix patterns). The package's nova.mix.js-style asset pipeline may not compile, and the field mixins may not resolve. This is the most likely first failure.
• Upstream abandonment. No security patches, no Google Maps API deprecation fixes. Google's Maps JS API has moved to AdvancedMarkerElement and periodically retires legacy classes; polygon rendering has been stable, but there is no one to ship a fix if that changes.
• Credential surface. A Maps JS key is by definition exposed client-side. It must be referrer-restricted and quota-capped, or it becomes a billing liability.
• Data contract undocumented. You will need to read the Vue component to confirm the exact serialisation; nothing guarantees stability across a fork.

Key questions

1. Which Nova major version are we on today, and what is the upgrade horizon to Nova 5?
2. What exactly is persisted — GeoJSON, a Google Polygon literal, or raw lat/lng arrays — and does our downstream reporting consume it?
3. Do we already hold a Google Maps Platform account, or would this create one for a single admin field?
4. Do we need read-only display, index-column rendering, multi-polygon, or hole support? The package's coverage of these is unverified.
5. Is this a throwaway internal tool or a long-lived product surface? The answer determines fork-versus-replace.

Integration Approach

Stack fit Adopt only if the stack is Laravel + Nova and the team is comfortable owning a fork. The opportunity score of 7.59 against 5 stars is the interesting signal: the geo-field gap in the Nova ecosystem is real, but the market for paid Nova add-ons is small enough that maintainers churn. Treat this repository as a high-quality reference implementation rather than a dependency.

Migration path Do not install it as a composer require from Packagist for anything beyond a spike. The correct path is:

1. Fork into the organisation's namespace (acme/nova-google-polygon) under MIT, which is what the licence is for.
2. Rebuild the asset pipeline against the target Nova version (Vite for Nova 5).
3. Add the validation rules the original omits — geometry presence, coordinate bounds, max vertex count.
4. Publish an internal tag and pin it.

The alternative is replacement: a Leaflet or Mapbox GL field, or a bespoke Nova field if the requirement is narrow. Choose replacement if we do not already have Google Maps Platform in the estate — standing up a Cloud billing account, API enablement, key rotation, and quota alerting for one admin form is disproportionate operational overhead compared with a self-hosted tile solution.

Compatibility Assumed baseline is PHP 8.x, Laravel 9/10, Nova 4.x. Verify explicitly against the app's Nova version before committing; if the app is on Nova 5, budget for asset-toolchain rework rather than assuming a drop-in. Also confirm the DB column type can hold the largest expected geometry — JSON is fine, TEXT is safer, and if polygons exceed a few thousand vertices, revisit the storage choice entirely.

Sequencing

1. Spike (1–2 days): install in a sandbox, render a field, save and reload a polygon, inspect the persisted payload. Confirm it works on the current Nova version before anything else.
2. Decision gate: fork-and-own vs. replace, based on spike output and whether Google Maps Platform already exists internally.
3. Fork hardening: asset rebuild, validation, read-only/detail rendering, docs on the stored format.
4. Pilot: one resource, one team, defined rollback (field is additive; removing it leaves orphaned JSON data, so confirm a data-retention position).
5. Rollout only after the pilot survives a Nova upgrade rehearsal.

Operational Impact

Maintenance Adoption converts a "free" package into an owned asset. Assume 10–20% of one engineer's time in the first quarter for the fork, then a low but non-zero trickle tied to Nova upgrades and Google Maps API changes. The archived upstream guarantees zero inbound fixes; every CVE or deprecation is ours. The MIT licence makes this legal and clean — the constraint is engineering capacity, not IP.

Support No upstream support channel, no issue triage, no maintainer responsiveness. Internal ownership must be explicit: a named code owner, a README documenting the stored format and the API key configuration, and a runbook for "the polygon field is blank." Without that, this becomes tribal knowledge concentrated in whichever developer did the spike.

Scaling The field is admin-facing, so request volume is negligible. The scaling concerns are data-shaped: JSON geometry grows with vertex count, and large polygons inflate every resource index/detail payload if the column is eagerly selected. Watch for a handful of pathological records dominating table reads. Client-side rendering cost rises with vertex count and with multiple polygons per map. None of this is a blocker for typical administrative boundaries; all of it is a problem if the field is used to trace high-resolution coastlines.

Failure modes

• Silent blank field when the API key is absent, referrer-restricted incorrectly, or the Maps JS API is not enabled on the project. Fails closed and quietly — needs a startup/liveness check and an explicit error state in the forked component.
• Quota exhaustion or billing suspension on the Maps Platform project breaks the field for all users simultaneously, with no relationship to application health monitoring. Must be wired into the same alerting as any other third-party dependency.
• Nova upgrade breakage at the asset-compile or mixin level; usually caught in staging but only if a Nova upgrade rehearsal is on the release checklist.
• Geometry corruption when a user abandons an in-progress draw or the map container fails to initialise — no validation layer exists upstream to catch a partial payload.
• No spatial correctness guarantee: self-intersecting or degenerate polygons will be stored without complaint.

Ramp-up Low for anyone with Laravel/Nova experience — the package is small, one field class plus one Vue component, and reading it end-to-end takes an hour or two. The non-obvious skills are Google Maps Platform administration (key restriction, API enablement, quota/billing alerts) and whatever downstream consumer reads the geometry. Budget a short written handover rather than assuming the spike developer is permanently available.