Modern Frontend Architecture 101

Understanding what matters, away from javascript fatigue and framework wars

A couple of weeks ago, my fellow backend developers were curious about our frontend architecture, code structure and challenges. After a couple of presentations on how to build scalable and robust frontends, I thought it would be a good idea to sum it all up and share our strategy with the community. Without further ado, here is the first part.

Update 1: The second part is already out !(Click here to check it out)
Update 2: The third part is already out !(Click here to check it out)

Let’s start by having a look at a typical web page 👀

A typical web page

A normal user would see vertical and horizontal bars, a main content with a list of artifacts and a chart but for a frontend developer, there are only components (VBarComponent, HBarComponent, OverviewComponent, ..etc).

Webpage from a frontend developer’s perspective

These components are laid out in the form of a tree which starts with a root node usually referred to as main component. Every modern frontend App must have at least one component (aka the main component).

This tree is the foundation of component based architecture. We will see from this point onward how it drives every aspect of the frontend world.

Analyzing the tree 🔎

One can quickly notice that components laid on the same branch work together to deliver an independant and coherent feature for the user. However, the shape of the branch may differ from one feature to another depending on how it’s displayed and which business value it provides.

This diversity makes code structuring a challenge because unlike backend, there is no standard n-layer architecture to help organize the files of the App.

An example of n-layer architecture

The solution here is to be driven by features rather than the layer type. Every feature will group its components inside a subfolder, thus helping developers understand where to add a new component while staying flexible to any possible shape of the branch.

AppRepo
 │  
 ├──/Overview                      * Overview feature folder
 |   ├──/Components                * Components folder
 |      ├──/ListComponent          * List component
 │      └──/ChartComponent         * Chart component
 │
 ├──/Details                       * Details feature folder
     ├──/Components                * Components folder
        ├──SomeComponent           * Some component
        └──SomeOtherComponent      * SomeOther component

Although, it’s an intuitive solution 💥

it quickly encounters some limitations. What to do with technical components ? Where to add a shared component ?

This is where we transition from the word feature to something more general and less coupled with functional domains, I chose brick. Why ? It actually makes sense to say that my App is made of bricks. Each one has a specific role, yet they form together the building blocks of the App.

In this example, my application is made of different bricks:

• Core: Contains everything necessary for the application to bootstrap. It also provides technical utilities for other bricks (monitoring, logging, ..etc)
• Shared: Shared tools, widgets, everything that is used across all bricks like tooltips, error dialogs, sorting functions, ...etc
• Feature 1, 2 & 3: Features corresponding to a functional domain with a specific added value for the user.
• Feature A, B & C: Also feature bricks but their added value is destined for features rather than the app directly, can be shared across some feature bricks (like the case of feature A)

In this article, we saw how a webpage can be translated to a tree of components. This tree shape explains why our code structure is driven by features and how we split our App into different bricks with unique roles.

I will continue explaining the modern frontend architecture in my next article where I will explore in depth what bricks are made of. I will also highlight more issues related to the tree shape and how to handle them.

Stay tuned and don’t forget to 👏!