Splitting your angular app to modules: performance, code & time complexity.

Splitting your angular app to modules: performance, code & time complexity.

In this article we will explore the effects of refactoring of our application from a single NgModue to multiple ones, from 3 aspects:

  1. Code complexity & architecture
  2. Performance
  3. Development time

The story behind it, we have started to work on our project 8 months ago, and our goal was to deliver an MVP as fast as we can. This led us to using a single NgModule and messy code as we only focused on delivering business value. By now we have demoed our app a few times and it seems there is a genuine need for it on the market so we have to keep the balance between performance, extensibility, and delivering features. This led me to refactor the app a bit.

 

Code complexity & architecture (Before refactoring)

Lets see the starting state of the app, architecture wise there’s one module which contains all of the components, which is not great because this way we do not take advantage of the advanced capabilities of the Angular DI engine, the vertical separation isn’t the greatest between functionality also at application start it has to initialize all of the components, even though 99% of the users will not use the admin site.

 

 

Code complexity & architecture (After refactoring)

After refactoring the vertical separation became much better, Its much cleaner which component belongs where. The code didn’t become any complex except for the new files which describe the component, basically instead of one huge module we have 3 smaller ones. Our god module  has been divided.

 

Performance

We can look at the following metrics:

  • Script evaluation (main.js)
  • Javascript boot up time
  • Page load (Time to interactive)

(Page load isn’t that relevant in this case because it is affected by other things aswell like images, but its still somewhat useful to see.)

What I did is built the pre-refactor app and the refactored one with the production setup, source map, gzipped the js and html files in the root folder.

rm -rf dist/ && ng build --prod --source-map && gzip -r dist/*.js -9 && gzip -r -9 dist/*.html

And served it with http-server. I have used Chrome devtools and Lighthouse for benchmarking the application.

optimization outcome
optimization outcome

With the optimization we maged to reduce

  • Script evaluation (main.js) by 39%
  • Javascript boot up time by 22%
  • Page load (Time to interactive) by 12%

Which are not huge numbers but they require such a small investment that its a no brainer.

The routes became more concise:

Routes before refactoring

 

Routes after refactoring

Development time:

The application has ~100 components/16KLOC the refactor took around a day of work.

Conclusion:

If your application is going to stay small ~20-50 components youre welcome to just keep them in one module, but after that it has its advantages to keep things separate, your architecture will be cleaner, new developers will be able to ramp up quicker and the performance will be better. In the end it doesn’t have any drawbacks to use NgModules and to have nice horizontal separation.

TLDR;

Use NgModules

 


Leave a Reply

Your email address will not be published. Required fields are marked *