Skip to content
effect-cqrs

Limitations

effect-cqrs is a trial port, not a maintained library. These are the gaps that matter before using it for anything real.

  • No broker. New events wake view models and subscribers in every process, through PostgreSQL notifications or by polling, but there is no transport like the Moleculer broker, so dispatch is the entry point to wire into your own HTTP or RPC layer.
  • SQLite, PostgreSQL and memory only. There are no adapters for MongoDB or MySQL.
  • Snapshots are opt-in. Without them, recent state is only kept in memory, so after a restart each aggregate is replayed the first time it is used. A changed state needs a new snapshot version by hand.
  • Event upcasts are pure. An upcast can’t read a service or fail with its own error, and an event can only be read in a version its aggregate declares.
  • No code generator. There is no equivalent of cqrs generate.
  • No inline projections. A view model never runs in the transaction that appends the events, so a read model is always a moment behind its command. Read one aggregate with state, which is always current, or wait for a command’s position with caughtUp or CommandApi.ReadAfter.
  • Slow handlers don’t slow writers. There is no backpressure, so a view model with a slow handler falls behind and catches up when writes stop.
  • One thread. Concurrent writers share commits, but the work itself doesn’t spread over cores, and synchronous SQLite calls block the event loop while they run.