Generate event ID for each adapter

[davydovanton]

We want to see simple way for debugging events, that's why we need to use sequences for each adapter type and generate event_id. For example:

events = Hanami::Events.initialize(:memory_sync)
events.subscribe('user.created') { |payload| p payload }

events.broadcast('user.created', user_id: 1) # => event_id

Backlog

• [x] Generate simple UUID as a event id (eid) (https://github.com/hanami/events/pull/80)
• [ ] Use a meta keyword in subscribe block for getting eid
• [ ] Try to use universally Unique Lexicographically-sortable time-based Identifiers as eid (https://github.com/abachman/ulid-ruby)

Event type

I really love idea from redis streams:

The ID is composed of two parts: a millisecond time and a sequence number. 1506871964177 is the millisecond time, and is just a Unix time with millisecond resolution. The number after the dot, 0, is the sequence number, and is used in order to distinguish entries added in the same millisecond. Both numbers are 64 bit unsigned integers. This means that we can add all the entries we want in a stream, even in the same millisecond.

That's why, let's create event id as time.seq

[joelvh]

@davydovanton I imagine Redis doesn't also have a process identifier because it can maintain the sequence number in one place. When maintaining a sequence across multiple processes, it's a little more tricky and at least could require an identifier for the process as well.

However, I'd looked for a GUID/UUID format that incorporated a timestamp and randomness. ULID is what I found and think would be a great solution to adopt as a default UUID. It has a timestamp prefix followed by random entropy. Formatted as a UUID with specific characters (not hex), it can also be converted to a big int.

Check out ULID (Ruby implementation): https://github.com/abachman/ulid-ruby

Thoughts?

[joelvh]

P.S. ULID can also help make SQL indexes faster by having some sequence to the IDs via the timestamp prefix in the ULID

[davydovanton]

@joelvh hey, thanks for your ideas 💯

I think, for the first iteration, we can use SecureRandom.hex for this (like a in sidekiq).

For me, the general idea of "eid" (Event ID) is better logging, that's why we can use not uniq way now. In future we can create a way for adding custom id functions 🤔

[joelvh]

@davydovanton got it - makes sense. I'm also coming more from the UUID-as-identifier perspective and thinking of Event Sourcing, but Hanami Events is more transient events for coordination rather than state.

[davydovanton]

yep, agree with you. that's why I suggest to create a simple solution before and understand what we need :)

[joelvh]

@davydovanton what was the reasoning not to use Wisper with custom broadcaster?

[davydovanton]

I created simple backlog for this feature. will work on it