Accueil > professional > Event driven architecture should be a must go (esp. for client side JavaScript)!

Event driven architecture should be a must go (esp. for client side JavaScript)!

While reading Getting Started with Twitter Flight, I realized that only events provided an effective decoupling between data producers and consumers. Not Object Oriented Programming. Not services. Sounds crazy? Sounds wrong? Read on and let me know.

At first, with events, some benefits immediately pop up:
– internal changes have not effect on external code. None at all. No renaming or bigger change affect the other components, even the ones depending on this component (as long as the event itself is untouched).
– willing to change the event? Just have a look to who depends on it. No need to try to track use of some service/object/whatnot all the way through your application. And in JavaScript, doing so would be especially bad: no type, no compiler. Only plain text search through methods name (at best). Good luck with that. And if others depend on your code, well, they’re basically screwed. With events, it’s way simpler to do changes. Even deciding to version public events could be easy.

But, actually, events provide way more: they decouple events producers from listeners. Sounds trivial, for sure, but going deeper it means no need to inject some service, register somehow somewhere for callbacks, no need to look at an object with plenty of methods/stuff in it. The API to communicate with others parts of the software is actually uniform! You won’t have a specific way of doing it for each need. You just want the payload, no need to read some non existing documentation to figure out to use the crap.

The mental noise is tremendously reduced. You need to signal something to others? Easy, fire an event. You want to know of something? Easy, listen to the event. That’s true decoupling, way more that some abstract FooService with plenty of methods, related objects and extra funky behaviors or dependencies. Just the stuff you need, always through the same mechanism.

What does it mean in practice?

Well, very nice stuff:
– willing to test something when receiving an event? Plain simple, just fire it! No need to mock or whatnot the sender.
– needing to add 10 new ways of firing the same event in the UI? Plain simple, you just fire the event in the new places and all the listeners will get them. No need to change the listeners!
– you need to kill some component and fire the same event in a different way? Fear not, delete without looking anywhere else and produce the same event wherever you need it.
– you rely on some external component that you want to swap for something better. For sure, since you’re on the UI side, you didn’t code defensively. So you’ve plenty of reference to the old component’s events. Screwed? Not at all, write a component translating the events from the new format to the old one and… done!

Such ease of coding is something I would love to have whatever the language, be it Java, Scala and even more JavaScript, which has way less tooling for code exploration and refactoring.

It made me realized a funny point: Object Oriented Programming (OOP) came with the concepts of objects to encapsulate logic and data, and (public) methods to communicate with others objects. Actually, in the beginning of OOP, methods where sometimes called messages. It’s still used and visible in Ruby nowadays. Theses messages were supposed to help decoupling. The internals would be nicely hidden from the others, only the stuff needed by the outside would be visible.

Yet, in fact, you can’t get the message/public method without the object. And the object doesn’t come for free. You need to get an hand on it, to figure out what it intends you to do and so forth. The decoupling aspect of methods is pretty bad in the end. Whereas for events, it’s all bright and sunny 😉 You can get the message without the object mess. Crazily good no ? And you can change the internal, even drastically (aka delete), without affecting the outside at all.

It sounds like the Single responsibility principle done right isn’t it? Damned, I tried for so long to do that in plain old OOP…

Anyway, thanks a lot Tom, the author of Getting Started with Twitter Flight, for having made me realize this point so clearly.

All is not rosy though for sure. Infrastructure code, utilities, libraries and the like may still be used in many different parts of the same application. However, this kind of code is generally pretty focused, trying to do one thing well, and has few, if any, state. As such it’s easily testable and refactoring is seldom needed. Should the need arise, it’s generally pretty strait forward. Domain related code is a completely different story: state is everywhere, refactoring frequent. So an event driven architecture, if only for domain and application level code, already provides plenty. And is, IMHO, way better than all the alternatives I know of as of now.

Publicités
Étiquettes : , , ,
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :