Filament Google Map Location Picker Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament form field for the TALL stack (Livewire + Alpine + Blade) that wraps the Google Maps JS API and writes a picked coordinate back into form state. Server-side footprint is essentially nil: no migrations, no service layer, no queue work — one Blade view, one Alpine component, and asset registration in a service provider. That shallow integration is good for reversibility and bad for leverage: the whole product is a few hundred lines of front-end code, so the dependency buys very little you couldn't own outright.

Integration feasibility. Technically straightforward, but the last release is 2022-11-05, which predates Filament v3 (and v4). Filament's v3 rewrite changed custom-field APIs — asset registration, component/view resolution, form state handling — so assume incompatibility with v3+ until proven otherwise in a spike. Treat "compatible with our Filament major version" as the first gate, not an assumption.

Technical risk.

• Lifecycle, not security. Single-maintainer org, 0 dependents, ~3 years without a release, no community. This is an unmaintained reference implementation, not a supported dependency. Supply chain itself is benign (minimal transitive deps; third-party JS comes from Google's CDN).
• Google Maps Platform is the real coupling. API key governance, billing account ownership, SKU pricing, and ToS all sit outside the package. Google's 2025 move to per-SKU free tiers means the cost model must be re-verified against current pricing rather than assumed.
• Key exposure. Any Maps JS key ships to the browser. It must be HTTP-referrer- and API-restricted with per-key quotas; on a public, unauthenticated form this is a direct billing abuse vector.
• Silent state loss. Marker position lives in Alpine and must entangle into Livewire state. A missed path yields a null coordinate that saves cleanly — the worst failure class here.
• Privacy. Tile loads transmit end-user IP to Google, and address/geolocation is personal data under GDPR. Fine for internal admin; needs review before any public surface.

Key questions.

1. Which Filament major version is the target, and is v2 a hard constraint anywhere in the estate?
2. Is Google a fixed requirement, or is a cost/privacy-motivated swap (Leaflet/OSM/Mapbox) acceptable?
3. Who owns the GCP project, key restrictions, and budget alerts?
4. Is click-to-pick sufficient, or do we need Places autocomplete, reverse geocoding, or drawing tools?
5. Storage shape: two numeric columns, JSON, or PostGIS geography (which fixes precision and enables radius queries later)?
6. Does this ever render on an unauthenticated page?

Verdict. Capability value ~7/10; package-as-dependency ~4.5/10. Buy the pattern, not the package.

Integration Approach

Stack fit. Comfortable only on Laravel 9/10 + Filament v2 + Livewire v2, with PHP constraints from the 8.0/8.1 era. On Filament v3/v4 + Livewire v3 this is a starting point for a fork, not a drop-in. Also verify Alpine version assumptions — Filament v3 ships Alpine v3.

Migration path, ranked.

1. In-house field (recommended). Build a LocationPicker field: Blade view + Alpine, FilamentAsset::register() for Maps JS, companion state fields, explicit lat/lng validation rules. 2–4 senior-dev days including tests. Eliminates lifecycle risk and lets you shape the API to the domain.
2. Adopt-and-wrap. Install on v2 but reference the package class in exactly one adapter field under app/Filament/Fields/. Swapping implementation later becomes a one-file change.
3. Fork-and-upgrade. Port asset registration and view resolution to v3/v4 — 1–3 days, plus a permanent maintenance obligation you have just adopted.
4. Vetted alternative. Evaluate maintained pickers (e.g. dotswan/filament-map-picker, cheesegrits/filament-google-maps) on v3/v4 support, release cadence, and issue responsiveness. Stars are not maintenance.

Compatibility checks. CSP must allow Google Maps across script-src, img-src, and connect-src; confirm config caching doesn't drop the API key; confirm the field survives modal open/close re-renders without duplicating map instances.

Sequencing.

1. Gate 0 — compatibility spike (0.5 day). Install in a throwaway branch of the real app, render, pick, save. Kill the package here if it fails.
2. Platform prerequisites. GCP project, Maps JS + Places enabled, referrer- and API-restricted key, budget alerts, .env plumbing.
3. Domain decision. Storage shape and validation rules before UI work; migrate any existing coordinates.
4. Field abstraction. One wrapper class, one view, one JS entry point; no package references elsewhere.
5. QA matrix. Desktop and mobile touch, keyboard-only, null/partial state, validation failures, re-render teardown.
6. Rollout behind a flag, lazy-loading Maps JS behind a "pick on map" toggle rather than on every form render.

Operational Impact

Maintenance. Effectively zero upstream. Budget for it as a vendored component: pin the exact version, audit on every Composer update, and assume you own each future Filament upgrade. That ownership cost is why in-house usually wins on total cost of ownership past twelve months.

Support. No maintainer SLA, no issue triage, no peer knowledge base at 0 dependents. Internal support rests on whoever writes the wrapper — document the key-rotation runbook and the "map won't load" triage path.

Scaling. Two axes. Cost scales with form renders, not users: every admin form open that mounts the map is a billable Dynamic Maps load, linear in admin activity and invisible until the invoice. Mitigate with lazy-load-on-toggle and a hard budget alert. Payload is the second axis: Maps JS is heavy and will degrade admin time-to-interactive if registered globally.

Failure modes.

• Maps JS blocked (key restriction, quota, CSP, offline) → blank field, blocked submit. Mitigate with a manual lat/lng fallback and non-blocking validation.
• State desync → silent null coordinates. Validate server-side and fail loudly.
• Marker drift against reverse-geocoded address → treat coordinates as authoritative, address as derived.
• Orphaned map instances after Livewire re-render → explicit teardown on destroy, mount guard.
• Key abuse → referrer restriction plus per-key quota, with spike alerting.
• Precision loss on cast → pin storage explicitly, e.g. decimal(10,7).

Ramp-up. A Filament-fluent dev is productive on the field in under a day. The slow work is cross-functional: GCP and billing ownership with platform ops, CSP changes with security, and privacy review if the field ever reaches an unauthenticated surface. Plan a week end-to-end including approvals.

Decision. Approve a two-day spike on Filament v2 to extract the pattern; do not adopt it as a long-lived dependency. If the target is Filament v3+, skip to an in-house field or a vetted, actively maintained alternative.