Product Decisions This Supports
- Build vs. buy for internal event-sourcing observability. The package ships an admin surface (event stream, stored aggregate/projection state) on top of Filament, so the decision it most directly informs is whether to spend engineering weeks building an internal viewer versus adopting a maintained one. Default lean: adopt, unless your event model needs bespoke replay/orchestration controls.
- Filament upgrade timing. v1.2.0 widens the Filament constraint to accept both 4 and 5. This decouples the package from your admin panel's major version, meaning your Filament 5 migration is no longer blocked by this dependency. That is a roadmap-unblocking fact, not just a compatibility note.
- Support and operations tooling roadmap. An event-stream UI is a customer-support and incident-response capability: it lets non-engineers answer "what happened to this order/account and when" without a database console. Frame it as an ops-enablement line item, not a developer nicety.
- Auditability and compliance positioning. For event-sourced domains, a browsable, read-only record of what the system recorded is a direct input to audit-readiness and dispute-resolution conversations. Useful when scoping regulated or enterprise-tier features.
- Risk posture on dependency breadth. The package now supports two Filament majors with a CI matrix covering both, which lowers the "we'll get stranded on an old major" risk that often kills small admin-panel dependencies in procurement/architecture review.
When to Consider This Package
Consider it when most of the following hold:
- You already run Filament as your admin panel and event sourcing (typically
spatie/laravel-event-sourcing) in the domain — the package's value is the bridge, not either half.
- You need read/inspect visibility into stored events and aggregates: debugging projections, answering support questions, verifying that a state change actually got recorded.
- Your team is small enough that a maintained admin viewer is cheaper than a bespoke one, and you accept the upstream project's release cadence.
- You want the Filament 4 → 5 upgrade path to stay open; v1.2.0 makes that a non-issue rather than a blocker.
- You are comfortable pinning to a single-maintainer, community-scale package for internal, non-customer-facing tooling where failure is inconvenient rather than revenue-impacting.
Look elsewhere when:
- You are not on Filament or not event-sourced — the package assumes both, and the cost of adopting either just to use it is disproportionate.
- You need write operations or managed replay/rebuild orchestration from the UI. A viewer is not a control plane; treat replay tooling as a separate, higher-risk decision with its own guardrails.
- You require fine-grained RBAC, tenant isolation, retention/archival, or PII redaction on the event payloads shown to staff. Plan to extend or wrap the package, and budget for it.
- You are on PHP 8.2 with Filament 5 and require tested support: v1.2.0 allows that combination but does not test it. If your platform is 8.2, either stay on Filament 4 or move to PHP 8.3+ before committing to Filament 5.
- You need an SLA, vendor accountability, or a long-term support guarantee.
How to Pitch It (Stakeholders)
For executives (one paragraph): This is a small, free, open-source add-on that gives our admin panel a read-only window into our event-sourced data — the record of everything the system has done. It replaces work we would otherwise build ourselves, and it shortens support and incident investigations by letting staff answer "what happened and when" without engineering involvement. The new release (v1.2.0) is a pure compatibility widening: it keeps us current with Filament 5 without forcing an upgrade now, and it is fully backward compatible with the version we would be adopting — no code changes, no config changes, no behaviour changes. Cost is near zero; risk is low and confined to internal tooling; the main caveat is that it is a small community project, so we should not build anything revenue-critical on top of it without a fallback.
For engineering leads: v1.2.0 is a constraint widening only — Filament 4 and 5 both install, public API, configuration and behaviour are unchanged, and the release is explicitly backward compatible with 1.1.0. CI runs the full suite against both majors across supported PHP/Laravel combinations, with one documented gap: PHP 8.2 + Filament 5 is allowed by the package's constraints but untested because the test tooling won't install there. Static analysis covers both majors. Practical guidance: treat v1.2.0 as a safe drop-in; if we are on PHP 8.2, resolve that before the Filament 5 move rather than treating this package as the blocker. No migration work, no API surface to re-learn, no deprecations to track.
Recommended framing: adopt for internal observability now, defer any Filament 5 upgrade to its own scheduled work, and explicitly scope out replay/write capabilities so the viewer stays a low-risk read path.