daruan-rst/magicalpotionbrewery

Magical Potion Brewery Challenge

Theme: Magical Potion Brewery

Entities:

1. Wizards: Users who are magical potion brewers.
2. Ingredients: Different magical ingredients required for potion-making.
3. Potion Recipes: A collection of potion recipes, each specifying the required ingredients and steps.
4. Brewery: The central location where wizards brew potions.

Functionality:

1. Potion Brewing: Wizards can select a potion recipe and brew potions by combining the necessary ingredients.
2. Ingredient Management: Allow wizards to gather and manage their stock of magical ingredients.
3. Recipe Discovery: Wizards can discover new potion recipes by experimenting with different ingredient combinations.
4. Potion Catalog: Maintain a catalog of all brewed potions, including their properties and effects.
5. Wizard Profiles: Allow wizards to create profiles, track their brewing history, and showcase their most powerful potions.
6. Potion Trading: Wizards can trade potions with each other, with potion properties affecting trade values.
7. Leaderboard: Implement a leaderboard to showcase the most accomplished potion brewers.

Technologies:

1. Kotlin: As the primary programming language.
2. Spring Boot: To build the backend API.
3. Spring Data JPA: For managing data related to wizards, ingredients, recipes, and potions.
4. H2 Database: To store information about wizards, ingredients, recipes, and potions.
5. Spring Security: Handle user authentication and authorization.
6. JUnit and Mockito: For unit testing.
7. Swagger: To document the API.

Target Technology/Concept:

Focus on building a RESTful API using Spring Boot, implementing secure user authentication and authorization for potion brewing and trading operations.

Project Architecture:

Build this project as a monolith since it's not overly complex and doesn't require microservices.

Challenges:

1. Dynamic Recipe Discovery: Create a system for wizards to discover new potion recipes through experimentation.
2. Potion Properties: Implement a system for defining and calculating the properties and effects of brewed potions.
3. Ingredient Management: Design a way for wizards to gather, trade, and manage their stock of magical ingredients.
4. Leaderboard Calculation: Design an efficient algorithm for calculating and updating the leaderboard based on wizards' achievements.
5. User Authentication: Implement secure user authentication and authorization for different API endpoints.

This Magical Potion Brewery challenge offers a whimsical and creative theme that combines potion-making, experimentation, and trading within a magical world. Have fun building your Kotlin backend for this enchanting theme!

magicalpotionbrewery's Issues

Sugestões

• Usar DTOs no lugar de DAOs nos controllers (tanto para request, quanto para response se fizer sentido). Você também criou uns objetos de Request, mas poderia adicionar Annotations para validar os campos (notBlank, notNull, Min, Max, JsonFormat, etc...)

• Quando usamos v1/ num endpoint, geralmente usamos ele antes do domain, pois é o versionamento da API ou do endpoint.
  Exemplo: No lugar de /api/ingredient/v1 costumamos usar v1/api/ingredient ou api/v1/ingredient (talvez nem seja necessário usar api aqui).

• No WizardService, você está usando diretamente ingredientRepository, recipeIngredientRepository, recipeRepository e potionRepository. Isso não é recomendado segundo o Single Responsibility Principle (S do SOLID) pois várias classes de Service poderiam alterar dados da mesma entidade no banco de dados, o que pode dificultar manutenção do código e troubleshooting.

• Em Kotlin, no lugar de usar assim:

if (potion == null) {
    throw RequiredObjectIsNullException()
}

Da para usar diretamente:

potion?: throw RequiredObjectIsNullException()

• Outro uso comum em Kotlin é de forEach com listas / collections no lugar de:

for (wizard in wizards) {
     val withSelfRel = linkTo(WizardController::class.java).slash(wizard.id).withSelfRel()
     wizard.add(withSelfRel)
}

Da para usar assim:

wizards.forEach {
      it.add(linkTo(WizardController::class.java).slash(it.id).withSelfRel())
}

• Na classe RecipeIngredientRepository não me parece que era necessário receber o objeto Ingredient inteiro para fazer a consulta, só o nome do ingredient (se único) ou o id deveria ser suficiente e tornaria o código mais simples.

• Adicionar uns Dockerfile e docker-compose.yaml para subir o projeto e o banco de dados já populado para testar.