Let's talk about Frontend architecture. We all know that Frontend has become complex with the days and why is it so?
Front-end is where all user requirements, user enhancements, use of the Business domain, handling of errors, optimization, and so on. Our frontend architecture is responsible for the cohesion of the new and old codebase.
In the time of AI agents π€
Even now, with the rise of AI agent coding tools, clean and well organized code remains critical.
Without clear instructions, AI can easily overcomplicate solutions. AI agents understand domain logic through code structure. The clearer and more consistent patterns you have, the less context the Agent holds, because the agent will follow a predictable organization.
For that reason, my rule of thumb is simple: Follow a modular approach to code organization
What is a modular approach?
A modular approach is the practice of breaking down a solution or user requirements into smaller units, where each unit has a single responsibility.
Following this approach helps maintain a solution over the long term and makes it easier to add new features, whether they are simple or complex.
With so many stacks out there, why not use the basic organization offered by a library or framework?
Of course you can! A framework or library often provides a playground or a basic project structure to get you started. However, as tasks grow bigger and features begin to interact with one another, it becomes our responsibility to break down big user requirements or concepts into self-contained units.
A use case:
Let's say your Admin panel website, needs a new feature an Employees overview page with the following use cases:
Page: Employees Overview***
- Filter (search, role, age range)
- List employees
- Open modal for Editing a new employee
- Open a modal for adding a new employee
Now, we can design the architecture by breaking the solution into smaller building blocks.
For example:
With our rough idea in place, we can start organizing our code using a modular approach. We take a big feature and split it into smaller and independent blocks called modules.
project
ββββ common/
β ββββ components/
β βββββ Modal
β ββββ hooks/
β ββββ useUserLanguage.ts
β ββββ models/
β ββββ user.ts
ββββ core/
β ββββ authentication/
β ββββ i18n/
β ββββ translations/
β ββββ router/
β ββββ api/
β ββββ store/
ββββmodules/
β ββββemployees-overview/
| ββββ EmployeesOverview.tsx (Main component)
β ββββ components/
β βββββββ employee-filter/
β βββββββ employee-list/
β βββββββ employee-add/
β βββββββ employee-edit/
β βββββββ hooks/
β ββββββ useFetchUser.ts
β ββββββ useUpdateUser.ts
β βββββββ components/
β βββββββ helpers/
β βββββββ models/
β βββββββ EmployeeEdit.tsx
ββββlib/
β ββββutils
Let me explain you shortly about some of the important folders and what functionality they cover
-
common Also called shared: Contains code that can be reused across modules (features). You can organize them by components, hooks, helpers, etc.
- helpers Also called functions: Pure functions that performance specific tasks.
- models: Represent your entities. It's recommended that your entities match the backend for consistency and a single source of truth, with slight differences when needed, for example, dates (the backend uses UTC, while the frontend uses a Date object).
- modules: Feature-based code aligned with your business goals.
core (optional): Contains the foundational code of your app. This folder is optional because you can either keep these files in a dedicated core folder, making it easy to find anything your app relies on, or place them directly in your main structure.
lib Also called utility functions: Generic technical functions that are not related to domain or business logic and can be used across your code.
Conclusion π
Start thinking in terms of features, responsibilities, and blocks and let your team and AI agents maintain the code more easily πͺ

Top comments (1)
Amazing work, very helpful!!