Put Down the Redux: A Case for Distributed Client Side React.js Apps.
Flux-based architectures have been a wonderful boon to the development community. Frameworks such as Redux and Mobx offer a comprehensive way to wrangle complex state. But there’s often a cost: the complexity of the client side applications tends to explode. We are living in a world of front-end monoliths.
The solution? Break client side apps into smaller, pre-rendered applications with simpler or no state. Easy, right? The implementation is fairly straight forward, but knowing when and why to break up your application is where the magic happens.
When should you split your application?
Feel like your state is getting too nested on the client? That can be a good indication that the logical complexity of your application has grown and it might be time to start breaking it down into smaller pieces. Another common indicator is a rise in merge conflicts on teams as small as eight developers, even while working issues that are mostly in separate sections of the code base. This may indicate a deeper problem with CI/CD and the confidence and cadence of your deployments, but breaking apart the application will help alleviate the conflicts by reducing the surface area of largely isolated sections of the code interacting with each other.
However, there are times when you should *not* break apart your client-side app. Each time you break your app apart, you will need a new URL path to point to the new smaller app. Will this affect your company’s SEO strategy? Another consideration is that you are adding the overhead of creating new repositories and setting up new CI. Smaller teams in the range of one to two developers may find the extra overhead outweighs the benefits.
Where should you split your application?
Usually, break your application where you find discreet different views, ideally where you can have the new application render mostly as a pure function to which you can pass state easily via the URL or JWTs. This will typically coincide with major routes in the overall application, and often where you’re code splitting. Code splitting is a great way to reduce the initial payload of our website, but it doesn’t do anything to stop us from making logical monoliths. By the same token, splitting apart our application can help us to break up a monolith, but it is not necessarily the be all end all in reducing payload size. Code splitting can be used on a much more granular level to shave off kilobytes, especially when the majority of a view does not change. Code splitting and breaking apart your application should be used in concert. One should not be used to replace the other.
There should be one final question that is nagging at you by this point. Breaking apart a monolith is all well and good, but how do I deal with code reuse and transclusion? It is an excellent question, and at this point I would ask you not to think about how to reuse code across your *application*, but how to reuse code across your *organization*. Web components are an excellent way to share atomic styled elements across your applications. You can host components for things like buttons or simple nav bars on a CDN that multiple applications can all pull in, and it will ensure consistent styling and behavior throughout your properties, and allow you to maintain them all in one spot regardless of what framework the application is using. If you want to reuse more complex components, you can still compose them from multiple simpler web components, but you might want to create a React library in npm instead. You lose out on the ability to pull the more complex components into non React projects, but higher level complexity can be easier to manage in React than the composition of web components.
Flux-based architecture can be a very useful tool, but know when, where, and why to use it. Don’t use Flux as a crutch to build overly complex or heavy client side SPAs. Instead, identify meaningfully large sections of your applications that can be abstracted out to reduce complexity and contention. By following these guidelines, we can create smaller, simpler, and faster client side applications that are easier to maintain.
