Filament Event Sourcing Laravel Package

Technical Evaluation

Architecture fit. albertoarena/filament-event-sourcing is a Filament panel plugin that surfaces event-sourcing state (stored events, aggregates/projections, replay tooling) inside the admin panel. Architecturally it sits at the outermost layer of a Laravel app: it consumes the event store and read models, it does not own them. That is a good fit for teams already running spatie/laravel-event-sourcing (or a compatible store) behind a Filament admin panel — the plugin adds an operational surface rather than a new runtime dependency in the domain layer. Teams without event sourcing get nothing from it, so the addressable audience is narrow and self-selecting.

Integration feasibility. This release is deliberately low-risk to adopt: no public API, config, or behavioural changes — the sole delta is a widened filament/filament constraint permitting v5 alongside v4. For an existing v1.1.0 consumer on Filament 4, upgrading is a lockfile move with no code edits. For a team planning a Filament 5 upgrade, this package is no longer a blocker. Installation remains a standard Composer require plus plugin registration in the panel provider; there is no migration, no publish-and-edit step introduced here.

Technical risk. The material risk is the declared-but-untested combination: PHP 8.2 on Filament 5. The constraint allows it, CI cannot install the tooling to prove it. That is a small but real exposure — it converts a hard compatibility gate into a runtime-discovery problem, and it will surface as confusing failures (missing class, signature mismatch) rather than a clean Composer conflict. Secondary risks: Filament 5 is a fresh major, so transitive panel dependencies (other plugins, custom panel customisations) may still lag, and this package's own CI only proves its slice of the matrix. Third: event-sourcing UIs are read-heavy against append-only tables; the release says nothing about query behaviour on Filament 5, and static analysis does not catch N+1 or missing index regressions.

Key questions.

• Which PHP and Laravel versions do we actually run, and does the Filament 5 path in our matrix intersect the untested PHP 8.2 cell?
• Do we have other Filament plugins or bespoke panel code that constrain us to Filament 4 today?
• Is the underlying event store spatie/laravel-event-sourcing, and which major?
• What is our exposure if the plugin's event-listing views are pointed at a high-volume store — has anyone load-tested them?
• Who owns the Filament 5 upgrade decision, and does this release pull it forward?

Integration Approach

Stack fit. Assumes Laravel + Filament + an event-sourcing backend. The plugin is admin-plane only; it should never be a dependency of the domain or API layers. Keep it in require-dev if panels are not deployed to production, otherwise require — but treat it as operational tooling, not application logic.

Migration path. Two distinct paths, and they should be sequenced separately:

1. Existing v1.1.0 users staying on Filament 4 — bump to v1.2.0 for constraint hygiene only. No code changes, no config publish, no data migration. This is a routine dependency refresh and can ride the normal weekly cadence.
2. Teams moving to Filament 5 — upgrade Filament first, verify the panel boots and the plugin's pages render against a seeded staging event store, then confirm the plugin resolves without conflict. Do not bundle the Filament major bump with unrelated feature work.

Compatibility. Backward compatible with 1.1.0 by declaration. Tested: Filament 4 across the supported PHP/Laravel matrix; Filament 5 across the same matrix minus PHP 8.2. If we are on PHP 8.2 and want Filament 5, treat it as unsupported regardless of what Composer permits — either move to PHP 8.3+ or hold Filament 4.

Sequencing.

1. Confirm our PHP/Laravel/Filament matrix and whether we sit in the untested cell.
2. Upgrade to v1.2.0 on the current Filament major; run the suite and smoke-test the panel in staging. Low ceremony.
3. Separately, plan the Filament 5 upgrade; on the branch, bump PHP first if needed, then Filament, then this package.
4. Verify against a realistic (anonymised or seeded) event store, not an empty one — empty-store page loads hide pagination and performance problems.
5. Add a CI job pinning the Filament major so future transitive drift is caught in our pipeline, not in production.

Operational Impact

Maintenance. Near-zero for the v1.1.0 → v1.2.0 hop: no config surface, no migrations, no deprecations. The ongoing cost is tracking Filament majors — this package's release cadence is evidently tied to them, so expect a similar constrained release at each Filament major. That is predictable and cheap.

Support. Single-maintainer package (per the repository namespace), which is the standing risk regardless of this release. Mitigation is the usual one: pin the version, keep the lockfile committed, and be prepared to vendor or fork the panel pages if the maintainer goes quiet — the surface is small enough that a fork is feasible, which materially lowers the risk compared to a deep framework dependency. The declared-but-untested PHP 8.2 + Filament 5 cell will generate support questions upstream; do not rely on it.

Scaling. Two axes. Data volume: event stores grow monotonically and the plugin reads them; listing pages need pagination, sensible default filters, and indexed queries. Nothing in this release addresses that, so validate against production-shaped data before exposing the panel to a wide audience. Access control: the panel exposes raw event and projection state, which is sensitive. Restrict these pages to a named admin role / gate rather than leaving them on for all panel users, and confirm that surviving a Filament major does not silently change authorisation behaviour.

Failure modes.

• Composer resolves an allowed-but-untested combination (PHP 8.2 + Filament 5) and fails at render time rather than at install time. Detect by pinning PHP and Filament in CI.
• Filament 5 transitive drift breaks the panel after an unrelated composer update. Detect via a scheduled build and a staging smoke test.
• Panel timeouts or memory exhaustion against a large event store. Detect with a seeded dataset in staging and query-count assertions.
• Sensitive event payloads visible to under-privileged panel users. Detect via an access-control test on the plugin's pages.
• Maintainer abandonment. Detect by watching release cadence against Filament majors; respond by forking.

Ramp-up. Minimal. A Laravel developer familiar with Filament registers the plugin and is productive within an hour; the concepts they need (events, aggregates, projections) come from the event-sourcing library, not this package. Budget roughly half a day for a developer new to event sourcing to interpret what the panel shows correctly. The Filament 4 → 5 upgrade on our side is the larger effort and should be scoped as a Filament migration, not as a plugin upgrade — this release simply removes the plugin from that critical path.