commanded

commanded copied to clipboard

I'll just leave this here, as I personally would find this useful. Feel free to close it if it's irrelevant.

It would be nice to support a simple catch-up-subscription, per "category", with client persistent state. For example, I would like to project all events from "$ce-cars" category. Using the current competing consumers, it is hard to make commanded integrate with other non-commanded systems using ES.

For example, I would like system A to publish events to "cars-123" stream. System A is using HTTP API. Then system B (with commanded) would subscribe to "$ce-cars" and project all the cars into a sql table.

I guess I'm not sure what this will involve, because using Extreme is already sufficient, but this is just a thought. Maybe you can make an even nicer abstraction.

I've been looking for this option, too, encountering a couple of cases where I'd like to subscribe to all Events for a specific Aggregate type. I'm not sure whether this would be more of an EventStore issue that a Commanded issue, though... (as in: you may want to have a stream_type (aggregate type) registered with each stream, enabling per-type subscriptions on the EventStore level).

@florish I'm using Greg's ES, where it is already available: http://codeofrob.com/entries/creating-a-projection-per-stream-in-the-eventstore.html

@florish Both Greg's Event Store and my own Elixir EventStore support subscriptions to a single stream. But only Greg's Event Store supports category subscriptions (e.g. by event type).

Commanded could allow the user to configure the stream that a handler, or process manager, subscribes to as in the example below:

defmodule ExampleEventHandler do
  use Commanded.Event.Handler, 
    name: "ExampleEventHandler",
    subscribe_to: "$ce-cars"
end

This would be optional, the default would be the current behaviour (subscribe all events).

@slashdotdash @drozzy Thanks both! Good to know about the available options.

I think the $ce-cars behaviour should be the default. I practically never subscribe to single stream (commanded handles it for me automatically for aggregates!)

So it looks like internal implementation leaking into user layer.

By the way, this is the only feature that commanded is missing for me not to use Extreme alongside it.

@drozzy Using $ce-cars as a default wouldn't work with anything other than Greg's ES, would it? AFAIK the Postgres-backed Eventstore (commanded/eventstore) would not be able to use that default since it does not have category streams ATM, or am I mistaken here?

Sorry, I'm not familiar with Postgres-ES :-(

Not a problem at all, in essence there is no such thing as category streams in there yet (I'm not aware whether there is interest in building something along these lines). So right now, if Commanded is going to support pluggable backends, it'd be necessary to subscribe to $all since that's the only stream that is guaranteed to be supported by all backends.

Apart from that, totally agreed with your point, it'd be super nice for scalability as well.

@jfornoff the notion of "categories" is what makes the stream model per-aggregate so powerful. For example, if you have a page that lists "cars", how would you get cars from different aggregates into one projection? I suppose if you could query the DB directly (and if that DB did projections for you) that would solve the issue. But ES.org is remote service, and you can't build large projections and then query them.

I find, in general, that ES guys know what they are doing in terms of Event Sourcing, and I've been actually learning about the right way of doing things just by using their product (for example, their competing consumers implementation teaches you that you must ack everything, as opposed to how I though it would work magically).