Front-End Architecture Part Ⅰ

In this article, I will be writing about topics such as how we should set up an architecture for a large-scale front-end application, how we can benefit from design patterns, how components should be, and how we do error management.

As you might know that 5–10 years ago, all business logic was kept in the backend, and the front-end was only responsible for rendering the data. With the introduction of SPA into our lives, the responsibility of business logic began to shift to the front-end.

One of the most important reasons why we use SPA is the component base structure, so how should a component be like?

Component

The first rule of a component is that it should be small and short. The second rule is that they should be even shorter.

We should also consider the SOLID principles, which every software developer should know, when designing components but how?

• A component should have one and only one reason to change, meaning that a component should have only one job.
• Components should be open for extension but closed for modification.
• A change that you have made on a component should not affect another component
• Dependency between components should be as low as possible.

We can create a component by applying these principles, but managing them is so hard when product/team count increases, component count increases, etc. We use a Design System to prevent this.

Design System

When the team count increases in a software company, the company should have a design plan.

Why Design System?

• It provides consistency between pages.
• It provides a way to develop a new UI Page quickly because developers use created components.
• It is a common language between developers and designers.
• It prevents rewriting the same component again and again.

We’re not designing pages, we’re designing systems of components.
- Stephen Hay

We created a component with SOLID principles in the Design System but required to define an architecture for combining all of the components and creating a page. In this time we take advantage of the Atomic Design Methodology shared by Brand Frost.

Atomic Design

Atomic Design provides the ability to create reusable components. The methodology’s name comes from the smallest unit into which matter can be divided. It targets to divide the smallest unit component.

It mentions 5 main structures. Atoms, Molecules, Organisms, Templates, Pages. I am not writing details for the atomic design.

Why?

• It increases the reusability of components
• It prevents component/code repetition
• It provides to increase development speed

I mentioned how there should be UI for the front-end. But I need to decide on a business logic layer. Because every component depends on business logic. We need a strategy to manage business logic.

Pure JavaScript Classes

I mentioned that components should be clean and don’t have as much business logic as possible. Because if components have business logic more than one and the same business logic needs different components, managing that would be so hard. In this situation, we can use the JS class.

Why do we need it?

• We can use an object-oriented approach basically.
• We can take advantage of the design pattern. The patterns solve problematic parts for the codebase If we use them at the correct time.
• We can have independent business logic from Vue, React, Angular, etc. In this way, we can simply switch some of the technologies.
• We can use the business logic class in different components because it does not depend on any component.

We created components, design system, and architecture. Now we have the project. We can not ignore error cases so we need to accept that we may face bugs every time everywhere. Then we should handle all of the bugs.

If you want to find out more about the following subjects below, I will write them in my second blog post.

• Unit/Integration/Automation Test
• Error Handling
• Monitoring
• GitHub Actions
• Some of the Libraries