Você gostou do vídeo de hoje? Qual poderia ser o próximo desafio? Quer apoiar o canal e ter benefícios exclusivos? Seja membro: www.youtube.com/@buildrun-tech/join
Muito bom o vídeo, so quero deixar apenas uma sugestão, em uma API REST o método DELETE deve ser usado para remoção de um recurso. No seu caso, como está alterando um recurso (Status), deveria usar PUT
lembrando que, tem um video que o Brunão fez sobre o design pattern strategy, da pra implementar o envio para cada channel, da pra dar uma incrementada no código e mostrar que tem conhecimento tambem sobre design pattern 😄
Espero que seu canal cresça bastante, pois seu trabalho é muito bom! Trabalho com java a 7 anos e vi poucos canais no yt que tem esse grau de cuidado com a apresentação que você tem!!!
Utilizar a identificação como notificationId não seria algo redundante dentro do contexto da entidade Notification? Porque você prefiriu utilizar um relacionamento 1 para N entre Channel e Notification ao invés de criar um enumerado, no caso não seria mais interessante ser um relacionamento N x N ou talvez utilizar @ElementCollection com uma listagem de enums representando os canais, tendo em vista que a notificação poderia ser enviada para vários canais ao mesmo tempo. Achei muito inteligente sua ideia de criar um Enum para o Channel contento o Id e a descrição dele pra representar os canais padrões pré cadastrados no banco, eu provavelmente teria feito um enum somente com a descrição dos channels e buscaria eles através da descrição pra pode setar ele como um relacionamento da notificação, mas usando essa abordagem que você fez fica muito mais claro e simples. Muito bom o vídeo, aprendi coisas novas ✌
Muito bom. Parabéns pelo canal. Aproveitando os vídeos pra dar uma atualizada. Vou ver todos e já estou compartilhando seus vídeos com o clã dos devs por aqui. kkkkkk. Valeu.
Camarada, algum motivo especial em ter optado por utilizar o CommandLineRunner ao invés dos arquivos schema.sql e data.sql? Parabéns pelo vídeo, muito bacana.
Qual sua opiniao de status e channel serem apenas enums? Penso isso pois são registros que não mudarão com frequência e eles são muito acoplados a implementação, você teoricamente não poderia ter um channel sem implementar a forma de envio dele (pensando em algo mais futuro)
@@programadordebug Pensando em otimização, nós precisamos normalizar as colunas da base de dados ( 1 Forma Normal ). Se for um campo de texto somente, não temos tantos benefícios com indexação. :)
Poderia ser dessa forma tambem, nao vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
Muito bom o video parabéns super didático. Espero que mais brasileiro possa criar conteudo desse seu nível. Eu só fique com uma duvida, por que você extraiu tudo para uma entidade channel e status, pq não optou por só usar uma enum? No final você colocou um TODO dizendo que não irá realizar essa implementação. Daria para ter criado uma interface, envioGateway com 1 metodo send por exemplo, injetar na sua service e chamar o metodo send no lugar do TODO. Ai quem for mexer com o envio teria que implementar essa interface. Acredito que desacoplaria bem mais.
@@eduardoroosevelt3261 Fala Edu! Optei por normalizar a base de dados, com isso ela fica melhor indexada e otimizada. É uma ótima sugestão essa criação da interface, boa!
@@murilokratos3388 obrigado Murilo! Rapaz, eu prefiro ter a visão real do código que está rodando, além de outros aspectos (encapsulamento, etc). Não tem certo ou errado, é mais a minha preferencia mesmo :)
Obrigado pelo conteudo!! Dúvida: qual seria o motivo de criar as tabelas channel e status ao inves de apenas adiciola-las como coluna de notifications e deixar o proprio backend tratar isso?
Naoo vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
Muito bom mesmo. Agora me tira uma dúvida. Porque você optou por fazer duas entidades channel e status e não colocou apenas como 2 atributos da notificação já que no cadastro é uma notificação por channel? Eu só faria assim se no cadastro eu enviasse uma mensagem e uma lista de chanels para essa mesma notificação. Muito obrigado pelo conteúdo.
@@daniel_goncalves opa, obrigado! Optei por normalizar a base, para poder ensinar os relacionamentos tbem. Com a base normalizada, as buscas ficam mais eficientes
Nao vejo problema na questao do status ser um ENUM dentro da propria entidade. Quanto ao Chaneel nesse caso e melhor ser uma tabela separada pois o channel pode ter outros atributos. Suponha que a empresa deseje desabilitar o envio de notificacao de SMS, por questao de custo, por exemplo. A tabela channel poderia ter um campo Ativo (true/false) para cada tipo de notificação. Dessa forma, voce consegue ter controle maior sobre cada channel
@@dldmdani O desafio foi passado via PDF para um inscrito do canal. Ele passou para a gente e eu converti para MD. Está no link da descrição o repositorio, o arquivo é o problem.md
