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

41–50 of 81 posts

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

#41

Post by inopinatus »

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 strongly believe it is the wrong choice for just about every application.

None of these are pure as-originally-outlined-by-Fowler CQRS/ES, but I'm willing to suggest they are paradigm equivalent, real world successful examples:

1. Basically all double-entry accounting/book-keeping/core banking systems.

2. Many RDBMSes. Specifically the replayable log structure of transactions.

3. I sell a service that includes two event-sourced data structures mutated by domain-specific commands. They are used for collaborative decision making in sports management. This aspect works very well indeed: the resulting characteristics are intrinsic to ES structures, are (AFAIK) unique in our market, and represent one of our most customer-retaining capabilities.

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

#42

Post by zdbo »

UK-AL wrote: post #20
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.

Absolutely. I use CQRS fairly regularly, but I've never used ES on production software and I can't think of a case where it would have been appropriate. It's a serious solution that is not trivial to implement.

CQRS is a highly understandable, almost always reasonable technique to follow when you strip away all the other things that people tend to associate it with.

This is a pretty decent article on that: https://lostechies.com/jimmybogard/2012/08/22/busting-some-c...

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

#43

Post by ehsanu1 »

eric_b wrote: post #35
jen20 wrote: post #33

Earlier quoted context omitted.

I would be interested to know why you consider ES "not production ready". There have been zero reported incidents of data loss in stable released versions which were not as a result of catastrophic failure of the hardware on which it was running (though most people's poor understanding of Azure has caused more problems than everything else put together). Furthermore, this should be no surprise given the testing proce…

We had no data loss incidents. My concern was around tooling and maintenance of the database. Once you had to start clearing out bad events in dev environments or doing common administrative chores there were many holes. I never did find out how to remove specific problem events. We ended up just purging the store every time something went wrong in lower environments. We had no solution for this problem in prod. How…

Not saying this is great, and I don't have experience with an ES system in production, but... Could you do one of:

1. Manually remove the specific problem event from the store, then re-run all events starting from the previous accumulated state snapshot stored before that event? Then you get the new state snapshot just by re-processing all the events. This of course assumes you have state snapshots, and may not be feasible if this is a common occurrence and there are too many events to process.

Or:

2. Create a "reverse" event? This will cancel out the bad change and give you a new, valid state to work from and continue. This is nice since the historical state of the system is still represented, but that may be a disadvantage in some situations.

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

#44

Post by ouro »

eric_b wrote: post #35
jen20 wrote: post #33

Earlier quoted context omitted.

I would be interested to know why you consider ES "not production ready". There have been zero reported incidents of data loss in stable released versions which were not as a result of catastrophic failure of the hardware on which it was running (though most people's poor understanding of Azure has caused more problems than everything else put together). Furthermore, this should be no surprise given the testing proce…

We had no data loss incidents. My concern was around tooling and maintenance of the database. Once you had to start clearing out bad events in dev environments or doing common administrative chores there were many holes. I never did find out how to remove specific problem events. We ended up just purging the store every time something went wrong in lower environments. We had no solution for this problem in prod. How…

I can see why your projects failed. That EventStore does not support you editing an event is not something that makes it "not production ready" it is in fact a feature that keeps you from doing stupid things.

If you go and edit an event, how do subscribers receive that edit? Let's imagine I have a projection updating a sql db and you now edit an event,how will this projection receive the edit?

"We had no solution for this problem in prod. How would you fix an event that should not have gotten in to the store? (Wrong contract, bad data etc) I understand it shouldn't happen, but in the real world all kinds of things go wrong."

You should do some more research into eventsourced systems as there are patterns for handling these exact scenarios. http://files.movereem.nl/2017saner-eventsourcing.pdf discusses some. In your scenario the most common is read the problem stream out, write it to a new stream (with any changes that you want) then either delete the old stream or leave a last event in the old stream saying it has been migrated to the new stream.

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

#45

Post by ouro »

ehsanu1 wrote: post #43
eric_b wrote: post #35

Earlier quoted context omitted.

We had no data loss incidents. My concern was around tooling and maintenance of the database. Once you had to start clearing out bad events in dev environments or doing common administrative chores there were many holes. I never did find out how to remove specific problem events. We ended up just purging the store every time something went wrong in lower environments. We had no solution for this problem in prod. How…

Not saying this is great, and I don't have experience with an ES system in production, but... Could you do one of: 1. Manually remove the specific problem event from the store, then re-run all events starting from the previous accumulated state snapshot stored before that event? Then you get the new state snapshot just by re-processing all the events. This of course assumes you have state snapshots, and may not be fe…

my answer above ^^ assumes we really want to remove it. compensating actions are generally the preferred option

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

#46

Post by spuz »

eric_b wrote: post #11
ryanworl wrote: post #9

Earlier quoted context omitted.

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…

We use the strategy of versioned events. Event data is still immutable, but older events are upgraded to the latest structure at read time. This works reasonably well but it is not ideal.

Storing data as immutable events implies that all data ever generated by your application becomes available to future versions of your application. Writing an application that can handle all the forms of your data across time is obviously more complex but it's a necessary consideration if you decide to go with event sourcing. Unfortunately, you cannot have all the benefits of available and useful unaltered historical data without also putting in the engineering effort to support it.

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

#47

Post by davidcaseria »

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.

I work for a finance startup that uses Akka Persistence to implement an event sourced architecture. It has worked pretty well for us, much better than the original CRUD system. Akka can support a variety of different databases via journal plugins which has allowed us to maintain using a SQL database instead of being forced to adopt an unproven database.

The one area we've struggled with in the architecture is the query/projection side. Recently we have decided to completely separate the projection logic into a different application that is deployed independently to mitigate some of the issues we have been having.

http://doc.akka.io/docs/akka/2.4/scala/persistence.html

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

#48

Post by Terr_ »

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.

IMO it's a bit like talking about a "Facade Framework".

Using facades to encapsulate multiple complex objects behind a simpler interface may be an important of your overall design, but even if you use them it a lot you probably don't need (or want) to build a "Facade Framework" that lets you instantly define new ones with a few lines of meta-code.

Any code you make for reuse by other people is going to contain something more in order to have value to them. For example, "A Facade library for dealing with various cloud services".

Relating it back to CRQS, compare "CQRS Framework" to "A CQRS framework for command-line applications" or "A CQRS framework for websites". The CQRS-ness is a quality that can't stand just on its own.

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

#49

Post by btown »

slashdotdash wrote: post #37
eric_b wrote: post #12

Earlier quoted context omitted.

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…

Pushing read model updates back to the client using a two way communication channel is one technical solution. I want to experiment with using Phoenix channels[1] to solve this. I think that has potential for easing the UI/UX concerns. You post a command from the web front-end and subscribe to receive updates for the read model you're looking at. Domain events can drive the client notification. [1] http://www.phoenix…

If you can write your read model into Mongo, then you can use Meteor to build a real time interface extremely quickly; it tails the database log and dispatches updated records to subscribers practically instantly over websockets, no need for the event processing code to know about how to map to frontend queries. We use this for our production CRM, albeit for internal users. No doubt Phoenix would be more performant and support more databases, but it's nontrivial to build the record-to-subscriber reverse mapping that Meteor brings out of the box. RethinkDB was going to be the Chosen One for this use case, alas...

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

#50

Post by ehsanu1 »

davidcaseria wrote: post #47
ryanworl wrote: post #9

Earlier quoted context omitted.

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.

I work for a finance startup that uses Akka Persistence to implement an event sourced architecture. It has worked pretty well for us, much better than the original CRUD system. Akka can support a variety of different databases via journal plugins which has allowed us to maintain using a SQL database instead of being forced to adopt an unproven database. The one area we've struggled with in the architecture is the que…

Just curious, what issues did you have that were solved by an independent projection application?
Post reply on HN