'Nx workspace lib structure for Angular/Nest.js app
I'm setting up a new Nx workspace for an Angular app with Nest.js backend. For the frontend, there won't be only a single app but multiple variant with e.g. different styling per customer and slightly different features.
A common approach to structure the libs in the workspace is, backend (api) and frontend (client) folders on top-level and features inside, like:
└── root
├── apps
│ ├── api (nestjs)
│ └── client (angular)
└── libs
├── api
│ ├── core
│ │ └── src
│ ├── feature-1
│ │ └── src
│ └── feature-2
│ └── src
├── client
│ ├── shell
│ │ └── src
│ ├── feature-1
│ │ └── src
│ └── feature-2
│ └── src
└── shared
└── src
Basically, we separate backend and frontend code.
Would it also make sense, or are there any good reasons for not grouping backend and frontend per feature? For example:
└── root
├── apps
│ ├── api
│ └── client
└── libs
├── feature-1
│ ├── api
│ │ └── core
│ │ └── src
│ ├── client
│ │ └── ui
│ │ └── src
│ └── shared
│ └── util
│ └── src
├── feature-2
│ ├── api
│ │ └── core
│ │ └── src
│ ├── client
│ │ └── ui
│ │ └── src
│ └── shared
│ └── util
│ └── src
└── shared
└── src
Likely, in the end it doesn't really matter if I keep the libs per feature on backend and frontend consistent but somehow having everything for one feature under one roof feels better for me.
Nevertheless there will also be libs for client or api not being part of any feature, so there's still a client and a api folder under libs.
Thanks for any thoughts on this and hints for best practises.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
