Live data from Hacker News

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

wix.engineering

31–40 of 112 posts

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

#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://blog.wix.e... (CTRL-F 'high throughput and low latency' for the query)

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

#32
post #27

I've done a few Tech DDs on companies who have very CRUD-like operations and oddly chose to CQRS. Mind you, these are software companies doing about $3~$10M in revenue after 10 or so years (i.e. not rapid growth, but still valuable). Honestly, my big question is...why? I can find thousands (millions?) of CRUD and MVC developers in pretty much any major language, but how many developers can I find to write CQRS based…

Boredom.

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

#33

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.

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

#34

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.

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

#35
post #27

I've done a few Tech DDs on companies who have very CRUD-like operations and oddly chose to CQRS. Mind you, these are software companies doing about $3~$10M in revenue after 10 or so years (i.e. not rapid growth, but still valuable). Honestly, my big question is...why? I can find thousands (millions?) of CRUD and MVC developers in pretty much any major language, but how many developers can I find to write CQRS based…

The answer is in your question. Because event sourcing is a niche skill, devs see it like playing on a higher level of a computer game.

But where it’s really needed, nobody would choose a novice. So novices learn to do event sourcing on systems that don’t need it, and proceed to make a huge mess. Most companies don’t have any kind of architecture review to prevent this happening - they have managers who naively trust the developers.

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

#36
post #27

I've done a few Tech DDs on companies who have very CRUD-like operations and oddly chose to CQRS. Mind you, these are software companies doing about $3~$10M in revenue after 10 or so years (i.e. not rapid growth, but still valuable). Honestly, my big question is...why? I can find thousands (millions?) of CRUD and MVC developers in pretty much any major language, but how many developers can I find to write CQRS based…

[deleted]

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

#37

As a proponent of Radical Simplicity, I'm always sceptical about event sourcing. There are some benefits (I found it useful to replay events for example), but where I have seen it at work it makes things much more complex, the understanding of the system and the development of new features takes much longer. This already starts with a command framework instead of method calls.

A competent dev experienced in event sourcing can build a system that leverages this without taking on so much cost. But… they’re expensive and hard to find. So most experiences of event sourcing look exactly like you describe.

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

#38
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.)

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

#39
post #28

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…

> 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.

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

#40
post #25

The loop will close as we once again will realise that even though domain is king of software, it is too different a beast from what the enlightened among us (not me) call "Infrastructure", the serf that actually grows the crop. Now of course, you can make the serf bend over backwards to serve the king, and use forks to work the land, because that's how kings roll; but is it really the best way to work the land? If y…

The loop will close only when we stop looking for one grand unified theory of software.
Post reply on HN