Filament Signature Pad Laravel Package

Technical Evaluation

Architecture fit. This is a presentation-layer plugin: a single Filament form field that wraps a client-side canvas (Alpine component around a signature_pad-style JS library) and persists the result as a base64-encoded image payload on the form state. It sits at the leaf of the dependency graph — nothing in our codebase would depend on it, and it depends only on Filament/Livewire. That is the ideal shape for an optional capability: near-zero architectural coupling, near-zero removal cost. It contributes no domain logic, no models, no migrations, and no service provider surface beyond field registration, so it does not constrain how we model signatures in our own domain — which is where the real design decisions live.

Integration feasibility. Mechanically trivial: composer require, one field call in a form schema, one column on the model. Realistically a half-day spike. The non-trivial work is the persistence decision, which the package does not make for us: the field hands back a base64 data URL, and where that lands (a longText column vs. a disk-backed file with a path/hash in the DB) is an architecture call with long-tail consequences for exports, backups, replication, and storage cost. Treat the package as a UI component and own the storage layer ourselves.

Technical risk. Four risks, in descending order of importance to a TPM:

1. Compliance risk (not a package risk). A signature-pad image is not an e-signature. It is a bitmap that satisfies "wet-ink-looking artifact" and nothing more. If any workflow using it has legal or audit weight (contracts, consent, clinical, financial authorization), we must supply the surrounding evidence ourselves: signer identity, timestamp, IP/user-agent, document hash, version of the terms signed, and immutability/retention. The package addresses none of this. This is the single largest hidden cost and it will be discovered late if not scoped now.
2. Upstream lifecycle risk. 77 stars, 0 dependents, single small-agency maintainer, last release 2024-10-02. Zero dependents means no community validation and no peer pressure on the maintainer to keep pace — most critically with Filament's major-version cadence (v3 → v4). A Filament major upgrade is a hard break for third-party field plugins, and we should assume we may need to fork. MIT license makes forking viable; the code surface is small enough that a fork is hours, not weeks.
3. Payload/storage risk. Base64 in a text column inflates rows ~33% over raw bytes and typically lands 10–50 KB per signature depending on canvas size and pressure data. That breaks naive CSV/JSON exports, bloats DB backups, and slows replication. This is a foreseeable, avoidable mistake — design against it up front.
4. Fidelity risk. Canvas capture on high-DPI/mobile is a known source of blank or misaligned output; touch-scroll vs. draw conflicts inside scrollable forms, and behavior inside repeaters, wizards, and modals (nested Livewire components) are untested territory for a low-adoption plugin.

Key questions (to close before committing):

