How and Why to Choose a Frontend Architecture: Tips From an Experienced Developer

Frontend can be done in different ways. Some write everything in one file, while others create hundreds for different parts of the site. And everyone is right in some way, but until the site starts to scale and until there are more people in the team.

My name is Aleksander Guzenko, I'm a frontend developer with over seven years of experience on projects of different scales. In this article I will tell you what a good frontend architecture is, why you need it and how to choose the right one.

What is application architecture

There are many different definitions in the IT world, where each one is good in its own way, but I personally like the following.

Application architecture is a set of rules and constraints that govern the interaction of application modules with each other, as well as the application with the outside world.

We can make a simple analogy: architecture is like the traffic regulations in the real world. They too put up their own constraints that govern the behavior of all road users. If there were no rules, there would be chaos on the roads. It is roughly the same with application architecture.

Of course, you may not follow any principles and make "crutches", but then the very chaos will form in the program code. And if the application is small, you will be forgiven because few people worry about it. But if it has business logic or microservices, there will be a lot of problems that will cost the company a lot of money.

How frontend architecture differs from backend architecture

Every frontend developer who has done projects a bit more complicated than a landing page adheres to the principles of some kind of architecture. But at some point frontenders realize that just putting everything into folders doesn't work.

Until the 2000s, frontend applications were quite simple and small, while large and complex ones were almost non-existent. It's all because frontend technologies didn't allow developing large projects conveniently back then. And when an application is small, there is no question of architecture.

Then Facebook and other social networks began to be created. Business began to digitalize, and the need to scale applications grew. Company heads wanted websites to be efficient and flexible. That's when the first architectural approaches for the frontend began to be adopted.

In the beginning, frontenders borrowed a lot from the backend - for example, the MVC pattern, or Model-View-Controller. It's not bad in itself, but it's only suitable for small applications. Soon MVC became insufficient, and Flux architecture was created. It didn't solve all the problems, but it was better in some ways: as an example, when working with data directionality and interaction with it.

The complexity of this approach is that backend and frontend are different entities after all. They work differently, interact with data differently at different levels. Therefore, everything that was suitable for the backend could not necessarily be suitable for the frontend.

Today, there are ready-made architectural approaches that take into account many factors for frontenders. But there aren't many of them, and some of them are quite young. You could say that they are not yet established, and are likely to be heavily refined in the near future.

What are the criteria for a good frontend architecture

When we start writing an application, it's still small and clean. So far, we have no serious problems. But as time goes by, the application will evolve, which means that the code base will grow and the links between modules will become more and more. So if you don't keep an eye on it, one day those links will become so hard and inflexible that it will be hard to change even a couple lines of code. This is a real story from practice, though not mine. On one project the architecture was very inflexible, so the developers had to replace several libraries and rewrite the architecture just to swap rows and columns in a table. In the end, with all the approvals, it took more than a week.

To avoid chaos in the code, you should keep in mind three properties of a good architecture:

• Usability. Developers should understand where what lies and how it is interconnected with each other. This will make working with the project more comfortable, which means frontenders will become more productive.

  
  

• Time-to-market. Ideally, it should be low. If a business wants to release updates quickly, you need to reduce the time for this development. How to reduce it depends on the company and how well business processes are organized there.

  
  

• Scalability. If a company wants to grow, it will attract more customers and add new features, which means the load on the application will also become greater. Therefore, it is important to remember about scalability - even at the initial stages.

  
  

In reality, the first two criteria are influenced not only by the application architecture, but also by external factors. If a company has poorly built processes, the developer will feel uncomfortable working, even if the architecture is good. And it certainly won’t help release updates and new features faster.

I can give an example from my experience. We were developing a large application using Gitflow. Tasks were divided into two-week sprints, where for each sprint we made improvements and merged changes into the release branch. And once every two weeks we had a release.

From our side, everything is fine. The developers are comfortable, the testers are happy too, and in general everyone is great, there’s no rush. But the business doesn't like this because it wants to see some improvements more often than once every two weeks. And then management decides to speed up the process and add local releases: send updates to production when ready.

Of course, the time-to-market has grown, but the comfort and convenience for developers has greatly decreased. Now we had to redo all the processes that had long been established in the team. We started doing a lot of “crutches”, and in general the transition was quite painful. So everything depends not only on the architecture, but also on other external parameters that are hardly even related to it.

How to build good architecture

The term “good architecture” is very abstract, because it is impossible to choose an architecture that will be universal for everyone. Therefore, the choice depends on many factors:

• What kind of team do you have: strong seniors or a team of juniors and middles;
• What deadlines: tight or flexible;
• How many resources are there: many or few;
• How well the processes in the team are structured;
• Do you have your own libraries, templates, etc.

I would give this advice: you need to look into the future as far as possible and understand what the application will be like in the long term. And then prepare for the result that you saw.

Selecting an architecture is also difficult because the requirements for the project often change.

