4 ms·

Before anyone goes building their very own eventstore based on this blog article—even calling this implementation of the pattern eventsourcing is a stretch. You

Before anyone goes building their very own eventstore based on this blog article—even calling this implementation of the pattern eventsourcing is a stretch. You don't "query" the event stream. Your projections subscribe to it. (Also, there's no projection in this.) And while its not the first time i've heard of someone using a table per event type, its definitely something I'd regard as an antipattern. There are MUCH better articles out there about eventsourcing, even in Rubyland where its still fairly uncommon. This one is just cargo-culting, poorly.

codebeaker 9y ago
I'm currently writing a book on this (ES/CQRS), but I have come to the conclusion through some of our projects that a "subscription" model is actually less ideal as you end up falling back to keeping a lot of state in the application heap. We rather prefer to have a subscriber who re-runs the projections which are purely functional, and dump their state. This mandates that you have some way of querying relevant events from the underlying store. Sometimes the best store for this is a DBMS, sometimes it's something simpler like CAS linked lists in Redis or similar (lists of hashes pointing to keys, similar to git's ref/tag model) Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult, and simply calling as-frequently-as-makes-sense your update function is simpler to reason about, and helps highlight performance issues by making it easier to see the perf of frequently called short lived processes vs dealing with any VM bloat of your choice of language's runtime managing long lived subscribers. Caveat: naturally this is all very subjective, just my 2 ¢
- fnord123 9y ago
  >Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult This is true. It's also a problem if you drop a packet - you need to build up state again on the client side. If you're writing a book about event sourcing, I should think you'll spend a good deal of time covering trading systems and order books since these are an area where event sourcing (AIUI) has been used for decades.
- karmajunkie 9y ago
  Yeah, i agree with most of that, particularly the utility of having your projections be pure functions. You can go a really long way on ES by doing on-demand projections (with or without snapshots as you describe). However, I stand by what I said earlier in that you don't query streams—though whether you subscribe as a live projection or request the entire stream (or perhaps the entire stream from version number X onward, to be used with snapshots) is definitely a YMMV kind of question.
cedricd 9y ago
Do you have a link to some of those articles?
- karmajunkie 9y ago
  Google Greg Young and Udi Dahan for starters... If you're doing this in Ruby, you can check out Eventide as one option, but i'm not sure if it plays well with Rails as the team behind it is squarely in the anti-Rails camp.
davidgl 9y ago
Strongly recommend this as a good place to start: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying https://engineering.linkedin.com/distributed-systems/log-wha...

codebeaker 9y ago

I'm currently writing a book on this (ES/CQRS), but I have come to the conclusion through some of our projects that a "subscription" model is actually less ideal as you end up falling back to keeping a lot of state in the application heap. We rather prefer to have a subscriber who re-runs the projections which are purely functional, and dump their state. This mandates that you have some way of querying relevant events from the underlying store. Sometimes the best store for this is a DBMS, sometimes it's something simpler like CAS linked lists in Redis or similar (lists of hashes pointing to keys, similar to git's ref/tag model) Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult, and simply calling as-frequently-as-makes-sense your update function is simpler to reason about, and helps highlight performance issues by making it easier to see the perf of frequently called short lived processes vs dealing with any VM bloat of your choice of language's runtime managing long lived subscribers. Caveat: naturally this is all very subjective, just my 2 ¢

fnord123 9y ago
>Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult This is true. It's also a problem if you drop a packet - you need to build up state again on the client side. If you're writing a book about event sourcing, I should think you'll spend a good deal of time covering trading systems and order books since these are an area where event sourcing (AIUI) has been used for decades.
karmajunkie 9y ago
Yeah, i agree with most of that, particularly the utility of having your projections be pure functions. You can go a really long way on ES by doing on-demand projections (with or without snapshots as you describe). However, I stand by what I said earlier in that you don't query streams—though whether you subscribe as a live projection or request the entire stream (or perhaps the entire stream from version number X onward, to be used with snapshots) is definitely a YMMV kind of question.

cedricd 9y ago

Do you have a link to some of those articles?

karmajunkie 9y ago
Google Greg Young and Udi Dahan for starters... If you're doing this in Ruby, you can check out Eventide as one option, but i'm not sure if it plays well with Rails as the team behind it is squarely in the anti-Rails camp.

davidgl 9y ago

Strongly recommend this as a good place to start: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying https://engineering.linkedin.com/distributed-systems/log-wha...