Tomato Resource Laravel Package

Technical Evaluation

Architecture fit

tomato-resource is the schema-definition layer of the TomatoPHP admin stack, not a standalone library. Its value proposition is a single resource class per model that drives table columns, forms, filters, actions, and validation, plus a generator that emits the migration, model, and CRUD wiring. The architecture has two halves with different risk profiles: a build-time generator that writes files and migrations into app/, and a runtime base class that CRUD screens consume.

Fit is strictly conditional. If we are already on tomato-admin, tomato-crud, and tomato-forms, this package is a prerequisite that unblocks admin work. If we are not, installing it yields a config file and a base class and nothing renders. That makes it an all-or-nothing bet on one vendor's internal API surface — itself v1.x and fast-moving — rather than an incremental library adoption.

Integration feasibility

Mechanically trivial: Composer install, publish config/migrations/lang, migrate, clear cache. The real feasibility work is verification, because the package ships no supported Laravel/PHP matrix, no feature list, and no breaking-change notes beyond a changelog link. Feasibility must be established empirically — read composer.json, read the tagged diff, enumerate supported field types from config/tomato-resource.php, then run one end-to-end pass on a small resource and diff the emitted migration against intent.

Technical risk (ranked)

1. Continuity — single 1.0 tag from October 2023, no releases since, 1 star, 0 dependents. Effective maintainer count is one, and there is no signal of ongoing stewardship.
2. Destructive generation — generated model/controller names derive from the table name; collisions may overwrite existing files, and any inline customization is lost on regeneration.
3. Silent failure mode — unsupported field types typically drop the column without throwing. The migration diff is the only reliable check, and it is a manual step.
4. Schema blast radius — the package publishes a resources meta-table and writes migrations. Conflict with an existing schema, or an alter at deploy time, is a production-grade failure.
5. Security assumption gap — authorization and validation behavior is undocumented. Generated CRUD does not imply policies or server-side enforcement; the resource definition must be treated as a UI hint, not a security control.
6. Performance — the CRUD index may paginate without eager loading; relationship-heavy screens can degrade quietly.

Key questions to answer before a go decision

• Are we already committed to Tomato Admin, or would adopting this pull us into an ecosystem decision we haven't made?
• What Laravel/PHP/database versions does composer.json actually declare, and do they cover our target matrix?
• Is generation non-destructive or configurable to be, and what exactly triggers an overwrite?
• Which field types survive end-to-end (definition → migration → form → table), and which are dropped silently?
• Is the resources meta-table additive-only, and is it required in production?
• Does the base resource class give us enough extension surface to hold shared defaults and a vendor-agnostic boundary?
• What is the real cost of the fallback (Filament, or hand-rolled controllers) for our specific backlog size?

Integration Approach

Stack fit

Laravel plus Tomato Admin only. Portability is near zero — the abstraction assumes Tomato's CRUD and form packages exist and render. A prerequisite gate should apply: confirm the admin panel boots before any debugging of this package begins, because failures at the screen layer are almost always upstream, not here. The honest comparison set is Filament, Nova, or Backpack; this package does not compete on documentation, hiring pool, or support history, and wins only on "we are already on Tomato."

Migration path

There is no migration from an incumbent admin framework — this is additive inside a Tomato codebase. If we are on plain Laravel, adopting this is adopting the Tomato stack, and should be scoped and approved as such rather than as a single-package addition. The exit path costs one class today: wrap the vendor base resource class in our own subclass and confine vendor references to that one file, so a future swap or fork stays cheap.

Compatibility

Pin 1.0.* — never an open constraint. Verify the version matrix manually against our environment. Validate the publishable migrations against a scrubbed copy of the target schema before touching anything shared. Assume config keys and class names churn between minors; treat every bump as a reviewed change, not a composer update.

Sequencing

1. Prerequisite: confirm the Tomato Admin panel boots, and pin the entire Tomato set together — the packages drift as a group.
2. Read config/tomato-resource.php in our checkout and enumerate supported field types and generation paths. This gates every later step.
3. Build and register our own base resource subclass (soft deletes, ID strategy, common casts, audit columns) before generating anything, so we never retrofit it across existing resources.
4. Time-boxed pilot on one real back-office table. Generate, hand-diff the migration against intent, commit the artifacts, wire one CRUD page, confirm index/create/edit render.
5. Instrument the index page: query counts at realistic row volume with relationships joined.
6. Gate the pilot against explicit criteria — field coverage, no collisions, no schema conflict, acceptable support surface, acceptable query counts.
7. Only then expand across the backlog, one resource at a time, with output committed and reviewed every time.

Bake these into the team's working agreement: the generator runs locally and never in CI or at deploy; generated files are committed and reviewed as code; customization lives in subclasses or traits, never inline; php artisan optimize:clear is the first debug step after any definition change.

Operational Impact

Maintenance

Low run-cost, high drift-cost. There is very little to operate day to day, but a single 2023 release means any patch we need makes us the maintainer of a de facto fork. Mitigations are structural: interface boundary, pinned version, no vendor-file patches, and a deliberate upgrade cadence we schedule rather than chase. Budget a one-off fork-or-replace decision within roughly twelve months of adoption, and make that decision explicit now so it isn't forced later.

Support

Community support is effectively nil at 1 star and 0 dependents — internal ownership is mandatory, not a nice-to-have. The saving grace is that troubleshooting is tractable with a four-step runbook any mid-level developer can execute: confirm the panel boots, clear cache, inspect the emitted artifact, reduce the definition to the smallest failing field set. Escalation beyond that is binary — fork it or replace it. There is no vendor path.

Scaling

Technically, the admin surface scales fine for internal back-office volume, and the generator is dev-time so it imposes no runtime cost. Two things to watch: index pages that paginate without eager loading, where N+1s compound with row count and relationships, and schema breadth, since each new resource is another artifact set to review. Organizationally it scales poorly — the hiring pool for TomatoPHP is essentially zero, so ramp cost is paid per person rather than amortized, and the bus factor sits with whoever wrote the convention doc.

Failure modes and blast radius

• Schema conflict (highest blast radius): generated migrations collide or alter at deploy. Mitigate with mandatory hand-diff, a scrubbed-copy dry run, and a backup plus rollback plan for the first production deploy that includes these migrations.
• Silent field drop: a column is missing and the UI and API are quietly incomplete. Mitigate by diffing every generated migration against the intended schema, without exception.
• Overwrite: a generated model or controller clobbers hand-written code. Mitigate by committing before generating, checking configured output paths, and only generating into a clean tree.
• Stale cache: a defined field is invisible in the UI. Mitigate with optimize:clear as documented first-line response.
• Authorization gap: generated CRUD exposes data without policy enforcement. Mitigate by wiring policies and server-side validation explicitly at the controller layer, and by stating in writing that the resource definition is not a security boundary.

Ramp-up

Days, not weeks, for an existing Laravel developer — but only if the base class and a short convention doc exist first. The convention is the actual deliverable: resource class owns schema, controller owns screen concerns, subclass owns shared defaults. Without it, per-screen divergence starts within a sprint. Ramp cost is asymmetric: cheap for Laravel natives, expensive for anyone from a Filament or Nova background, who will reasonably expect documentation and a support community that do not exist here.

Framing for the decision: this is a scoped, time-boxed pilot behind one internal tool with a named fallback — not a platform standardization. The cost of trying is genuinely low: one resource, one sprint, a pinned version, and artifacts under version control. The cost of standardizing prematurely is a single-maintainer dependency sitting in the critical path of every internal CRUD screen we ship.