Olá!
Segue a minha resolução. Para fixar os conhecimentos utilizei o consumo de uma api externa (iTunes) para buscar os dados referentes as músicas e artistas, para as consultas utilizei exemplos com Derived Queries, JPQL e consulta nativa para exemplificar todo o conteúdo do curso.
A consulta utilizando IA foi feita através da API do Gemini para viabilizar o uso utilizei as dependências Spring AI e Google Gemini.
Abaixo segue o link do projeto no Github:
Olá, Victor. Como vai?
Parabéns pela excelente conclusão do desafio! O seu projeto no GitHub ficou sensacional e demonstra que você foi muito além do escopo tradicional do curso de Spring Data JPA.
Integrar o consumo de uma API externa real (iTunes), implementar IA nativa utilizando as dependências modernas do Spring AI com o Google Gemini e, acima de tudo, diversificar as estratégias de persistência cobrindo Derived Queries, JPQL e Native Queries é um baita diferencial para o seu portfólio. Essa variedade mostra que você domina quando usar cada tipo de consulta na arquitetura do mundo real.
Para agregar ainda mais valor à sua arquitetura e trazer insights de boas práticas sobre as três abordagens de consulta que você utilizou, preparei um breve comparativo de cenários ideais para cada uma delas no Spring Data JPA:
Como você implementou as três formas no seu repositório de músicas e artistas, vale a pena fixar os critérios técnicos que arquitetos de software usam para escolher entre elas:
findByArtistaNomeContainingIgnoreCase). A grande vantagem é que o Spring Data gera o SQL dinamicamente para você, eliminando erros de digitação e mantendo o código limpo. O limite de uso ocorre quando a consulta exige muitos relacionamentos ou agrupamentos complexos, o que deixaria o nome do método gigantesco e ilegível.@Query orientada a objetos): É o cenário ideal para a maioria das consultas de média a alta complexidade. Como ela é orientada às suas entidades Java (classes e atributos) e não às tabelas do banco de dados, o seu código ganha independência de banco. Se hoje você usa PostgreSQL e amanhã mudar para Oracle ou MySQL, o seu código JPQL permanece intacto porque o Hibernate traduz a query de forma transparente.nativeQuery = true): Devem ser guardadas como um "trunfo" para cenários muito específicos. Elas são ideais quando você precisa utilizar recursos exclusivos do seu banco de dados atual que o JPA não mapeia nativamente (como funções de busca textual avançada do Postgres, operações geoespaciais complexas ou otimizações extremas de performance através de Dicas de Query / Hints). A desvantagem é que você perde a portabilidade do banco de dados.Caso queira continuar evoluindo esse projeto que já está excelente, deixo duas sugestões de implementação que aproximam a sua API do nível de produção de grandes empresas:
Pageable: Como você está consumindo dados do iTunes, se a busca trouxer centenas de músicas, carregar tudo isso de uma vez na memória da sua aplicação pode gerar gargalos. Experimente alterar um dos seus métodos para receber o parâmetro Pageable e retornar um Page<Musica>, limitando os resultados por página.@Entity inteira com todos os relacionamentos para o usuário através da API, utilize registros (Records do Java) ou interfaces para extrair apenas as colunas necessárias na consulta (ex: apenas o nome do artista e o título da música), otimizando o tráfego de dados.Seu repositório my-music está super completo e bem estruturado. Continue com essa postura proativa de conectar diferentes ecossistemas (Spring, APIs externas e Inteligência Artificial)!
Espero que possa ter lhe ajudado!