Weave Code
Message Repository For Illuminate Laravel Package
eventsauce/message-repository-for-illuminate
Laravel integration for EventSauce message repositories, letting you persist and retrieve domain events through Illuminate's database and Eloquent layers. Configure a message repository in your app and use it to store event streams, with support for Laravel's connections and transaction handling.
[READ ONLY] Sub-split for an illuminate message repository.
Frequently asked questions about Message Repository For Illuminate
- What is eventsauce/message-repository-for-illuminate used for?
- It provides a Laravel/Illuminate implementation of EventSauce's MessageRepository contract, persisting and retrieving serialized domain event streams through Laravel's database connection and query builder. It is intended for teams already using EventSauce in a bounded context, not as a general-purpose event store or replacement for Laravel's native events. It implements persist, retrieveAll, and retrieveAllAfterVersion.
- How do I install and configure it in a Laravel app?
- Install it with Composer alongside eventsauce/eventsauce and a serializer such as ConstructingMessageSerializer. There is no published migration, config file, or service provider, so you create a messages table with aggregate root id, aggregate root version, and serialized payload/headers columns, then construct the repository with a connection, table name, and serializer and bind it in your own provider. That manual wiring is by design because the package is a thin adapter.
- What database schema does the message repository require?
- You need a messages table storing the aggregate root ID, aggregate root version, and serialized event payload and headers. The package does not ship a migration or mandate a schema, but a unique index on aggregate_root_id and aggregate_root_version is strongly recommended to enforce optimistic concurrency and prevent silent stream corruption. Without that index, version checking becomes advisory rather than guaranteed.
- Does it work with Laravel 11 and Laravel 12?
- Support is determined by the illuminate/database constraint in the specific package tag, so check composer.json for the tag you install rather than assuming the latest Laravel major is covered. Because this is a read-only subtree split mirrored from the EventSauce monorepo, tags follow upstream releases. Test against your target Laravel version before committing.
- Does retrieveAll stream events or load them all into memory?
- The MessageRepository contract defines retrieveAll and retrieveAllAfterVersion, and the Illuminate adapter uses the query builder to fetch rows for the aggregate stream. Whether results are yielded as a generator or materialized depends on the implementation in the tagged version, so verify the return type in the source before relying on streaming for very long streams. For long-lived aggregates, test memory behavior and consider snapshots if replay cost grows.
- Can I use it with MySQL, PostgreSQL, and SQLite?
- Yes, because it uses Illuminate's query builder rather than database-specific SQL, it works across MySQL, PostgreSQL, and SQLite. That lets you keep CI and local development on SQLite while production runs Postgres, with no repository behavior divergence. You still need to create the messages table and indexes consistently across environments.
- How does it handle transactions and optimistic concurrency?
- The repository uses the injected Illuminate database connection, so it composes with DB::transaction() and Laravel's connection handling, including read/write splitting and multi-database configuration. Optimistic concurrency depends on your schema enforcing a unique constraint on aggregate root ID and version; the package alone cannot guarantee it. Use the unique index and handle duplicate-version failures at the application boundary.
- Is it compatible with Eloquent models and model events?
- No, it deliberately avoids Eloquent models, observers, and model events, operating directly on the query builder and connection. Anything relying on Eloquent lifecycle hooks, HasUuids, or soft deletes must be implemented at the repository boundary or in your own persistence layer. This keeps the adapter thin and avoids a second ORM in the domain path.
- How should I test an EventSauce message repository in Laravel?
- Because the adapter uses the Illuminate query builder, you can test it against SQLite in memory or a test database with the same messages schema you use in production. Cover persist, retrieveAll, retrieveAllAfterVersion, duplicate version handling, and transaction rollback behavior. Also test your serializer round-trip, since the repository stores serialized payloads rather than domain objects.
- What are the production risks and maintenance considerations?
- The package page shows low stars and no dependents, but that is largely because it is a read-only Composer subtree split mirrored from the EventSauce monorepo, so governance, issues, and releases live upstream. The real risks are governance ambiguity, release coupling to upstream tags, adoption opacity, and no repo-level CI in the split. Mitigate by pinning the version, committing the lockfile, naming an owner, verifying upstream tests, and accepting that a fork is affordable because the surface area is tiny.
Weaver
How can I help you explore Laravel packages today?