Let's take some banking application. At first it will be a simple application, because there is not much code since we are starting to write from scratch. Then simple architectural approaches such as modular architecture will do. But as the company grows, the application architecture must become more mature: more complex and richer. As an example, move towards microservices.

It is unlikely that you will be able to predict for sure what the application will be like, but at least you can know exactly what the level of load and optimization will be.

• If the product will be used from office computers or in budget organizations, then you will have to use tools that are compatible with older browsers.
• And if the product is used, for example, by gamers, then much less attention can be paid to optimization and compatibility with older browsers. But at the same time, you will need to work more on the functionality of the application.

I really like the Feature-Sliced Design, or FSD, approach. This is a full-fledged architectural approach that is created specifically for the frontend. FSD is immediately prepared for the fact that you will have problems with the coupling of components, code complexity and the possibility of refactoring. Everything is already included in the architecture.

FSD is a young architecture that was created in 2021. This architecture gives us several rules and restrictions that divide the application into layers, hence Sliced. Each layer has its slices or pieces. And each slice has its segments. And this structure (layers → slices → segments) helps to break the application into meaningful parts.

Each layer is a separate application module, such as widgets or basic components (buttons, paragraphs). Slices are the functionality of a specific module. And segments are all sorts of api, config, lib, and so on. This architecture allows you to achieve Low Coupling and High Cohesion.

Another main and not the most obvious advantage of this architectural approach is that when we try to break down the logic into parts at the code level, we immediately notice shortcomings in some business aspects. We kind of try to divide the process into subparts and understand whether this is a common element for the whole process or a unique case, and then we put it in a separate folder.

It's better to tell with a real example. We had a customer for whom we needed to develop a dashboard to display data: he wanted to add dictionary functionality to the user card. When we started breaking this feature down according to FSD principles, we were faced with the question of whether to put it in the entities layer as part of the “user” entity or add it to the general functionality, which in theory could be used for tables and other elements.

If we did not use FSD, we would associate the functionality of dictionaries with the user entity. And when a business asked to implement it elsewhere, additional work would have to be done to port the code. Therefore, FSD helps us better think through the business logic of applications.

At the same time, the architecture also has a big drawback: high entry threshold for developers. But I would say that it is quite easy to overcome. In just a couple of months of development, you can remember all the principles. It’s like riding a bicycle: at first, it’s difficult, but then you ride automatically.

There is another important drawback of the architecture. Since FSD is actively developing, some principles are changing. For example, recently developers decided that they did not need the processes layer - they made it deprecated. This is because it can be broken down into smaller entities (entities and features), and in general only a few percent of all front-end developers used it. Therefore, when working with this architecture, there are certain risks that you need to be aware of.

It is worth noting that FSD is not suitable for all projects. For example, making a simple landing page for it is too much. But if the application is larger, where there are several modules or tabs, I would recommend trying this architecture.

To confirm the popularity of architecture, I will give the following example. Every week I conduct 5-7 interviews with Middle and Senior level front-enders - that is, I have a sample of approximately 100-200 people. About 80% of them and other developers I talk to write projects using FSD principles or know about it and want to try it. I think these are impressive numbers.

I even helped FSD develop for some time. They had too simple examples on their website that did not reveal all the benefits of FSD. These were various pet projects of the To-Do List level or something like a platform with films. And all of them did not show what problems architecture helps to solve. Therefore, third-party developers decided to create a couple of large projects themselves and add them to the site as examples.

The most active members of the FSD community split into three groups and started writing their own applications with different scales. Some used React, others used Vue, and others used Effector, a library from the creators of the FSD architecture. And I was in one of these groups.

Unfortunately, work on the projects has not progressed very far. All the developers had a main job, so they didn’t allocate as much time to side projects as they would like. Because of this, problems arose with the organization of processes and application development. But today the work is still ongoing, and it is likely that these applications will still be finalized.

You can learn more about the architecture on the official website, and communicate with other enthusiasts in the Telegram channel. You can also find answers to many questions there; you just need to type a keyword into the search, and there is a high probability that someone has already discussed this. I did this myself.

How to avoid serious mistakes when building architecture

I would give this advice: if you have no experience in building architecture, it is better to actively study Feature-Sliced Design and use it. This is a cool architectural approach that already solves the main problems of the frontend out of the box. It is also well suited for complex applications where there is some specific logic.

And second: it is important to imagine what the project will look like after some time. Write code to support this vision. This way you will make much fewer mistakes and will be able to rebuild everything in time if necessary.

Building good architecture is like putting together a cool build in an RPG game. You create it from certain artifacts, that is, front-end tools. For example, if you want modularity, use modularization tools that will help you implement a public API and divide the application into modules. If you want FSD, then use another tool: you start dividing everything into layers, slices and segments.

And when you reach the final boss and the application becomes too complex, you will need to move to a microservice architecture. Therefore, the further you move through the levels and locations, the more difficult it becomes to play, which means you need to select the right tools.