Events as Data objects

[ljubomirm]

I would like to post a feature request. I've really grown found of the ruby's new Data class. I think its immutable nature would fit events well. If you'd ever consider adapting the Data type for events, what would be your preferred approach? Would you replace the current data object with a Data class object, would you extract the current public interface into a module that could be included in a Data class definition, or would you do something else?

[palkan]

Hey @ljubomirm,

Sorry for late response (missed this issue for some reason).

I like the idea of using Data objects for events. Let's explore that for v2.

Started playing with this idea here: #12

Please, share your thoughts!

[ljubomirm]

Hey @palkan ,

Thank you very much for looking into this. To me it feels like two strategies could be extracted from the Event class, ImmutableEvent (where the name would expose more about what the intent is then technology it implements), and MutableEvent. I think it would be nice if the strategy would be configurable or perhaps set through an attributes attribute like immutable: true.

What do you think?

[palkan]

ImmutableEvent

I'm not a big fan of using the term "immutable" in Ruby, because immutability is too strict condition to implement in Ruby.

set through an attributes attribute like immutable: true.

I'm not sure we need to make this configurable. Why having mutable events? Seems conceptually illegal.

There is also a problem with the.attributes API is that it assumes you can call the method multiple times and, as a result, support inheritance. If we migrate to Data under the hood, we're no longer allowed to do that; we must define all the attributes at once (technically, we can overcome this by re-creating the Data class though).

From the Downstream perspective, we can be flexible and support an Event interface without having an assumption on a particular implementation.

[ljubomirm]

I see what you mean and it makes perfect sense. I also understand the dilema with the existing API and backward compatibility. I've mentioned configuration as an option, so it would be easier to define a default strategy for the attributes method, but a breaking change on the attributes method just can't sound great. I do like the v2 way of defining event classes and would prefer it to the old way.

Just to put an idea into ether, at a glance it seems like the Event interface could be included into a Data class defintion with less logic and fewer objects. Is there a real need for the Event class to be an envelope for a Data object? Could an event be just a Data object?

[palkan]

Is there a real need for the Event class to be an envelope for a Data object? Could an event be just a Data object?

The reason is that we actually have the following structure for events:

- event_id
- type
- data:
  - <your attributes> 

So, top-level attributes are library-defined attributes, and the data is your event payload following your schema.

We can't define nested structures using Data.define; and using Data.define would require users to declare our library attributes, too.

Finally, the event_id is not required at trigger time (when you create an event), and we can't instantiate a Data object without specifying all the attributes.

[ljubomirm]

The envelope with this structure could be built from the Data object. Perhaps the publish method could do this seamlessly.

[palkan]

Perhaps the publish method could do this seamlessly.

I think, we can do that; even with the current proposed implementation: we can create a DataEvent class on-the-fly for a given Data class, memoize it, wrap the source event and use as the actual event downs the stack; and then unwrap before calling the subscribers.