Designing scalable Angular applications

Oleg Varaksin
Jan 13, 2019 · 6 min read
Image for post
Image for post
Image for post
Image for post
  • UI components and the entire application become better testable. We can more easier mock the application’s parts.
  • Better separation of concerns. Components don’t need to know who provides the data and where they save the data. The communication between application layers occurs through well-defined API.
  • Software artifacts in separate layers can be developed in isolation.
  • Immutable application’s state which allows to boost performance of Angular apps by using OnPush ChangeDetection.
  • Truly debuggable applications because you can always reproduce the past state (time-travel debugging!).
  • Unidirectional data flow. Such data flow leads to less failures.
  • In GUIs with Canvas / WebGL graphics. These kinds of GUIs don’t have HTML markup for every graphic element. Only a canvas tag is present in the DOM. Therefore, only one component’s template would be exist. Writing a component per graphic element has no sense.
  • In web apps with complex workflows. It is not clear where to place a “workflow orchestrator”. A new extra layer for that is overengineering.
  • Sometimes, presentational components should work with services too, to avoid repetitive inputs and outputs in a larger component tree with deep nested components. You can read about this issue in this article: Angular Architecture — Container vs Presentational Components Common Design Pitfalls.
  • The software is sliced vertically too. When slicing vertically, we group software artifacts by feature modules. Feature modules are well-known in the Angular world. There is a common feature module having features shared among other feature modules.
  • The data flow into the following direction: Service layer → Facade layer → View layer. The emitting events, executing logics, dispatching state management actions go into the opposite direction: View layer → Facade layer → Service layer.
  • Business logic resides in smart components and smart facades. In my opinion, the term “smart” fits better a piece of software with business or workflow logic because the term “container” is misleading for that (read the mentioned above article). View related logic, triggered by user, normally resides in smart components. But there is also logic such as workflow steps, that reside in facades. I suggest to call such facade a smart facade (similar to smart component). This is especially a case when you have a bidrectionnal communication and the data in real-tme (e.g. over WebSocket).
  • View layers of separate modules should not depend on each other. For instance, the view part of “Some Feature Module” should not have dependencies from the view part of “Other Feature Module”. The view layer of one module can inject several facade layers from every other module.
  • Facade layers of separate modules may communicate horizontally with each other. By this way, the view layer of one module has an indirect access to every service across the whole application.
  • What is about the service layer? In my opinion, the service layers of separate modules can also communicate horizontally with each other (optional if needed).
Image for post
Image for post
Image for post
Image for post

Layer view

Image for post
Image for post

Module view

Image for post
Image for post

Angular In Depth

The place where advanced Angular concepts are explained

Sign up for The Deep Dive

By Angular In Depth

A newsletter with focus on advanced web development, written and curated by Max Koretskyi and inDepth.dev team. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Oleg Varaksin

Written by

Thoughts on software development. Author of “PrimeFaces Cookbook” and “Angular UI Development with PrimeNG”. My old blog: http://ovaraksin.blogspot.de

Angular In Depth

The place where advanced Angular concepts are explained

Oleg Varaksin

Written by

Thoughts on software development. Author of “PrimeFaces Cookbook” and “Angular UI Development with PrimeNG”. My old blog: http://ovaraksin.blogspot.de

Angular In Depth

The place where advanced Angular concepts are explained

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app