Thank you for your time reviewing this code :)
This project contains a make file to make it easy. To execute the application, just execute the
command make start or docker-compose up -d.
To reinforce the good practices of code formatting, the lint and some other tools can be executed through make file.
The tests could be executed by your favorite IDE, executing the command make tests or even by go test ./.... To
generate the mocks, execute make mocks.
| Method | Resource | Params |
|---|---|---|
| POST | /decks | shuffle: boll, optional, default false cards: string, optional, default empty |
| GET | /decks/<deck_id> | - |
| PATCH | /decks/<deck_id>/drawn | count: integer, optional, default 1 |
Import the postman collections for more details.
-
Standard ordering
- Spades, diamonds, clubs and hearts.
-
Partial/Custom deck
- Use 0 (zero) to represent Ten cards in the parameter cards.
- 0S: Ten of Spades
- 0D: Ten of Diamonds
- 0C: Ten of Clubs
- 0H: Ten of Hearts
- Once a Custom deck is created and the parameter shuffle=false, the cards will be saved on the exact way received in parameter cards.
- Case there is/are one or more invalid card(s) within cards parameter, the deck will be not created and, a 400 error will be returned.
- Use 0 (zero) to represent Ten cards in the parameter cards.
-
Draw cards
- If the count parameter value informed is greater than the remaining cards in the deck, a 400 error will be returned.
There are a couple of improvements which could be done with more time:
- Use env vars to set up the components in the application. I usually implement this with libraries as godotev.
- Use properly migrations to create tables and indexes - could be done by Gorm itself or another migration library.
- Add more tests.
- Most of the logic was tested in the usecase, models and dtos. But I would add tests for the handler and repositories.
- For repositories depending on the situation we can use test-containers.
- In some projects, patterns as golang-standards are widely used to organize the code. For this challenge I just kept the structures in the root, to make the code review easier and also, to avoid misunderstandings.
*At the business side, I would implement a rule to avoid inserting duplicated cards on partial decks.