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

The Reactive Monolith – How to Move from CRUD to Event Sourcing

wix.engineering

Post reply on HN
Print view View original

41–50 of 112 posts

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#41

Post by tunesmith »

blowski wrote: post #39
copperx wrote: post #28

Earlier quoted context omitted.

> any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite a bit of hot air in his time. I've just started reading some Fowler stuff. What hot air are you referring to? I would like to keep that in mind.

People over-apply his patterns. Some patterns that are useful in niche edge cases suddenly become a ‘best practice standard’, sprayed anywhere and everywhere. My rule of thumb is that you should only use his patterns if you could afford to hire him to code it for you.

One of those books has a rule buried in the middle somewhere that I was was in 60-point text on the first page of chapter one. I've taken to calling it Rule Zero: Don't implement a pattern unless it actually solves a problem.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#42

Post by runeks »

hihihihi1234 wrote: post #38
SPBS wrote: post #31

I'm somewhat skeptical of Wix's engineering principles in general. Back in 2015 they released an article[0] about using MySQL as a better NoSQL database and talked about how joins are bad for latency, and then their example of a "fast query" used a subquery which was the same as to joining the two tables. Did they not realise that the queries would be equivalent? [0] https://web.archive.org/web/20160601000411/http://…

I'm skeptical of Wix's engineering principles because I've used their product and it's hot garbage, or at least it was 10 years ago. (I'd forgotten Wix existed.)

Go on…

What didn’t you like about their product and why does this make you doubt their engineering principles?

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#43

Post by jordanbeiber »

dmitryminkovsky wrote: post #19
0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

I second this wholeheartedly because this happened to me. I'm the kind of person who learns by my making my own mistakes (as opposed to learning from others', which is what smart people do)—and boy, did I learn a lot from the mistake of trying to build a general purpose application with event sourcing. Theoretically, event sourcing is the way all applications should be built. I was first taken by this methodology by…

I believe ES has it’s uses in discreet systems doing their thing for you.

For me ES makes perfect sense in systems handing a workflow for you. Products like Zeebe[1] and Ubers Temporal[2] comes to mind.

These systems basically becomes your business transaction log and as such ES is just a great fit. (I have no idea whether ES is used in temporal though… never looked at the code)

[1] https://github.com/camunda-cloud/zeebe

[2] https://temporal.io/

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#44

Post by runeks »

Flankk wrote: post #33
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

It's not practical. That's why all the arguments for it involve overstating and hyperbole. The results speak for themselves. It's shit.

The question is whether it’s not practical because it hasn’t received the three decades of engineering that relational databases have, or because it’s broken in theory.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#45

Post by lmm »

holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

Prevent lost writes from when two people read-modify-write at the same time. Be able to answer questions like "how did this end up like this" or "what happened to the change I made on xx/yy". Easier sharding, better performance, and avoiding deadlocks, because you're not worrying about database-level transactions any more. Much easier data migrations that you can do in a gradual, rollbackable way. Clear data provenance that lets you know how to resolve inconsistencies. Easier backups. Smoother relationship between live data and analytics/reporting.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#46

Post by jareklupinski »

dmitryminkovsky wrote: post #19
0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

I second this wholeheartedly because this happened to me. I'm the kind of person who learns by my making my own mistakes (as opposed to learning from others', which is what smart people do)—and boy, did I learn a lot from the mistake of trying to build a general purpose application with event sourcing. Theoretically, event sourcing is the way all applications should be built. I was first taken by this methodology by…

> learning from others', which is what smart people do

my grandfather had the same words :)

> What you need is PostgreSQL, perhaps with something like Hasura or postgraphile in front of it. What you need is a lightning-fast way to iterate and flesh out your idea.

optimizing my team's incoming stream stack atm, event sourcing seems so enticing on paper...

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#47

Post by classabove »

blowski wrote: post #34
holoduke wrote: post #29

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

this is absolutely terrifying

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#48

Post by blowski »

tunesmith wrote: post #41
blowski wrote: post #39

Earlier quoted context omitted.

People over-apply his patterns. Some patterns that are useful in niche edge cases suddenly become a ‘best practice standard’, sprayed anywhere and everywhere. My rule of thumb is that you should only use his patterns if you could afford to hire him to code it for you.

One of those books has a rule buried in the middle somewhere that I was was in 60-point text on the first page of chapter one. I've taken to calling it Rule Zero: Don't implement a pattern unless it actually solves a problem.

Exactly. The problem is not Martin Fowler himself, but those who pick up his books and ignore those warnings.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#49

Post by he0001 »

I had this team of consultants which sole purpose was to introduce an ES system, it was my predecessor that had decided this. The consultants were “experts” on building this kind of system. Very long story short, it failed miserably with a completely broke system which was hard to test, failed pretty much all use cases and completely blew budget. According to the team there were many reasons why the project failed, one was they the requirements were complex. This also manifested in that implementing some of these requirements had “close to infinite” amount of combinations. Never understood that but that was one of the explanations. We shut down the project and made a “traditional” solution instead.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#50

Post by jordanbeiber »

he0001 wrote: post #49

I had this team of consultants which sole purpose was to introduce an ES system, it was my predecessor that had decided this. The consultants were “experts” on building this kind of system. Very long story short, it failed miserably with a completely broke system which was hard to test, failed pretty much all use cases and completely blew budget. According to the team there were many reasons why the project failed, o…

I know you’re not me, but here I am, pretty much in the same boat.

The word ”traditional” have also been thrown around.

Post reply on HN