UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the d

UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the design/review stage, but also at runtime. So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change. Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results. Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem. What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API'). GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure. But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.