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

The Way We Are Building Event-Driven Applications Is Misguided

gillesbarbier.medium.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: The Way We Are Building Event-Driven Applications Is Misguided

#61

Post by fullspectrumdev »

thebigspacefuck wrote: post #54
buster wrote: post #23

Be aware of marketing blog posts like this (looking at you Confluent, Databricks and Camunda!). Another "forget this style, only use our new framework". What he forgets to mention, and what is probably not in the scope of "our new framework that does everything better", is that it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just us…

Is medium-driven development an antipattern?

A good few years ago when I worked at a security consultancy that catered to a bunch of startups (only some of whom survived long enough to pay the invoices…) we referred to certain development patterns as “HackerNews Driven Development” lol.

I guess Medium driven development is the newer edition of this?

Re: The Way We Are Building Event-Driven Applications Is Misguided

#62

Post by seadan83 »

thaumasiotes wrote: post #50
edudobay wrote: post #44

Earlier quoted context omitted.

I think the analogy is clear when I think of it as: - Orchestration brings the idea of a conductor, who is the main reference for "what should we do" among orchestra players. - Choreography brings the idea of dancers in sync without the need of a central conductor.

> Choreography brings the idea of dancers in sync without the need of a central conductor. Try that and let me know how it works. In reality, the dancers are of course synced by the music, dependent on the same conductor as the orchestra. And on top of that, orchestration isn't the conductor's job. It's the composer's (or arranger's) job, putting it exactly parallel to choreography. The orchestrator, like the choreog…

Interesting. A counter example, WWE (wrestling) is choreographed. The wrestlers react to the cues of the other wrestlers. It's not necessarily based on time or music, but instead a pre-agreed sequence.

I think the catch is that not all cues need to be time based and that is the distinction. In orchestration, there is one source for cues - the orchestrator.

The difference I think speaks to orchestration where the players get their cues from one source, while choreography has different source(s) for cues (time/tempo perhaps being one of them)

Re: The Way We Are Building Event-Driven Applications Is Misguided

#63

Post by everforward »

The choreography pattern has always felt like a top-down solution to what is fundamentally a bottom-up problem.

Notably the article calls out tracing, which is the bottom-up solution to this. Choreography functions by dictating a flowchart that events move through, so visible comes from that dictation. Tracing functions by watching what events move from which producers to which consumers, and surfacing that organic data.

I'm not sure I see the fundamental advantage of dictating these flows rather than observing and reporting on them with some kind of internally-standardized conventions on message metadata with some standardized tooling to consume that. They seem to end up in a fairly similar situation: producers can see their consumers and vice versa, both sides need to coordinate on changes.

I really don't think it's that much boilerplate, at least compared to the pain of dealing with a choreographer that's failing to scale or just generally bad (and which you now can't replace, because everything is hand-tailored to it).

Re: The Way We Are Building Event-Driven Applications Is Misguided

#64

Post by 10000truths »

Animats wrote: post #59

Aw, it's an ad. As with yesterday's "big data" article, the usual question is whether you have enough transaction volume to need all this stuff. If you can organize your web site so that most traffic is read-only files, and the heavy machinery only turns on when somebody does a "buy" or something important, the whole problem probably fits into a CRUD app. There's a useful insight in there - fan-in and fan-out are har…

> The set-theory approach is hard to do, but promising. Each object that wants something has a small set of the things it wants. There's a big pool of such sets. There's also a big pool of the items you have, which changes constantly. It's easy to express what you need to fetch and which objects are now ready to go as set intersection and difference operations. But you need representations for big sparse sets which can do set operations fast. Probably B-trees, or something in that space.

