DEV Community

loading...

Discussion on: Redux is half of a pattern (1/2)

davidkpiano profile image
David K. 🎹 Author

Go write a post then.

Thread Thread
rodocite profile image
Rodolfo Yabut

I am working on it.

But I'm not prolific and it is something I know that gets even the event sourcing community heated. Only reason why I chimed in is because you are prolific and I think you have a chance at giving a ton of people an aha moment that isn't in the wrong direction.

If you want to research for your follow up blog post, check out how similar these are to Redux and Redux sagas:

In particular, the event handlers:
github.com/commanded/commanded

Projections:
eventstore.org/docs/projections/in...

Discussion on sagas and handlers:
stackoverflow.com/questions/342846...

Can't deny how close the patterns match up. I mean the EventStore Projection API is basically what we know as a reducer. Event Store was made back in 2012.

But I will say that in infrastructure, people misunderstand and do all sorts of weird event sourcing patterns. If you had a good evented model in your infrastructure that represented state pretty well, complex stream transforms in Redux (and Redux itself) starts to disappear because the work has been done for the UI.

The only reason why we needed Redux in the first place was because we needed to model some type of complex state representation that the backend didn't give us. If the state is computed in the infrastructure and the UI as a service just receives it, where is the role in Redux other than acting as a global store or a pubsub? And even then, with GraphQL and Apollo + cache, Redux's complexity and importance starts to disappear.

Thread Thread
boubiyeah profile image
Alex Galays

Time to eat some much needed humble pie Rodolfo; you want to push your point of view so hard...
Redux is absolutely not event sourcing (I used both extensively)
The only thing in common is that there are "events", something extremely common and found in pretty much all codebases (and the dreaded DOM)

No frontend keep all the events from last week around for the logged user, it's slow enough as it is. If you don't keep all the events, then it's not sourcing, just event driven (like almost all UI paradigms from the last decades)
Trying to find similarities between very different architectures might help you learn new things, but there's not point pushing this tool down people's throat.

Thread Thread
rodocite profile image
Rodolfo Yabut

You wanna mansplain me more? Maybe you can explain how React works, too. Insult me because you think I'm using analogies as learning tools (although that is absolutely completely valid)?

Actually, I think you should eat some humble pie. I am bringing up a legitimate comparison and I have used both extensively as well.

Your argument doesn't make sense and is just a nitpick. You in fact DO keep all the events in context of the lifetime of your frontend. If you do not choose to persist them after the browser closes or refreshes, that's your choice. But the implementation itself matches event sourcing. You are using an event store, running projections off of them, and using those projections in your read model. You can even replay your events to regenerate your state. If it looks like a duck, talks like a duck?

Also, there are event streams that terminate in event sourcing, you know. You could think of a browser session as a unique event stream with a prefix "ui-1", "ui-2", etc.

But again, the main point is: in context of the UI's session lifetime, the events are not ephemeral and you are indeed keeping all the events.

As for speed, the implementation of Redux might be slow, but updating state per event is one of the reasons why people use event sourcing in infrastructure-- to do relatively complex and flexible compute "realtime" without having to iterate through large sets.

The "slowness" is due to the growing event store which is a problem in ALL event sourcing implementations. In infrastructure, you typically cold storage "really old events".

If you don't have the flexibility to see the valid comparison, I doubt you've used both as much as you say or you haven't really thought about it. The similarities go FAR beyond analogies and learning helpers.

In fact, if you took the event storage itself and persisted it, you now have a way to recover complete session state through replay. Though UI state isn't so complex or critical that you can't just persist the state itself versus doing a replay from the events. It would be useful if you wanted to track clickstream and state transitions beyond 1 session. Which some people might want to do.

As I said in a previous post, other than purely UI state, we needed Redux to model complex domain state that the infrastructure should have already given us. If the we already had that state, we wouldn't need to mirror what many scaled infrastructures use for our frontend. The reason you remove Redux is you already HAVE the state you need. But I think the pattern itself is a pretty important entry drug (although contentious because people do it in so many different ways) concept that could help launch people who know React and have only worked in React to understand how distributed systems manage state and data.

React is already very good training in SOLID. And as a result, a lot of the component patterns you see fundamentally match up closely with supervision tree models in distributed systems. Now THIS next statement is me using an analogy, but if you diagram a supervision tree and don't label it and just describe it in terms of supervision tree definitions, then tell people to label it in terms of React Components, they will surprisingly know how to.

Thread Thread
joeyorlando profile image
Joey Orlando

@Rodolfo you’re my hero πŸ€™πŸΌ