Discussion on: What's your worst nightmare as a coder?

View post

Event-driven architectures.

It's basically no different from a goto statement, and we've known for a long time that gotos are considered harmful. Applications which use events to drive data flow and logic become impossible to navigate, which makes them impossible to maintain.

Paramanantham Harrison • Jun 15 '19

Wow. Want to hear more on this. I believe, not the architecture but the worst implementation which is harmful.
Event driven architecture works for many use cases.

Casey Brooks • Jun 15 '19 • Edited

You're exactly right, events by themselves are not bad, and can be very useful in large, modular codebases. But a bad implementation will only get worse over time, and the nature of it makes it nearly impossible to recover from beyond a certain point.

The problem is when the app is driven by events. When one event triggers another event, which triggers another, etc. One of the most extreme examples of this is WordPress, where in it's internals methods are rarely called on their own. They mostly call each other through events, which, while they can be augmented and overridden, means tools like static analyzers can't help, you don't have good stack traces, exception handling gets confusing. As a result, you really can't refactor that code anymore, since you can't really figure out who's all listening for the event anymore. But I've personally worked with many other examples in Android, JS, and PHP.

The alternative is to only use events as a reaction. Keep the logical path in normal function calls, send events as "notifications" instead, to broadcast what you just did or what you're about to do, without altering the execution flow.

Paramanantham Harrison • Jun 15 '19

Awesome point. Totally agree

Kirill Shestakov • Jun 17 '19

I have a feeling there is a lot more to be said about this, and I think you maybe right and those architectures should be considered as anti-patterns. The biggest problem I find with event-driven stuff is how easy it is to lose track of what is happening, and how easy it is to introduce circular event triggering. I think the cleaner architecture would mean that it would be actually impossible to introduce a circular dependency. For example, it could be done similarly to the creation of objects. If you have classes:

class A {
    b: B;
    constructor(b: B) {
        this.b = b;
    }
}

class B {
    a: A;
    constructor(a: A) {
        this.a = a;
    }
}

It would be impossible to have a circular dependency such as above, because the creation of A's instance requires a B's instance, while the creation of B's instance requires an A's instance. So, you'll not be able to successfully run

let a = new A(); // Error - need an instance of B as the 1st argument
let b = new B(a);

I think a similar way of thinking should be applied to events.