Added message type to allow store not only events but also commands and unfied message processing #183
Conversation
oskardudycz
force-pushed
the
message_type
branch
from
a966e95 to
0196377
Compare
| data: { mocked: true }, | ||
| metadata: { | ||
| streamName: 'testStream', | ||
| eventId: `event-${position}`, | ||
| messageId: `event-${position}`, | ||
| streamPosition: position, |
There was a problem hiding this comment.
Should "event" from value be changed to "message" too? 🤔
There was a problem hiding this comment.
I could do that too, indeed. 👍
| @@ -45,7 +42,7 @@ export type CreateCommandType< | |||
| data: CommandData; | |||
| metadata: CommandMetaData; | |||
| } | |||
| >; | |||
| > & { readonly kind?: 'Command' }; | |||
There was a problem hiding this comment.
Yes, I don't want to force Emmett user to pass kind property if it's not needed and can be resolved by context. Typically, it'll be needed when a message can be either a command or an event, e.g. workflow or message handling). That will be typically done on the receiving end (so subscriptions). There, it will be automatically filled upon reading from the store. See: https://github.com/event-driven-io/emmett/pull/183/files#diff-ca381aa5cbc0929ecbb32c004c54bce2d0d6c1ceb3c91d524055888807396559R69
oskardudycz
force-pushed
the
message_type
branch
from
0196377 to
5296777
Compare
oskardudycz
force-pushed
the
message_type
branch
from
5296777 to
13060c6
Compare
This is the first step to enable message storing and workflows
oskardudycz
force-pushed
the
message_type
branch
from
13060c6 to
65405ae
Compare
|
I'm not yet convinced whether this will stay like that or I'll go with Happy to continue discussions on this design in the future. |
This is the first step in enabling message storage and workflows.
It adds a Message type that's either a command or an event. I added an additional property called kind, which will inform you what the message actually is (so if it's an event or command).
The next step is to adjust the stores to keep that information. I will also rename tables and columns to have event in their names instead of message (e.g., message ID, message type, etc.). MongoDB event store is already adjusted to some degree to that. Eventually, event stores will become message stores. Of course, I want to keep the abstractions as we have, but probably as aliases. See this in follow up PR: #184
Thanks to that, Emmett will be able to store and then handle async workflows as described in https://event-driven.io/en/how_to_have_fun_with_typescript_and_workflow/. Commands will be stored either in the stream together with events or in a dedicated "outgoing commands stream".
Thanks to having mentioned earlier kind when building the state, we'll be able to just read the events.
As an alternative to kind I was considering renaming type property in Command and Event types to commandType and eventType. Then we could benefit from duck typing, but I didn't like that fully, as in general both Commands and Events are just Messages, so that'd be a bit too expressive imho.
Of course, the kind will not be required to be provided in the regular code. It will probably only be used in workflows to distinguish if we're sending command or storing event.
It will always be available upon reading. As it'll be stored.