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.