The idea is nice and needed. However maybe the spec is a bit elaborate for me to adopt it immediately. I've been rolling my own for some time at some clients, for our kafkaesque/event sourcing patterns.
However what I used there was simple http stream/json stream like this:
- No start of [] but JSON newline entries a new line is an new entry
- Using Anything as an id (we've been using redis XSTREAMS as lightweight kafka concepts, just 64bit integers)
- have an type as an event, and versioning is just done by upgrading the type, ugly, but easy.
- We'er considering using SSE at this moment
Compaction is not something that I would do in the protocol I think I would just expose another version of it on a different url I think or put it in a different spec.
How do you recover when there is e.g. some connection error and a client misses some events? Can the client ask to replay the events? Then, how far back can they go?
However what I used there was simple http stream/json stream like this:
- No start of [] but JSON newline entries a new line is an new entry
- Using Anything as an id (we've been using redis XSTREAMS as lightweight kafka concepts, just 64bit integers)
- have an type as an event, and versioning is just done by upgrading the type, ugly, but easy.
- We'er considering using SSE at this moment
Compaction is not something that I would do in the protocol I think I would just expose another version of it on a different url I think or put it in a different spec.