Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a CQRS/ES web application in Elixir using Phoenix

10consulting.com

Post reply on HN
Print view View original

11–20 of 81 posts

Re: Building a CQRS/ES web application in Elixir using Phoenix

#11

Post by eric_b »

ryanworl wrote: post #9
eric_b wrote: post #6

I have worked on, or cleaned up, 4 different CQRS/ES projects. They have all failed. Each time the people leading the project and championing the architecture were smart, capable, technically adept folks, but they couldn't make it work. There's more than one flavor of this particular arch, but Event Sourcing in general is simply not very useful for most projects. I'm sure there are use cases where it shines, but I ha…

What do you think about the use of technologies like Kafka which enable what is effectively an event sourced architecture without all of the buzzwords? Not everyone uses it that way, obviously, but there is plenty of discussion about it.

One of the projects did use Kafka as the "event log". There were stability issues with the version of Zookeeper that was used. From a writer/reader perspective Kafka was sufficiently performant when it was up. (The Zookeeper issue was eventually fixed as I recall, but by then the damage was done in terms of political capital spent and lost.)

The big issues didn't really have that much to do with the persistent store of events. The bigger issue was the fact that as new features get added to your application, your event payloads change. Well, in order for projection (particularly re-projection in the case of an issue) to work, your code needs to know how to read and process all versions of every event. Of course, there are techniques like snapshotting to give you point in time "good states" so you can eventually deprecate some of these events, but thinking about it is challenging.

Additionally, most folks argue that the event store should be immutable. This is great until some kind of bad event gets in there. Now your code needs to know how read, and discard, this bad event forever (or until a snapshotted point in time).

Finally, projection is not the panacea the evangelists will have you believe. Inevitably there will syncing issues between the event store and the projected database/elasticsearch cluster/mongo instance whatever. And what do you do then? Re-project! But that is not easy :)

Re: Building a CQRS/ES web application in Elixir using Phoenix

#12

Post by eric_b »

baconforce wrote: post #10
eric_b wrote: post #6

I have worked on, or cleaned up, 4 different CQRS/ES projects. They have all failed. Each time the people leading the project and championing the architecture were smart, capable, technically adept folks, but they couldn't make it work. There's more than one flavor of this particular arch, but Event Sourcing in general is simply not very useful for most projects. I'm sure there are use cases where it shines, but I ha…

Would love to hear about your experience and why CQRS/ES failed those projects, and what type of technical complexities it introduced.

I detailed some of the problems I saw in another thread, but one other thing that gets challenging is the CQRS side (if you choose to keep everything async).

For example, say you fire an "address change" event. That gets sent to the event store for eventual projection in to a medium you can actually query from (realtime querying of the event store itself is the road to very bad places, I promise). So now your event is sent along, but how do you know when it has been processed/projected? What if there was a conflict with another address change event from somewhere else? How does that bubble back up?

The typical solution is to pass back some kind of "receipt token" so you can poll to see when your event is processed, then do your read from the projected database, or whatever. Of course, this can be made to work, but once you start talking edge cases and the need to support standard UX paradigms, polling for every update and handling error scenarios in this way becomes painful.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#13

Post by eric_b »

devbug wrote: post #8
eric_b wrote: post #6

I have worked on, or cleaned up, 4 different CQRS/ES projects. They have all failed. Each time the people leading the project and championing the architecture were smart, capable, technically adept folks, but they couldn't make it work. There's more than one flavor of this particular arch, but Event Sourcing in general is simply not very useful for most projects. I'm sure there are use cases where it shines, but I ha…

Do you mind detailing your experience with Dataomic? We're looking at ways to store 6-ary tuples (quadstore + temporality of existence and temporality of observation) of facts and build indices on top of them. I'm hesitant to move to (relatively) obscure data store without a really good idea of where that puts us.

We didn't get terribly far down the road with Datomic. Management/administration of the DB was not for the faint of heart. (At the time the docs were simply terrible, maybe they are better now?) We would see data corruption/loss as well. We weren't doing anything terribly complicated with it, and data loss doing the simplest things was unacceptable. (It's entirely likely we were the cause of the data loss somehow, but we followed the guides and did nothing crazy or weird). So anyways, we just threw it out almost immediately.

Conceptually it wasn't really a fit with the team or our application either. The query model and direct reading from the storage medium seemed silly - why not just use underlying storage medium directly for everything? (Besides, now you have to administer both Datomic and Cassandra/Oracle whatever) Not worth it for the obtuse query approach and limited value of "never forgetting" imo :)

Re: Building a CQRS/ES web application in Elixir using Phoenix

#14

Post by sb8244 »

realntl1 wrote: post #5
bglusman wrote: post #3

Earlier quoted context omitted.

Would you care to expand on what "the whole point" of CQRS is, or how they missed it? You seem to imply that the existence or creation of a library to support the pattern is, in some sense, against the spirit of the pattern, which is a) not at all obvious to me, and b) seems like something you should expand upon if you're criticising the article and/or author for HN's civil dialogue guidelines.

I think CQRS is more commonly viewed as an architectural pattern, not a code pattern, despite many definitions floating out there on the internet that focus on command/query object patterns. See this post: http://udidahan.com/2009/12/09/clarified-cqrs/ . If we view it as an architectural pattern, it becomes folly to think that CQRS can be distilled into a library.

