Nova Unlayer Field Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin bridge, not a platform: one Nova field class plus a Vue component that embeds the Unlayer editor. Laravel stays the system of record; Unlayer is a composition surface only. That boundary is the right one for a TPM to defend.
• Two persistence artifacts matter, and the TPM should insist on both: rendered HTML (the deliverable that reaches the inbox) and editable design JSON (the re-editable source), plus a schema_version. If neither authoritative copy lives in Unlayer's cloud, vendor lock-in is reversible.
• It extends an existing admin convention (a Nova resource) rather than introducing a new system, so adoption cost is bounded to one resource, one migration, one config entry.
• It deliberately does not solve rendering-to-send, governance, versioning, localization, or hosting. That is architecturally honest — and it is exactly the gap a TPM must assign an owner to before go-live.

Integration feasibility

• Composer-installable, MIT-licensed, small surface. A working field is realistically 1–2 days; a production-safe content authoring capability is 1–2 sprints once render/export, sanitization, permissions, preview/test-send, and the delivery handoff are included. A TPM should scope the estimate to the latter, not the demo.
• Two commercial prerequisites: an existing Nova license and an Unlayer plan. Procurement, security review, and secrets management are part of the plan — the TPM owns the account-ownership and key-management conversation.
• The field solves authoring, not sending. Name an owner for export/render, HTML sanitization, link rewriting, tracking pixel, unsubscribe, and bounce handling before committing.

Technical risk

• Weak adoption signal: ~34 stars, 0 dependents, single-org maintainership, and a release date (2026-07-14) that reads as anomalous. Treat as "adopt with a fork option" and verify against tags rather than trusting the date.
• Dual-vendor coupling compounds: Nova major upgrades (notably Vue 2 → Vue 3 in Nova 4) and Unlayer SDK/API changes are independent break vectors that can land on different schedules.
• Commercial dependency on hosted SaaS: pricing tiers, free-plan watermarking, export API quotas, data residency, and DPA terms are business risks, not code risks — the TPM negotiates and tracks them.
• Rendering fidelity is out of scope: editor preview ≠ inbox rendering. Sanitization and link handling need a named owner or they will surface as production incidents, not tickets.
• Third-party script inside an authenticated admin surface: CSP, iframe sandboxing, and CDN allowlisting must clear security review before content teams depend on the editor.

Key questions

1. Which Nova majors and PHP versions are supported — is Vue 3 (Nova 4+) covered?
2. Which Unlayer plan is required in production (watermark removal, export API, custom fonts, data residency)?
3. Who owns the Unlayer account and API key, and what is the offboarding path if we drop it?
4. Where does rendering happen — sync on save or queued job — and who owns tracking, unsubscribe, and bounce handling downstream?
5. Is schema_version persisted so old content re-renders correctly after an Unlayer editor change?
6. Do we need landing-page hosting/publishing, or is composition enough? This field covers composition only.
7. Is the surface small enough to fork and maintain internally if upstream goes quiet? (Yes — which is also the argument that lock-in here is low.)

Integration Approach

Stack fit

• Strongest fit: a Laravel monolith already running Nova for admin, with an established transactional or marketing send path. The field is additive — one resource, one migration, one config entry.
• Weak fit if the org is not on Nova (buying Nova solely for this is hard to justify), or if authoring already lives in a mature ESP editor (Braze, Customer.io, Mailchimp) — then this is duplicate tooling.
• Assumes some Vue-capable frontend capacity. Teams without it can integrate but cannot patch the component when a Nova upgrade breaks it — which is the most likely break to occur.

Migration path

• Additive and low blast radius: new columns, a new field on a template model or a new Nova resource, a new config key. No destructive migration.
• Do not retrofit existing HTML emails into Unlayer designs as engineering work. That is manual content migration — scope and staff it as content work with a named owner.
• Use a strangler pattern: new templates authored in the field, legacy templates untouched until parity is demonstrated on a representative set.

Compatibility

• Pin the package version. Spike Nova major, PHP version, and Unlayer JS SDK version together before committing.
• Persist schema_version per record so a render is reproducible after an upstream change.
• Confirm the export path works in the target environment — CSP, iframe sandboxing, and CDN allowlisting fail silently and will surface as "the editor is blank."

Sequencing

1. Spike (days): install on a branch, render one email end-to-end in a sandbox, confirm Nova/PHP compatibility and the Unlayer plan needed; open security review in parallel.
2. Data contract: agree the schema (design_json, html, plain_text, schema_version, rendered_at) and decide sync-on-save vs. queued render.
3. Editor UX: wire into one Nova resource; validate autosave, validation rules, preview.
4. Delivery pipeline: connect rendered HTML to the existing send path with link tracking, unsubscribe, and test-send.
5. Hardening: Unlayer-outage handling, HTML sanitization, and a fallback "edit raw HTML" route.
6. Rollout: pilot with one content owner, then widen; gate access on a written runbook.

Operational Impact

Maintenance

• Two upgrade tracks to budget for: Nova majors (re-verify and often re-patch the field) and Unlayer SDK/API changes. Plan a recurring line item each Nova cycle.
• With no community, the realistic operating model is a vendored fork. Assign a named engineering owner; do not assume upstream responsiveness, and treat the future-dated release as unverified until checked against tags.
• Because the code is small, the fork is cheap — record that as the explicit fallback, not a hope.

Support

• Tier 1 (content authors) is internal: editor usage, template structure, broken images and links.
• Tier 2 splits between Unlayer support (editor/export defects) and internal Laravel engineers (field, storage, pipeline). Make that boundary explicit so tickets don't bounce.
• Document account ownership, key rotation, billing escalation, and a communications plan for vendor outages.

Scaling

• Editor load is per-author and negligible; rendering is the scaling concern. Cache rendered HTML, render asynchronously, and never re-render on every send.
• Design JSON storage is trivial per record; version history, if added, dominates. Set a retention policy early.
• Send volume is bounded by the ESP/Laravel mail path, not by this package — the field introduces no send-side scaling risk.

Failure modes

• Unlayer CDN/JS unavailable → blank or erroring field inside Nova; authors blocked. Mitigate with a feature flag and a raw-HTML editing fallback.
• Expired or rotated key → editor loads but export fails silently; stale or unstyled emails ship. Mitigate with a render check and alerting on export failure.
• Nova upgrade → component breaks after a major bump. Mitigate by pinning Nova and scheduling re-verification before the upgrade.
• Schema drift → old design JSON renders differently after an Unlayer change. Mitigate with schema_version and a re-render test against a golden template.
• Silent CSP/sandbox failure → blank editor with no console signal in production. Mitigate by validating in the target environment during the spike, not in staging only.
• Vendor pricing/quota change → export or watermark behavior shifts. Mitigate with contract review and a documented offboarding path.

Ramp-up

• Fast for a small team: one engineer can stand up the field in days; the real ramp is the delivery pipeline and content operations (1–2 sprints).
• Content authors need light training on the Unlayer editor and a short style guide; the drag-and-drop surface is approachable but produces inconsistent output without brand guardrails.
• Keep a written runbook covering key rotation, outage fallback, raw-HTML editing, and the fork procedure so the capability survives maintainer turnover.
• Treat adoption as a reversible bet: export HTML and design JSON, prove value in one sprint, and retain the option to replace the connector without losing content.