For best reading experience we recomend turning the music on while you read.

Usually when we build any app we are faced with choices what to do once it grows so that we dont kick ourselves in the face after one year with our bad decisions.

So far as JavaScript apps keep growing we’ve seen people:

  • relying more and more on reactive functional programming to manage the complexity.
  • using concepts like redux to streamline state management. Like react boilerplate does.
  • using well proven google made architectures in frameworks as angular that convey google experiences with large scale apps.
  • using even ideas like making javascript microservice architecture(there was one project I saw that even took this idea somewhere with some clever tricks)
  • twitter five years ago released flightjs that is actor model based framework
  • using rails like architecture in emberjs

All these things are nice attempts by engineers to scale things up. Topic of our discussion is if we build our apps by adding more and more components how do we scale if we use for example react and redux.

I’d advocate that way to go when scaling react based redux apps or even if they have some reactivejs is to combine them with the actor model. Or of course google did not come up with something that works and then ingraned it into angular you should be able to do it that way too then :-D.

We’ve seen even Alan Kay appologize for OOP in recent years so making some OOP design pattern style solution for your app to scale things up seems expensive. Google can make things and then sublime their experiences in angular and thats fine but it might be bit pricey for rest of us.

What I advocate for is that if components are done in a way react boilerplate offers them, then each of these components can effectively be an actor. Just like twitter flight does it. Going this way pretty much implies that we can scale for long long time.

We are not inventing much here we are what industry battle tested for decades when it comes to scale. We just have to discipline ourselves and make componens in this style and who knows in the future someone might encode this discipline into framework on top of react boilerplate.

This I’d say would trully unleash the power of react boilerplate and take this amazing project further.

To elaborate:
React boilerplate gives already actions in a container component that one uses for message passing. There is also sagas for data fetching so you might think like well its already there. Main issue one faces when adding more and more components is that sometimes when growing the app we are forced to move state management accross components or elevate level where component state managers are mounted.

If one does not invest thought about organizing state management with redux then managing state for various business logic concepts can end up scattered throughout the components. Once app grows it can be harder to maintain and organize.

What I had in mind is that when thinking where to manage state for certain business need is to try to do it by thinking of each component as an actor.

When we think of components as an actors we tend to localize state management more than if we’d just let app grow as we see the need. With more localization of the state we can respond to app wide signals within that component instead of letting the data leave it and have it be responsibility of some other part of the app.

You can have your components send data around without any organisation and then let other parts of the app somehow manage. When your component could have kept the data in its state localy because we thought of it as an actor. Then have component itself deal with the data on external signals. This way you clearly outline future growth of the app. You no longer think can my next feature fit in somehow given that data that I need ends up from A to B to XYZ instead you feel that you can add things easily because all it takes is to add proper signaling and change relevant parts and it feels just as it should be.