Open
Milestone
Modular architecture
Current architecture
lms
├── ...
└── src
├── ...
└── lib
├── assets
│ ├── fonts
│ ├── images
│ └── sass
├── components
│ ├── domain-1
│ ├── domain-2
│ ├── ...
│ ├── domain-n
├── config
│ └── pages
├── hooks
└── utils
├── api
└── crud
Problems of the current architecture:
- Files are separated based on types (hook, services, utils, etc.) instead of user-facing features. This makes it difficult for someone who is reading/reviewing code since they have to check files at multiple places to understand what is happening behind a user-facing feature.
-
domains
inside components are not clearly defined, rather made on the go as needs arose. -
config
files have no proper convention and have multiple entry points. This makes it difficult to understand/add/edit configuration for a page/route.
Modular architecture
lms
├── ...
└── src
├── ...
└── lib
├── assets
│ ├── fonts
│ ├── images
│ └── sass
├── config
├── hooks
├── modules
│ ├── page-1
│ │ ├── assets
│ │ ├── components
│ │ ├── config
│ │ ├── hooks
│ │ └── services
│ ├── page-2
│ ├── ...
│ └── page-n
├── shared
│ ├── subpage-1
│ │ ├── assets
│ │ ├── components
│ │ ├── config
│ │ ├── hooks
│ │ └── services
│ ├── subpage-2
│ ├── ...
│ └── subpage-n
└── utils
Advantages of the modular architecture:
- User-facing features are now consolidated as
modules
, each module represents a user-facingpage
where a page is defined as a component that can be accessed directly from browser using a pre-definedroute
. Each module will contain a mandatorycomponents
dir and optional dirs forconfig
,hooks
,services
andutils
. - No need to create/manage domain specific directories as the architecture is now page-dependent.
- Config files now live in their corresponding pages.
Problems that are independent of the current structure, but still need architectural concerns:
Note: Suggestions for each of the following problem are given in square brackets.
- Changes in backend API schema might result in shotgun surgery:
- When API endpoints change [This is somewhat fixed using a centralized API config file].
- When API URL params change [Can be fixed by creating methods for specific purposes such as pagination, filtering, searching, etc].
- When API response body changes or expects changes in request body [Cannot be fixed easily as it needs changing the corresponding code wherever required].
- Components outside
lib
, such asDashboard
,QuickLinks
,SideBar
, etc. aren't reusable [Can be fixed by extracting the reusable code intolib
dir]. - No naming consistency for components.
-
List
,Create
,Detail
&Update
are now used as prefix for the components while container components haveContainer
as suffix in addition [It's better to use same names for CRUD operations that the user sees on frontend, i.e. changeCreate
->Add
andUpdate
->Edit
for generic CRUD components. In custom components, theDetail
prefix can be omitted andCreate
andUpdate
prefixes can be replaced withForm
suffix. Also, removeContainer
suffix from components since all components are essentially containers given that the presentational components, except templates, are imported from the primereact library].
Notes
The migration to the modular architecture should be done gradually, i.e. migrating modules one by one, without breaking the existing functionalities. This means that there will be some redundant code that has to be kept in both old and new directory structure. Once the migration is fully complete and tested, the old/redundant code can be removed safely.
All issues for this milestone are closed. You may close this milestone now.