Moving past the monolith, Part 7 – Splitting up your client-side applications

This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here.


JavaScript can be modular too! On the surface, everyone knows this, and frameworks like Angular even have the concept of modules. But even with Angular modules guiding you towards modularity, it’s just as easy to create a monolith.

If you’re truly building modular applications, consider breaking the modules up into their own deployable web applications. There are so many good reasons to do this.

  • This allows us to deploy (or more importantly, not deploy) each module independently! This is a huge deal! No more regression testing the whole application when you change one part of it.
  • We can use shared modules (which contain global UI elements, CSS, and shared JavaScript classes) to make sure that all of the modules have the same look and feel.
  • If When at some point you want to switch web frameworks (and you know you will — how many of you are stuck on an AngularJS monolith when you wish you could build new stuff in a newer framework?), you can start building new things a new way without having to rewrite the rest of the application.

I really can’t emphasize that last point enough. JavaScript fatigue is a thing, and JavaScript frameworks are coming and going out of style as a ridiculous pace. Someday you (or someone you want to hire) will need to maintain your application, and I’m guessing you would much rather do that in a “modern” web framework (whatever “modern” means at the current time).

Most of you will want to create one URL that users will go to access the application, but this doesn’t mean that you can’t deploy each module independently. Use a reverse proxy like IIS URL rewriting or nginx to set up routing rules that will redirect traffic based on a url to different hosted web sites. Reverse proxy routing is different than DNS routing (which just routes a domain or subdomain to an IP address), it allows you to route based on patterns in the URL (e.g. I can route http://mysite.com/posts and http://mysite.com/users to different hosted web sites).


Read the next post in this series, Planning ahead.