• Which Filament major versions are declared in composer.json, and is the field registered via the v3 plugin/schema API? Is there an open branch or issue for Filament v4?
• Does the field expose a hook to persist to disk (a saveUploadedFileUsing-style or dehydrateStateUsing path), or is base64-on-the-model the only supported output?
• Is there client-side trimming/downscaling of the canvas, or do we get whatever the device produced?
• What validation does the field support — required, minimum stroke count / non-blank check? Can it distinguish "drew nothing" from "cleared"?
• Does it behave correctly inside Repeater, Wizard, and modal actions? Any known Livewire payload issues at scale?
• Accessibility posture: is there any keyboard/pointer-alternative path, or is this mouse/touch-only (a WCAG exposure we'd inherit)?
• Are there tests, a CI matrix, and a stated support window? What is the maintainer's response latency on issues?
• Does the emitted payload include pressure/timing vector data, or only a rasterized PNG? (Vector data is materially better for legal-weight evidence.)

Integration Approach

Stack fit. Native to the TALL stack: Laravel 10/11, PHP 8.1+, Livewire 3, Alpine, Tailwind, Filament 3.x. No build-step changes, no new frontend toolchain, no separate asset pipeline beyond Filament's standard asset publishing. It will not disturb our existing panel configuration.

Migration path. Assume the package ships no migrations and we own the schema entirely. Recommended target — do not default to a base64 column:

• A dedicated signatures table (or polymorphic signatures relation) holding: path on a private disk, mime, bytes, sha256, signer_id, signed_at, ip, user_agent, document_hash, plus a nullable signable morph for reuse across workflows.
• Use the field's dehydrate/state hook to decode the data URL once, write the binary to disk, and store the path. Strip the base64 from the model attribute before save so it never enters the DB or an export.
• Serve signatures through a signed/authorized route, not a public disk — signatures are personally identifying artifacts.

If the package cannot be made to do the disk handoff cleanly, wrap it: a thin internal SignatureField that composes the vendor field and normalizes output. That wrapper is also our upgrade firewall.

Compatibility. Pin the Filament minor version and add this package to the dependency-review checklist at every Filament major bump. Verify PHP/Laravel constraints in composer.json against our runtime before the spike, and confirm the field renders under Livewire 3's component model rather than a legacy Livewire 2 pattern.

Sequencing.

1. Timeboxed spike (1–2 days) — one internal-only form, verify capture, save, re-render/edit, and the Filament version we actually run. Exit criteria: a persisted signature we can retrieve and display.
2. Storage decision — implement the signatures table + disk handoff + private route. This is the real deliverable; the field is incidental.
3. Internal wrapper field — 1 day of insulation. Gate decision here: if Filament v4 support is absent or the field's API is too rigid for the disk handoff, fork (MIT permits it; small surface area) rather than wait.
4. Pilot on one real workflow — pick the lowest-stakes, highest-visibility workflow (contractor onboarding acknowledgment, equipment check-out) and run a full device matrix: iOS Safari, Android Chrome, iPad, desktop, plus a scrollable/modal context.
5. Broaden — only after audit trail, retention policy, and export handling are in place. Do not roll out to legally-weighted workflows before step 4's evidence story is signed off by whoever owns compliance.

Operational Impact

Maintenance. Small runtime surface (one PHP field class + a JS asset), so ongoing engineering cost is low — but vendor risk is elevated and concentrated in one maintainer. Mitigations: pin the version, keep the wrapper, keep a fork-ready posture, and schedule a compatibility check against every Filament major and every Laravel minor. Budget a recurring half-day per upgrade cycle, not a one-time integration.

Support. Upstream support is effectively "GitHub issues, best effort, one small agency." Do not build a support plan that depends on upstream responsiveness. Internal ownership is the assumption: we diagnose, we patch, we fork if needed. Route any production defect through our own backlog, with upstream notification as a courtesy rather than a dependency.

Scaling. Compute impact is nil — capture is client-side, persistence is one write per submission. The scaling axis is storage and evidence retention, not throughput. Rough sizing: at ~30 KB of trimmed PNG per signature, 100k signatures ≈ 3 GB; add the audit metadata and it's still modest, but it grows monotonically and is never deleted without a retention policy. Plan for: trimming/downscaling before write, rejecting blank canvases so we don't accumulate empty artifacts, and a defined retention/legal-hold policy. If signatures are stored in-DB instead, the same volume lands in your primary database and every backup and replica — that's the failure mode to avoid.

Failure modes to instrument and test.

• Silent blank capture — form submits successfully with an empty signature. Highest-severity, lowest-visibility failure. Require server-side non-blank validation and a non-null constraint on the persisted path.
• Payload rejection — canvas output exceeds post_max_size, nginx client_max_body_size, or Livewire's request payload limits; presents as a generic 413/419/500 with no user-facing explanation.
• Export corruption — base64 or binary leaking into CSV/JSON exports; must be prevented at the storage layer, not patched per-exporter.
• Device fidelity — blank or offset strokes on high-DPI screens, or touch-scroll hijacking the canvas inside long forms; caught only by the device matrix.
• Container context — field failing inside repeaters, wizards, or modals, where multiple canvas instances coexist.
• Lost evidence — file written but DB row rolled back, or vice versa. Write the file after the DB commit, or reconcile with a job.

Ramp-up. A mid-level Laravel/Filament developer is productive in half a day; the wrapper and storage layer add maybe one more. The real ramp-up is QA and compliance, not engineering: one day for the device/browser matrix, and a separate review with the compliance or legal owner to determine whether the captured artifact plus our metadata satisfies the standard for each workflow we intend to use it in. Budget that conversation early — it determines scope far more than any technical detail of the package.