Frontend

The layer where the user interface, client interaction, and the initial consumption of the system live.

What is this layer?

The frontend is the direct point of contact with the user. This is where you build:

• screens
• visual components
• forms
• navigation
• state management
• visual feedback
• integration with APIs

Its purpose is not to hold the core business logic, but to provide a clear and usable experience on top of the system’s functionality.

Main responsibilities

Render the interface

Display information and let the user interact with the system.

Manage UI state

Handle filters, forms, selections, loading, errors, and other states of the experience.

Basic client-side validation

Help the user with early validations, without replacing the real validations in the backend.

Consume APIs

Send requests to the system through the API Gateway or the BFF.

Manage the experience

Messages, loaders, notifications, process steps, and visual responses to errors.

What the frontend should not do

It should not contain critical business rules

It can help with experience-level validations, but the business truth must stay in the backend.

It should not know too many internal details

If the frontend needs to know about every microservice, the architecture becomes fragile and hard to maintain.

It should not orchestrate complex processes

That is what layers like the BFF or domain services are for.

Relationship with other layers

The frontend usually should not talk directly to every microservice. Its ideal relationship is:

• frontend → API Gateway
• gateway → BFF
• BFF → microservices

This helps maintain a more stable experience, even if the architecture changes internally.

Local and global state

In modern applications, the frontend typically manages two types of state.

Local state

Belongs to a specific component or view. For example:

• whether a modal is open
• the current value of an input
• a visual toggle

Global state

Shared across several parts of the application. For example:

• the authenticated user
• the visual theme
• the cart
• persistent filters
• session data

Understanding this difference helps avoid over-engineering state management.

Why not put too much logic here?

Because the frontend:

• changes quickly
• adapts to screen needs
• is more exposed to UX refactors
• should not become the place where the system’s truth is decided

Important business logic must stay protected in the backend or the domain services.

Common technologies

Depending on the stack, this layer may include:

• React, Vue, or Angular
• TypeScript
• state management such as Redux, Zustand, or Pinia
• form libraries
• HTTP or GraphQL clients
• build tools such as Vite

Practical example

Imagine a catalog screen.

The frontend:

• renders filters
• displays products
• allows pagination
• shows loading states
• sends the request to the backend

But it does not decide:

• whether a product is actually valid
• whether stock can be reserved
• whether an order can be confirmed

That belongs to the domain.

Summary

The frontend is responsible for the user experience, presentation, and interaction. It should be a clear and efficient layer, but not the place where the main business rules are concentrated.