Tomato Notifications Laravel Package

Technical Evaluation

Architecture fit. This is an ecosystem add-on, not a notification platform. It contributes three things over stock Laravel: a persisted template model, a Filament CRUD/send resource, and a channel class that hooks into Laravel's native Notification system. Delivery, queuing, localization, and retries remain Laravel core. The decision it actually informs is narrow and real: buy vs. build for an admin-composed template layer behind an in-app inbox. Adopting it does not reduce the later work of building a multi-channel delivery strategy — scope the decision accordingly so stakeholders do not over-read the win.

Integration feasibility. Mechanically trivial (Composer install, auto-discovered provider, publishable config and migrations). Contextually unproven. With 1 star, 0 dependents, and a last release in mid-2024, no integration other than the author's own has been validated. A clean composer install is evidence of a clean install, nothing more. The three unknowns that decide feasibility: the illuminate/* version range, the required Filament major, and whether tomato-admin / tomato-settings / tomato-roles are hard requirements or soft suggestions. Budget half a day to read composer.json and the provider before committing to anything else.

Technical risk. Dominated by supply-chain and longevity exposure, not code quality. Single-maintainer org publishing many interdependent packages, no visible security-disclosure process, no evidence of a test suite, no upgrade cadence. Three risks require engineering sign-off before commit:

• Template renderer safety — if templates compile through Blade::render or eval, template-edit permission becomes code-execution permission. That reframes the entire admin-GUI value proposition as a security review item and is a blocking gate.
• Schema collision with Laravel's own notifications table and any existing template tables.
• Queued-job staleness — if templates resolve at execution time rather than being snapshotted into the payload, a mid-flight edit or delete changes what ships to users.

MIT licensing is the mitigant: forking is legally clean, so lock-in is bounded to engineering labor rather than legal exposure. That is the single most important fact for the buy decision and the one to lead with in the stakeholder pitch.

Key questions before a decision.

• Which channels does the channel class support, and does it wrap or replace the Notification facade?
• Is rendering Blade::render, eval, or restricted substitution? (Blocking.)
• Are templates snapshotted into queued jobs, or resolved at execution time?
• Is variable validation enforced at save time, or does a missing placeholder fail at send time?
• Are channel failures surfaced to error tracking, or caught and logged silently?
• Is the template model usable headlessly, without installing the Filament resource?
• Is there multi-tenant and per-locale template support?

Integration Approach

Stack fit. High fit if and only if the target is PHP 8.x + Laravel 10/11 + Livewire + Filament 3 + the Tomato admin suite already in production. There it is a genuine small win — template CRUD and a send flow you do not build. Anywhere else the dependency cost is disproportionate: a full Filament admin tree for one model, one resolver, and one channel class.

Migration path. Three options, descending preference for a non-Tomato stack:

1. Vendor and prune (recommended default). Fork under MIT, keep the template model, migration, resolver, and channel, drop the Filament resource, expose templates through our own admin surface. Captures the value while owning the render engine and dependency surface.
2. Adopt whole. Only where Tomato admin is already live. Pin the exact version; treat every bump as a reviewed change.
3. Build thin in-house. A notification_templates table, a cached resolver, and a channel over a whitelisted variable set is roughly 150–250 lines. Get that estimate from engineering in the same window as the spike — it is the real buy-vs-build threshold.

If replacing hardcoded notifications, migrate channel by channel: run the templated path in parallel with the incumbent, diff rendered output, cut over behind a flag. No big-bang cutover across notification types.

Compatibility. Pin explicitly; never float. Run composer why-not against current Filament and Laravel constraints before install. Verify published migration table names do not collide with notifications or existing template tables, and that published config keys do not shadow our own config/notifications.php. Confirm auto-discovery does not register routes or views that shadow existing ones.

Sequencing.

1. Throwaway branch: install, publish, migrate against SQLite, boot the app. (0.5 day)
2. Read the channel class and renderer — 20 minutes that settles most of the risk register. Decision gate.
3. Spike one template and one channel end-to-end through a queued job, including a deliberate missing-variable case. (0.5–1 day)
4. Wrap behind internal TemplateResolver / TemplateRenderer interfaces so the package is swappable without touching call sites.
5. Add composer audit and a dependency-review gate to CI; record the pin and rationale.
6. Roll out behind a flag, one notification type at a time.

Total to a go/no-go: 1–2 engineer-days. That is the budget ask.

Operational Impact

Maintenance. Assume we own it. Consuming unmodified costs near-zero day-to-day but accrues incompatibility risk at every Filament or Laravel major — and given the release cadence we should not assume the author ships a compatible version. Forking shifts cost to roughly 1–3 engineer-days per quarter. Name an owner before adoption; an unowned fork is a deferred outage.

Support. Support is limited. There is no SLA, no security-disclosure channel, and escalation is reading the source. For an internal/MVP inbox that is acceptable; for anything customer-facing or regulated it is not. The support burden lands on whoever owns the admin surface, so agree that explicitly with the team who will field "please change this copy" tickets — the same people who benefit from the GUI are the ones who inherit support.

Scaling. Delivery scaling is Laravel's, not this package's — queue workers, retry policy, and rate limits are our existing operational surface. What scales poorly is the template layer: no evidence of caching strategy, no multi-tenant isolation, no per-locale template variants, and an admin CRUD that will not age into a campaign tool. If volume or segmentation becomes a near-term need, this is the wrong substrate and a managed provider is the better answer.

Failure modes. Three to instrument for:

• Silent channel swallow — notification composes, nothing sends, no signal. Requirement: failures must surface in error tracking, not Log::info.
• Missing-variable send-time failure — template saves clean, dies at dispatch. Mitigate by validating variables at save time in our wrapper, not trusting the package.
• Stale queued render — a mid-flight template edit changes what a queued job ships. Mitigate by snapshotting rendered subject/body into the job payload at enqueue time if the package does not.

Ramp-up. Half a day for a Laravel-fluent engineer to read the channel and renderer and land the spike — the package is small enough that ramp-up cost is not a real objection. The genuine ramp-up cost is the operating model: who may edit templates, the variable whitelist, approval flow, and locale variants. That is product work the package does not do for you, and it should be scoped as a follow-on deliverable rather than assumed to ship with the install.