monorepo

This repo has three distinct purposes:

demonstrate and exercise the scenario of a monorepo containing several applications for different business projects and grouped by frontend and backend stacks and
to exercise a backend project structure (Profile API) using Uncle Bob's The Clean Architecture and
to exercise this same project using NestJS and maintaning some DDD principles and layer decoupling

As of the monorepo structure (item 1), I don't have much to comment as there is no much content to validate the structure. Nevertheless a PoC using Nx is welcome to validate if we can have an efficient process when it comes to building and packaging inner applications in monorepos.

As for the project, the intention is to present a lambda project with decoupled layers using Inversion of Control project student-profile-api (vanillja JS) or Dependency Injection in project student-profile-api-nest (NestJS).

Questions

does it make sense to group applications (REST API, lambdas) by project (sanctions, IDM, etc)?
does it make sense to have multiple lambdas mapped to different operations on a CRUD API or it's better to keep the operations inside a single lambda function?

Considerations

Pros

all the code base is kept together in one place and "easy" to find
it may be more productive for full stack developers that need to change both Frontend and Backend

Cons

large code base that consumes more memory when the whole structure is open (linters, git change detections, installed plugins that traverse the file structure)
more difficult to search for files (need to apply search in specific folders)

Folder structure

Repository structure

The student-profile-api project was structured following design principles.

.
├── .vscode
│   └── launch.json
├── back-end
│   ├── agent-comission
│   ├── common
│   ├── idm
│   │   ├── student-profile-api
│   │   │   ├── .vscode
│   │   │   ├── coverage
│   │   │   ├── dist
│   │   │   │   ├── express
│   │   │   │   │   ├── express.zip
│   │   │   │   │   └── index.js
│   │   │   │   ├── lambda
│   │   │   │   │   ├── index.js
│   │   │   │   │   └── lambda.zip
│   │   │   │   └── src
│   │   │   ├── src
│   │   │   │   ├── application
│   │   │   │   │   ├── adapter
│   │   │   │   │   │   └── ExpressAdapter.ts
│   │   │   │   │   └── controller
│   │   │   │   │       └── StudentProfileController.ts
│   │   │   │   ├── domain
│   │   │   │   │   ├── adapter
│   │   │   │   │   │   └── StudentProfileAdapter.ts
│   │   │   │   │   ├── entity
│   │   │   │   │   │   └── StudentProfile.ts
│   │   │   │   │   ├── repository
│   │   │   │   │   │   └── StudentProfileRepository.ts
│   │   │   │   │   └── usecase
│   │   │   │   │       ├── CreateStudentProfile.test.ts
│   │   │   │   │       ├── CreateStudentProfile.ts
│   │   │   │   │       ├── GetStudentProfile.test.ts
│   │   │   │   │       └── GetStudentProfile.ts
│   │   │   │   └── infrastructure
│   │   │   │       ├── http
│   │   │   │       │   └── express.ts
│   │   │   │       ├── repository
│   │   │   │       │   └── StudentProfileDynamoDBRepository.ts
│   │   │   │       │   └── StudentProfileMemoryRepository.ts
│   │   │   │       └── serverless
│   │   │   │           └── lambda.ts
│   │   │   ├── .gitignore
│   │   │   ├── package-lock.json
│   │   │   ├── package.json
│   │   │   ├── README.md
│   │   │   ├── tsconfig.json
│   │   │   └── webpack.config.js
│   ├── sanctions
│   ├── student-debt
├── front-end
│   ├── common
│   ├── idm
│   │   └── student-portal
│   └── sanctions
│── .gitignore
└── README.md

Structure explained

├── back-end
│   ├── common (common snippets, functions, libraries, etc)
│   ├── project 1
│   ├── project 2
│   │   ├── component 1 (REST APIs, lambdas, jobs, web services, tools, etc)
│   │   │   ├── coverage (code coverage report)
│   │   │   ├── dist
│   │   │   │   ├── express (Express application Webpack bundle)
│   │   │   │   ├── lambda (Lambda function Webpack bundle)
│   │   │   │   └── src (Javascript converted files from Typescript files)
│   │   │   ├── src
│   │   │   │   ├── application
│   │   │   │   │   ├── adapter (application-wide adapters)
│   │   │   │   │   └── controller
│   │   │   │   ├── domain (core business rules - technology agnostic)
│   │   │   │   │   ├── adapter (DTO's)
│   │   │   │   │   ├── entity (models with basic validations)
│   │   │   │   │   ├── repository (data access interface)
│   │   │   │   │   └── usecase (actual application user stories)
│   │   │   │   └── infrastructure (concrete implementations tied to specific technology)
│   │   │   │       ├── http
│   │   │   │       │   └── express.ts (Express application entry point)
│   │   │   │       ├── repository (data access concrete implementations)
│   │   │   │       └── serverless
│   │   │   │           └── lambda.ts (Lambda function entry point)
│   │   │   ├── tsconfig.json
│   │   │   └── webpack.config.js
│   ├── project 3
│   ├── project 4
├── front-end
│   ├── common
│   ├── project 1
│   │   └── component 1
│   └── project 2

fabioseno/monorepo