I've been freelancing for 5 years now and have completed more than 20 projects for about 10 clients. The projects are mostly large and long-term. I needed to come up with an approach that would allow me to use logic from one project to another. I also needed to be in the context of each project without spending a lot of time recalling logic and architecture. The best way to solve the above problems was the modular architecture that my colleagues and I came up with on one of my first projects and later improved and tested by me on other web applications. In this article, I would like to talk about the module's structure as the modular architecture's main part. This will help you understand the essence and benefits of this approach. Module Structure For this example, I'm using React and TypeScript, but the modular architecture can also be used with other frameworks. Example Folder Structure: src/
  modules/
    user-management/
      UserProfile/
        UserProfile.tsx
        UserProfile.module.css
        index.ts
      slice.ts
      types.ts
      api.ts
      index.ts
  components/
    Button/
      Button.tsx
      Button.module.css
      index.ts
  pages/
    Users/
      Users.tsx
      Users.module.css
      index.ts components/: folder with general components of the application. This folder shouldn’t contain any module component, for example, UserInfo.  The best example here is a component Button, it can be used in many modules.


pages/: The page is mostly the entry point of each application. Usually, each page is a separate route. In our example for the page Users, we can have route /users. It looks like the page should be a part of a module, but this is the only exception as the page is like a constructor that can contain different modules.


modules/: folder contains all modules of the application.


user-management/: module, and below I will explain each file so you can understand the module structure


UserProfile/ In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple.


slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects.


types.ts should be used in case you have types, in my case I usually use TypeScript.
api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides.
index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. You can put any other files into your modules, I just highlighted the most important ones to show you the basic idea. The main benefit of the module architecture is that it is very simple. The complexity here is to logically divide your application into modules, which should be also domain-related. Module names shouldn’t have technical names, it should be understandable for the client. Modules can use global context, like env variables, CSS variables, and data from other modules through state management systems like redux. I've been freelancing for 5 years now and have completed more than 20 projects for about 10 clients. The projects are mostly large and long-term. I needed to come up with an approach that would allow me to use logic from one project to another. I also needed to be in the context of each project without spending a lot of time recalling logic and architecture. The best way to solve the above problems was the modular architecture that my colleagues and I came up with on one of my first projects and later improved and tested by me on other web applications. In this article, I would like to talk about the module's structure as the modular architecture's main part. This will help you understand the essence and benefits of this approach. Module Structure For this example, I'm using React and TypeScript, but the modular architecture can also be used with other frameworks. Example Folder Structure: Example Folder Structure: src/
  modules/
    user-management/
      UserProfile/
        UserProfile.tsx
        UserProfile.module.css
        index.ts
      slice.ts
      types.ts
      api.ts
      index.ts
  components/
    Button/
      Button.tsx
      Button.module.css
      index.ts
  pages/
    Users/
      Users.tsx
      Users.module.css
      index.ts src/
  modules/
    user-management/
      UserProfile/
        UserProfile.tsx
        UserProfile.module.css
        index.ts
      slice.ts
      types.ts
      api.ts
      index.ts
  components/
    Button/
      Button.tsx
      Button.module.css
      index.ts
  pages/
    Users/
      Users.tsx
      Users.module.css
      index.ts components/: folder with general components of the application. This folder shouldn’t contain any module component, for example, UserInfo.  The best example here is a component Button, it can be used in many modules. pages/: The page is mostly the entry point of each application. Usually, each page is a separate route. In our example for the page Users, we can have route /users. It looks like the page should be a part of a module, but this is the only exception as the page is like a constructor that can contain different modules. modules/: folder contains all modules of the application. user-management/: module, and below I will explain each file so you can understand the module structure


UserProfile/ In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple.


slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects.


types.ts should be used in case you have types, in my case I usually use TypeScript.
api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides.
index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. components/: folder with general components of the application. This folder shouldn’t contain any module component, for example, UserInfo.  The best example here is a component Button, it can be used in many modules. components/: folder with general components of the application. This folder shouldn’t contain any module component, for example, UserInfo.  The best example here is a component Button, it can be used in many modules. components/: pages/: The page is mostly the entry point of each application. Usually, each page is a separate route. In our example for the page Users, we can have route /users. It looks like the page should be a part of a module, but this is the only exception as the page is like a constructor that can contain different modules. pages/: The page is mostly the entry point of each application. Usually, each page is a separate route. In our example for the page Users, we can have route /users. It looks like the page should be a part of a module, but this is the only exception as the page is like a constructor that can contain different modules. pages/: modules/: folder contains all modules of the application. modules/: folder contains all modules of the application. modules/: user-management/: module, and below I will explain each file so you can understand the module structure UserProfile/ In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple.


slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects.


types.ts should be used in case you have types, in my case I usually use TypeScript.
api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides.
index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. user-management/: module, and below I will explain each file so you can understand the module structure user-management/: UserProfile/ In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple. slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects. types.ts should be used in case you have types, in my case I usually use TypeScript.
api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides.
index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. UserProfile/ In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple. UserProfile / In React all my components are folders with their styles. For styles I am using CSS modules, I think this approach is the best for the modular architecture. You are free to put all your module components inside the components folder in your module, but I prefer to put them into the root of the module. In case you have more than 5 components in your module - you should probably think to divide this module into smaller pieces. This is very important to keep the module simple. UserProfile slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects. slice.ts I usually use redux-toolkit so this file is a data management file that shows how data are merged into the general store. I am not a fan of creating each store for the module but you can do that in case you want to use this module in other projects. slice.ts types.ts should be used in case you have types, in my case I usually use TypeScript. api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides. index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. types.ts should be used in case you have types, in my case I usually use TypeScript. types.ts api.ts file that shows communication with the server. In case you are also responsible for the server side it is recommended to use modules architecture on that side as well, so your modules can be related to each other on both sides. api.ts index.ts this is the most important file of your module, it shows what part of your module can be used in pages and other modules. By using this file you can see dependencies and generate a dependency graph. index.ts You can put any other files into your modules, I just highlighted the most important ones to show you the basic idea. The main benefit of the module architecture is that it is very simple. The complexity here is to logically divide your application into modules, which should be also domain-related. Module names shouldn’t have technical names, it should be understandable for the client. Modules can use global context, like env variables, CSS variables, and data from other modules through state management systems like redux.

Users Hate Search Filters—Maybe Let AI Handle It Instead

I Spent Years Freelancing in Web Dev—Here’s the Modular Trick That Saved My Sanity

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Users Hate Search Filters—Maybe Let AI Handle It Instead

Users Hate Search Filters—Maybe Let AI Handle It Instead

We Don't Need More Apps - We Need More Spaces

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

111 Stories To Learn About Architecture

Users Hate Search Filters—Maybe Let AI Handle It Instead

Users Hate Search Filters—Maybe Let AI Handle It Instead

We Don't Need More Apps - We Need More Spaces

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

111 Stories To Learn About Architecture

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps