Filament Architect Laravel Package

Technical Evaluation

Architecture fit. wotz/filament-architect is a form-field extension for Filament's Builder component — a drop-in replacement or subclass that adds authoring capabilities on top of Filament's existing block-composition primitive. It introduces no new runtime services, queues, storage backends, or external dependencies. Architecturally this is the cheapest possible integration shape for a Laravel/TALL stack: one Composer package, one field class swapped into a resource schema, and a JSON column that already exists in the Builder pattern. Fit is therefore high if and only if the application is already a Filament application.

Integration feasibility. Mechanically trivial: composer require, publish assets/config if required, replace Builder::make('content') with the architect field, and define block schemas as today. Effort is measured in hours, not sprints. The real feasibility question is not "can we install it" but "can we safely depend on it," and the adoption signals are poor: 2 stars, 0 dependents, no downstream projects to inherit bug reports from.

Technical risk. Four risks dominate, in descending order:

1. Data-shape lock-in (highest). The package's value is its serialized JSON contract. Once editors author content through it, that JSON is a production content schema. Extracting from it later costs far more than the integration saved. This risk is independent of code quality.
2. Coupling to Filament internals. Builder is among Filament's most complex form components and its internals shift across Filament majors (v3 → v4). An "extended Builder" is by definition a subclass or a heavy override, so minor-version churn can break it in ways that are not covered by the package's own tests — if tests exist.
3. Bus factor of one. Single maintainer, no dependents, single recent tag. The release record is not corroborated by any adoption signal, so version cadence tells us nothing about stability. Plan for the package to become unmaintained at any point.
4. Content trust boundary. Block-based authoring frequently implies rich text, HTML, or Blade fragments and embedded uploads. If the field renders author-supplied markup without sanitization, that is a stored-XSS path with an editorial account as the vector — a risk the package's low visibility means nobody has audited.

Key questions before committing.

• Which Filament major versions are supported, and what is the composer.json constraint on filament/filament and illuminate/support? Does a v4 branch exist?
• What exactly does it add over stock Builder — nesting, block presets/templates, drag handles, per-block previews, cross-resource block libraries? Is any of that on our roadmap, or are we paying lock-in for cosmetics?
• Is the serialized JSON shape documented and stable, and does it carry a schema version key?
• Are block definitions code-declared only, or can they be DB-driven? (DB-driven blocks turn an editor feature into a migration surface.)
• Does it degrade to plain Builder output, or is the payload proprietary?
• Test coverage, CI matrix, and issue responsiveness on the upstream repo.
• Sanitization behavior for rich content and handling of uploads inside blocks.

Integration Approach

Stack fit. Laravel + Filament + Livewire + Alpine, no new infrastructure. The only persistent footprint is a JSON/longText column. That scores well on operational simplicity and poorly on reversibility.

Compatibility. Pin the package to an exact version, not a caret range, and pin filament/filament alongside it. Run CI against both the lowest and highest Filament versions in the declared constraint — this is the single cheapest early-warning mechanism for the internals-coupling risk. Verify the PHP and Laravel version matrix matches the host application before the spike, not after.

Migration path. Do not let the vendor class appear anywhere but one file.

• Introduce an internal ContentBlocks field factory (or a thin subclass) that returns the architect field. All resources call ours; exactly one file imports the vendor namespace. Swapping back to stock Builder, or to a fork, becomes a one-file change.
• Write schema_version into the JSON payload from day one, and store block type keys as stable, explicit strings rather than class names.
• Implement the renderer against a block-type registry with an explicit unknown block type fallback that logs and degrades gracefully rather than throwing. This is the safety net for downgrades, removals, and partial rollbacks.
• Keep stock Builder available behind a feature flag so a rollback is config, not a code revert.

Sequencing.

1. Compatibility spike (1–3 days, timeboxed). Install in a throwaway branch, define three representative block types including one nested and one with an upload, confirm serialization shape, confirm Filament version. Kill criteria: wrong Filament major, undocumented payload, or no graceful rendering path.
2. Wrapper + serialization contract. Land the factory, the schema_version convention, and the registry/fallback renderer before any editor touches it.
3. Schema governance doc. Who may add a block type, what the review checklist is, how existing content is migrated when a block's schema changes.
4. Pilot on one content type with 1–3 editors, instrumented for payload inspection.
5. Rollout, with the fork decision already made rather than discovered under pressure.

Operational Impact

Maintenance. Low steady-state effort but non-zero: you own the wrapper, the block registry, the renderer, and any fork. Budget roughly a few days per Filament upgrade to re-validate the field, plus ongoing schema-migration work whenever a block changes. That latter cost is driven by content volume, not by the package — it exists with stock Builder too, so it should not be charged against the buy decision.

Support. No commercial support, no dependents, no community to lean on. Escalation path is "open an issue and hope," which means the effective support model is we support it. That is acceptable for an internal editorial tool and unacceptable for anything customer-facing and revenue-critical without a named internal owner.

Scaling. Runtime scaling is a non-issue — the field renders in the admin panel, and content JSON is read on public page render. Watch payload growth instead: deeply nested blocks inflate the JSON and the Livewire component state, which degrades editor responsiveness on large pages. Set a soft cap on block count and nesting depth, and cache rendered output rather than re-parsing JSON per request.

Failure modes.

• Filament upgrade breaks the field — detected in CI if the version matrix is in place, otherwise at deploy. Mitigation: pinned versions, upgrade validation in the release checklist.
• Package abandoned mid-lifecycle — likely over a multi-year horizon. Mitigation: fork under the org, MIT permits it; wrapper keeps blast radius to one file.
• Unknown block type at render — content goes blank or errors after a downgrade. Mitigation: registry with explicit fallback and alerting.
• Stored XSS via block content — mitigation: sanitize on render, not on save, and restrict block types that accept raw markup.
• Silent payload drift when a block schema changes without a migration — mitigation: schema_version plus a validation pass over stored content in CI.

Ramp-up. For a developer already fluent in Filament, half a day to productive, one day to fluent in the payload shape. The larger onboarding cost is editorial: block-based authoring needs conventions, previews, and a "what good looks like" guide, or output quality drifts. Treat the editor enablement materials as part of the delivery scope, and designate one engineer as the package owner so the bus factor of one on the upstream side does not become a bus factor of zero on ours.