The Way We Are Building Event-Driven Applications Is Misguided
gillesbarbier.medium.com
The Way We Are Building Event-Driven Applications Is Misguided
1–10 of 71 posts
Re: The Way We Are Building Event-Driven Applications Is Misguided
#2Re: The Way We Are Building Event-Driven Applications Is Misguided
#3In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
> Creator of Infinitic orchestration engine (docs.infinitic.io). Building in public at infinitic.substack.com. Previously founder at Zenaton and director at The Family.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#4In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#5In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
Shame it’s on Medium, so I immediately get a paywall / ad, and don’t end up reading your post.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#6In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
Shame it’s on Medium, so I immediately get a paywall / ad, and don’t end up reading your post.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#7In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
Interesting article Gilles (design patterns are fun!) but in the future maybe worth giving some form of disclosure in the comments. > Creator of Infinitic orchestration engine (docs.infinitic.io). Building in public at infinitic.substack.com. Previously founder at Zenaton and director at The Family.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#8Re: The Way We Are Building Event-Driven Applications Is Misguided
#9You write:
There is no easy way to understand how a specific business process is actually implemented. The whole process is defined by how each service reacts to others. There is no central repository, and the implementation details of business processes are scattered everywhere.
Yes, indeed. There is no easy way because the total system architecture is implicitly defined by the interactions of the components.
There is currently no way to actually express the architecture of such a system as runnable/testable and running code. You have the options of either (a) documenting the architecture or (b) leaving it to be defined implicitly.
Re: The Way We Are Building Event-Driven Applications Is Misguided
#10Another (maybe more mature) alternative to Infinitic is Camunda, who have been pushing this rhetoric for over a decade.
My problem with both is that neither feel very modern, in the sense that they are tied to (in Infinitic's case) or strongly favor (in Camunda's case) Java-centric development, don't have a great developer experience story, and don't feel very cohesive with the language.
What I'd love to see is someone tackling this for smaller orgs where the above tradeoff in developer experience isn't worth the gains, i.e. orgs with Camunda requires too many magic strings and schemas to be kept consistent across services for that, and Infinitic forces me to use Java or Kotlin which I don't want.
A "simple" solution might be to have declarative process and schema definitions in some DSL for version control, which auto-generates schemas, types etc in whatever language, giving me both strong types, intuitive local development, and clear deployment story through my existing CI/CD.