The main goal is create a new project with two API endpoints.
- Get all Exercises
- Create an Exercise
The implementation I have done is more complex that it needs to be considering the main goal, however this is how I would setup a new project thinking on the scalability.
- node
- docker
$ npm install
$ make start
# Onl first time
$ npm run migrations:run
App running in http://localhost:3000
- Users
- View all users:
GET
tohttp://localhost:3000/users
- Create:
POST
tohttp://localhost:3000/users
body example: { name: 'exampleName' }
- View all users:
- Exercises
- View all exercises:
GET
tohttp://localhost:3000/exercises
- Create:
POST
tohttp://localhost:3000/exercises
, body example: { userId: '36a24320-418a-4ff8-bd00-12ca6ce2e19f', content: 'exercise content' }
- View all exercises:
- This test has been implemented using Nest framework TypeScript.
- Using docker for postgres and node to run the app locally.
- Separating modules by responsibilities.
- Basic DDD approach with hexagonal architecture.
- Easy understand from the folder structure to know what the application is doing just by reading the use cases
- The migration infrastructure is setup to be used, I mean it's not autogenerated.
- Using typeorm, but not using Active Record, so using data mapper pattern by repositories.
- There is coupling in the entities at the domain level š¤®, which is wrong. The correct thing to do would be to have an implementation at the infrastructure level and avoid the coupling at domain level.
- I added a test file for the use-case to create an exercise. I had some problems mocking the repository, but I left the test implemented as it should, with the mention that with more time I would create a different implementation for that.
- Created some custom exceptions at domain level. I could create more and with more details.
- Using class-validator to validate body requests (Not domain rules).
- Author - Gonzalo Barba