> it becomes folly to think that CQRS can be distilled into a library

Sincerely curious about this statement. I understand that CQRS is an architectural pattern, but couldn't a library implement that architecture and then provide ways for you to implement into that architecture? You don't get to pick the architecture nuances at that point, though.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#15

Post by brightball »

eric_b wrote: post #12
baconforce wrote: post #10

Earlier quoted context omitted.

Would love to hear about your experience and why CQRS/ES failed those projects, and what type of technical complexities it introduced.

I detailed some of the problems I saw in another thread, but one other thing that gets challenging is the CQRS side (if you choose to keep everything async). For example, say you fire an "address change" event. That gets sent to the event store for eventual projection in to a medium you can actually query from (realtime querying of the event store itself is the road to very bad places, I promise). So now your event i…

Based on his article it looks like he's using subscriptions internally rather than polling. That's a fairly natural thing to do across an Elixir application/cluster.

In terms of conflict resolution, it seems like you'd have to clearly define a scenario where a conflict was possible. Based on the write-up, the state of an address would be based on the aggregate of the events that wrote to it. That seems like it would always lead to the last change winning.

From the write up of the system, I actually can't imagine trying to do this in anything other that Elixir/Erlang. The set of requirements and challenges to pull it off would be really complicated on just about any other platform.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#17

Post by karmajunkie »

sb8244 wrote: post #14
realntl1 wrote: post #5

Earlier quoted context omitted.

I think CQRS is more commonly viewed as an architectural pattern, not a code pattern, despite many definitions floating out there on the internet that focus on command/query object patterns. See this post: http://udidahan.com/2009/12/09/clarified-cqrs/ . If we view it as an architectural pattern, it becomes folly to think that CQRS can be distilled into a library.

> it becomes folly to think that CQRS can be distilled into a library Sincerely curious about this statement. I understand that CQRS is an architectural pattern, but couldn't a library implement that architecture and then provide ways for you to implement into that architecture? You don't get to pick the architecture nuances at that point, though.

At its most basic level, CQRS is frankly too simple to take on a dependency as a cornerstone of a project. You can write a single base class that handles all of the responsibilities needed. Its NOT an architecture—its an architectural tool.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#18

Post by UK-AL »

eric_b wrote: post #12
baconforce wrote: post #10

Earlier quoted context omitted.

Would love to hear about your experience and why CQRS/ES failed those projects, and what type of technical complexities it introduced.

I detailed some of the problems I saw in another thread, but one other thing that gets challenging is the CQRS side (if you choose to keep everything async). For example, say you fire an "address change" event. That gets sent to the event store for eventual projection in to a medium you can actually query from (realtime querying of the event store itself is the road to very bad places, I promise). So now your event i…

The address thing is normally solved by the fact that you organise your commands by things that should only logically change togther. So a conflict messages won't revert irrelevant fields back to their old ones.

So your commands should not be

UpdateCustomer

They should be

UpdateCustomerAddress UpdateCustomerEmail

Etc

For the address, just take the last one. All the business logic I can think makes this ok.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#19

Post by karmajunkie »

eric_b wrote: post #12
baconforce wrote: post #10

Earlier quoted context omitted.

Would love to hear about your experience and why CQRS/ES failed those projects, and what type of technical complexities it introduced.

I detailed some of the problems I saw in another thread, but one other thing that gets challenging is the CQRS side (if you choose to keep everything async). For example, say you fire an "address change" event. That gets sent to the event store for eventual projection in to a medium you can actually query from (realtime querying of the event store itself is the road to very bad places, I promise). So now your event i…

> Of course, this can be made to work, but once you start talking edge cases and the need to support standard UX paradigms, polling for every update and handling error scenarios in this way becomes painful.

This really makes me think you—and the originators of these projects you're lambasting—are working from an incomplete understanding of how to apply CQRS and ES. If you're applying CQRS in a fully async fashion, polling itself is an antipattern. That receipt token? That's what everyone else calls an ID. You know when its been processed because the subscription you should be watching tells you its been processed.

You mentioned changing event payloads in another thread. That's another big code smell to me. In a stable, well-understood domain, your payloads don't change much. If you're applying ES to a domain that ISN'T well-understood, you need to do a LOT of discovery ahead of time, or be prepared to iterate on your data until you do. It sounds like the projects you were on failed on those accounts.

Yeah, ES is hard when you keep trying to treat it like CRUD. Its overkill when you apply it to an easy domain, and its an antipattern when you write CRUD events. So don't do those things.

Re: Building a CQRS/ES web application in Elixir using Phoenix

#20

Post by UK-AL »

eric_b wrote: post #6

I have worked on, or cleaned up, 4 different CQRS/ES projects. They have all failed. Each time the people leading the project and championing the architecture were smart, capable, technically adept folks, but they couldn't make it work. There's more than one flavor of this particular arch, but Event Sourcing in general is simply not very useful for most projects. I'm sure there are use cases where it shines, but I ha…

I've worked on a successful CQRS project. It didn't use es though.

Probably one the nicest systems I've ever helped build. We had a very good lead though.

Post reply on HN