316 nestjs refactor - Githubissues

danielordaan commented 2 years ago

closes #316 closes #317 closes #319 closes #320 closes #321

What is it supposed to do
All backend functionality as of commit b677675a6733adcaedfeb44513724176584781d4 has been refactored for it to use the NestJS Framework.

Structural changes

The logical backend architecture consisted of the following path: Routes -> Optional Middlewares -> Controllers -> Daos

In the new backend architecture this has been refactored to the following architecture: Optional Guards -> Controllers -> Services -> Repositories

The guards allow or disallow access to the routes which are defined in the controllers. Routes are guarded by default but can be anonymized by using the @AllowAny() decorator. Request parameters and body attributes are from now on also encapsulated by decorators like @Param() and @Body(). Larger data structures have been defined in the dtos folder.

To use the DIP, NestJS uses a module driven architecture. Each module has one controller but can provide an arbitrary amount of services. Repositories that are used in these services must be declared via the imports array which contains the TypeOrm Entity references.

On compilation environment variables are checked for their presence. This is defined in the config.schema.ts file. To view complete API documentation of the backend, run the backend with NODE_ENV=development and go to http://localhost:8000/docs.

How can we test your branch
The new backend should seamlessly fit onto the existing frontend. The only changes made to the frontend were some route names. Tests can be ran by running npm run test. To get a quick view of all the endpoints, use the swagger documentation.

1. General checklist

[~] a. Tested happy flow. I did my best
[~] b. Tested unhappy flow. I did my best
[x] c. No unexpected exceptions.
[x] d. No code with high complexity. (Big O)
[x] e. EOF newline.
[x] f. No linter warnings or errors.

2. If relevant, front-end checklist

[ ] a. Responsive. (Desktop all the way to mobile 320px)
[ ] b. Using SCSS variables where relevant.
[ ] c. Relevant class names
[ ] d. No modified global SCSS properties, except if necessary and fully tested the impact.
[ ] e. Checked caniuse for more modern CSS properties.

3. If relevant, back-end checklist