Incremental updates to dynamic dependency graphs is a familiar problem for build tooling. I personally have used the taskflow C++ library (https://github.com/taskflow/taskflow) to great effect.

> Microsoft Research fooled around with this concept years ago in a different context. The idea was to have a database which supported pending SQL queries. The query would return new results when the database changed such that the results of the query changed. The goal was to to support that for millions of pending queries. Financial traders would love to have that. It's a very hard scaling problem. Don't know how that came out.

Incremental view maintenance is an active area of research. The likes of Noria and Materialize have done this with SQL, and the pg_ivm Postgres extension looks promising. Not sure if there is an equivalent implementation geared towards entity-component systems, though.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#65

Post by thaumasiotes »

seadan83 wrote: post #62
thaumasiotes wrote: post #50

Earlier quoted context omitted.

> Choreography brings the idea of dancers in sync without the need of a central conductor. Try that and let me know how it works. In reality, the dancers are of course synced by the music, dependent on the same conductor as the orchestra. And on top of that, orchestration isn't the conductor's job. It's the composer's (or arranger's) job, putting it exactly parallel to choreography. The orchestrator, like the choreog…

Interesting. A counter example, WWE (wrestling) is choreographed. The wrestlers react to the cues of the other wrestlers. It's not necessarily based on time or music, but instead a pre-agreed sequence. I think the catch is that not all cues need to be time based and that is the distinction. In orchestration, there is one source for cues - the orchestrator. The difference I think speaks to orchestration where the play…

> In orchestration, there is one source for cues - the orchestrator.

Just to be clear, everyone's talking about the conductor, who keeps time for the orchestra, but conductors don't do orchestration. The orchestrator is the person who wrote the score.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#66

Post by deanCommie »

Kafka is a disease.

It's a queue, it's a stream, it's a journal, it's an event bus, it's a database.

It's also apparently a workflow engine now?

It annoys me so much how appealing this is to a median developer. "Wow I just get to learn this one tool and then I can use it for EVERYTHING!" is not something competent craftsmen/professionals do in any other field, yet in software it's all the rage.

"The way we are building event-driven applications is misguided"

Maybe the way you are! Don't overcomplicate/overabstract things so much!

Re: The Way We Are Building Event-Driven Applications Is Misguided

#67

Post by Cthulhu_ »

thebigspacefuck wrote: post #54
buster wrote: post #23

Be aware of marketing blog posts like this (looking at you Confluent, Databricks and Camunda!). Another "forget this style, only use our new framework". What he forgets to mention, and what is probably not in the scope of "our new framework that does everything better", is that it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just us…

Is medium-driven development an antipattern?

Medium-driven development is neither rare nor well-done.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#68

Post by HelloNurse »

deanCommie wrote: post #66

Kafka is a disease. It's a queue, it's a stream, it's a journal, it's an event bus, it's a database. It's also apparently a workflow engine now? It annoys me so much how appealing this is to a median developer. "Wow I just get to learn this one tool and then I can use it for EVERYTHING!" is not something competent craftsmen/professionals do in any other field, yet in software it's all the rage. "The way we are buildi…

What have your predecessors done with Kafka? What did Kafka do to your predecessors? Aren't you thrilled to find out? It's enterprise enough to be an endless source of surprises!

Re: The Way We Are Building Event-Driven Applications Is Misguided

#69

Post by seadan83 »

thaumasiotes wrote: post #65
seadan83 wrote: post #62

Earlier quoted context omitted.

Interesting. A counter example, WWE (wrestling) is choreographed. The wrestlers react to the cues of the other wrestlers. It's not necessarily based on time or music, but instead a pre-agreed sequence. I think the catch is that not all cues need to be time based and that is the distinction. In orchestration, there is one source for cues - the orchestrator. The difference I think speaks to orchestration where the play…

> In orchestration, there is one source for cues - the orchestrator. Just to be clear, everyone's talking about the conductor, who keeps time for the orchestra, but conductors don't do orchestration. The orchestrator is the person who wrote the score.

Good point, for the analogy, I should have written conductor instead of orchestrator. The point remains though that the difference is in the source of synchronization.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#70

Post by bossyTeacher »

exe34 wrote: post #55
lelanthran wrote: post #48

Earlier quoted context omitted.

> Any code you didn't write today is legacy code! Any code you didn't write is legacy code!

I worked with somebody whose brain just didn't brain with mine. anything she wrote was unreadable to me, and anything I wrote was not "simple" or "understandable" enough.

Look at the biased way you write about the situation. This is the fundamental attribution error. If you can't read her code, it's her fault (you implied that). And if she can't read your code, it's also her fault (you implied that).
Post reply on HN