Filament Geometry Laravel Package

Technical Evaluation

Architecture fit: swisnl/filament-geometry is a thin Filament form-field plugin that wraps Leaflet/Leaflet.draw to capture and persist geometry (GeoJSON) against an Eloquent model. It is not a GIS platform — it is a UI adapter plus a cast/serialization layer. Fit is therefore narrow and good: if the product need is "let an operator draw a polygon/polyline/point on a map inside an admin panel," this is close to the minimum viable dependency. If the need is spatial querying, tile layers, coordinate systems, or PostGIS-backed search, the package is only the capture surface and the real architecture work sits outside it.

Integration feasibility: High. Installation is composer + Filament plugin registration + a form field schema entry and a model cast. No service, queue, or external API dependency at runtime; no vendor account. The 0.8.1 change — Filament 5.x compatibility — materially improves feasibility for greenfield work, because it removes the main blocker (pinning the admin panel to Filament 4.x). Effort is measured in hours, not sprints, for a single field.

Technical risk: The dominant risk is maturity, not complexity. Pre-1.0 versioning (0.8.x) means the public API and the composer constraint surface can move under us; Filament major-version support in this release is a signal that the maintainer tracks upstream, but it also means the package's own majors may lag Filament's cadence. Secondary risks: client-side dependency on Leaflet/Leaflet.draw (a largely frozen upstream) and the usual CDN/asset-publishing question for a JS-bearing plugin; and storage-format lock-in — if geometry is persisted as raw GeoJSON in a JSON/text column, downstream spatial queries require either a derived column or a PostGIS migration later. Data-loss risk is low (geometry is user-drawn), but malformed/partial geometries and null handling are worth a validation rule.

Key questions:

• Does 0.8.1 add Filament 5 support alongside 4.x, or does the constraint now exclude Filament 4? This determines whether we can adopt before/after our panel upgrade.
• Which Filament major is our target, and is that combination actually covered by the package's CI matrix (not just a composer allow)?
• Where does the geometry get persisted, and what is the query story — JSON column read-and-parse, or a spatial index?
• Is Leaflet.draw still the drawing engine, and does that constrain us on mobile/touch or accessibility requirements?
• What is the maintainer's release cadence and bus factor (single-maintainer risk)?
• Do we need coordinate-system reprojection, and if so, is that ours to build?

Integration Approach

Stack fit: Requires PHP 8.x, Laravel, Filament (4.x or 5.x per the constraint), Livewire, and Node/npm for asset publishing. It sits entirely inside the admin panel layer — no impact on the public application, API, or domain model beyond the cast attribute. That containment is the main integration virtue: it can be adopted, isolated, or removed without touching core business logic.

Migration path: Two distinct paths. (a) Net-new field: additive, non-breaking, ship behind a feature flag on one resource first. (b) Replacing an existing free-text lat/lng pair or a hand-rolled map widget: this is a data migration — you need a backfill that converts stored coordinates to the package's expected geometry shape, plus a dual-read or shadow-write period so records created before the switch remain editable. Treat (b) as a small project with its own rollback, not as a composer update.

Compatibility: Filament major version is the binding constraint and should be pinned explicitly in composer.json rather than inherited transitively, so a future composer update cannot silently cross a Filament major. Verify the 0.8.1 constraint against our actual installed Filament version before committing. Leaflet/Leaflet.draw versions and the asset-publish step are the second compatibility surface — confirm how assets are served in our deploy (published to public/ vs. Vite) so we do not ship a field that renders an empty div in production. Also confirm Livewire version alignment, since the field participates in the Livewire component lifecycle.

Sequencing:

1. Spike: install 0.8.1 in a scratch branch against our real Filament version; render the field, draw, save, reload, edit.
2. Decide storage shape and add validation (geometry type allowlist, coordinate bounds, required/nullable).
3. Ship on one low-traffic resource behind a flag; confirm asset pipeline in staging.
4. Resolve the query story (derived column or read-time parse) before any reporting depends on the data.
5. Only then migrate legacy coordinate data.
6. Document the pinned Filament constraint and the upgrade ritual for future Filament majors.

Operational Impact

Maintenance: Low ongoing cost, but non-zero ownership. We own the pinned version, the asset-publish step, and any wrapper code (custom validation, casts, resource configuration). We do not own Leaflet. Budget a small recurring allowance to track upstream Filament majors — this release is exactly that kind of event, and it will recur roughly on Filament's cadence. The Leaflet.draw layer is a slow-moving dependency that will eventually need a decision (accept, replace, or fork).

Support: Internal support surface is small: "the map doesn't render," "my drawing didn't save," "I can't edit an old record." Each maps to a known cause — asset pipeline, validation/JS error, or data-shape mismatch from a legacy record. Worth a short runbook and one saved example. Vendor support is community/GitHub-issue only; there is no SLA, which is acceptable for an admin-panel convenience feature and unacceptable if geometry capture ever becomes a revenue-critical or compliance-critical workflow.

Scaling: Negligible server-side scaling impact — it is a form field; load is bounded by admin concurrency, not end users. Two scale-adjacent caveats: geometry payloads make rows larger and can bloat admin queries if the column is selected broadly (exclude it from list/table queries); and any spatial querying requirement will outgrow the package's storage model and force a PostGIS or derived-index decision. Client-side, large/complex geometries (many vertices) can degrade Livewire round-trips — cap vertex count via validation if users draw freely.

Failure modes:

• Filament major bump without a package release → plugin breaks or is silently excluded by composer; mitigation: pinned constraints plus a smoke test on every panel upgrade.
• Assets not published / Vite misconfiguration → field renders empty in production while working locally; mitigation: staging verification step, and a rendering assertion in the smoke test.
• Invalid or partial geometry saved (self-intersecting polygon, single-point line) → downstream consumers choke; mitigation: server-side validation, not just client-side.
• Legacy records with pre-migration data shape → edit screen throws; mitigation: backfill + a read-path guard.
• Silent data loss on edit of an existing geometry (field initializes empty) → operator overwrites a valid polygon; mitigation: explicit test for the load-then-save round trip.
• Package abandonment → contained blast radius; mitigation: the field is isolated behind one form component, so replacement is scoped, not architectural.

Ramp-up: Effectively immediate for a Laravel/Filament-fluent developer — a few hours to a working field, under a day including validation and tests. The learning curve is not the package; it is the surrounding decisions (storage format, query strategy, validation rules) that a less experienced developer is likely to skip. Recommend one person own those decisions explicitly rather than letting them accrete. No specialist GIS knowledge required at this scope — and that is precisely the limit of the tool: the moment GIS knowledge is required, this package stops being the answer.