Paketá NodeJS API Challenge

• The API was developed using Node.js with Typescript. It includes a clean and organized directory structure.
• It uses Express.
• Two collections were created:
  • User
    • Id (string; generated by Mongodb)
    • Name (string)
    • Hobbies (string[])
  • Hobby
    • Id (string; generated by Mongodb)
    • Name (string)
    • ExperienceLevel (string, one of: ["Low", "Medium", "High", "Very High"])
    • Year (string)
• The CRUD endpoints were created for both entities.
  • Note: The front-end mockup provided for this challenge did not include an update feature for either entities, and therefore those endpoints were not created in order to keep the code as simple as possible and to not created features that will not be used. If the update feature is required, it can easily be added.
• The endpoints are documented in the controller layer via Swagger syntax. By doing this, the swagger documentation can be automatically generated through the swagger-jsdoc and swagger-ui-express NPM libs.
• The Swagger documentation can be accessed through the GET /docs endpoint.
• The front-end payload is being validaded through the yup NPM lib.
• There are success integration tests for the User entity. It was developed with the Jest NPM lib.
• The project is up and running live in a Heroku instance. It can be accessed from the web on: https://paketa-desafio.herokuapp.com/. Access https://paketa-desafio.herokuapp.com/docs for the Swagger documentation.
  • Note: Heroku has an automatic sleep schedule for when a project has not been accessed for a certain amount of time. You may have to wait a couple of seconds on the first request.
• The project was containerized using Docker.
• The project has CI-CD implemented. All pushes to Github are automatically reflected on Heroku via the Github Actions implemented workflow.
• The MongoDB instance is running online in an MongoDB Atlas Cloud instance.
• An Insomnia json file was included in the assets folder, to test the endpoints locally.

Note

• There were two possibilities of retrieving the user's hobbies: retrieve them along with each user on the GET /user endpoint, or create a separate GET /user/{userId}/hobby to be called every time a user is clicked on the screen. If a lot of users were to be loaded in the database, the first choice wouldn't be so practible because the user might have to wait a longer time for the table to load its components. However, the second choice also isn't the best-case scenario because you would make one extra request to the server on every new click on a user in the table.
• The first approach was implemented, keeping in mind that the second one might be better if the database would contain a higher number of users.