Eu não imaginava que microsserviços eram assim

[@bughunter94]

cara, esse formato ficou bom demais

[@rocketseat]

Que show que curtiu, Natalia! Valeu demais pelo feedback! 💜 🚀

[@RodrigoKulb]

18:23 Como um desenho simples pode explodir nossa mente de uma forma tão grandiosa!!! Parabéns Diego pela clareza na explicação!

[@giannoulakis]

Na empresa onde trabalho não duplicamos os dados no DB do serviço. Usamos o Redash, que centraliza data sources de vários dos serviços e de varios formatos, ficando disponíveis pra consulta através de queries SQL. A query fica salva e pode-se definir um cache pra ela, com revalidação configurável. Então os serviços que precisam de dados de outros, podem consultar pela query_id os dados do Redash, que já vão estar em cache.

[@brunorafael5665]

Seria um formato então de data center (banco de dados) com a uma api rest / redis (cache) que distribui as informações através da requisição ?? Fiz um sistema semelhante a este usando typeORM (nodejs) + redis (cache) para recuperar dados do data center a partir de views já pré definidas no banco

[@tiago.gcastro]

seria então uma tabela de usuario separada de qualquer sistema, na qual quando você quiser consumir, editar, inserir, é so chamar esta query(ou usar qualquer orm)?

[@pauloimon]

Guilherme, não conhecia o Redash, mas o que acontece se ele cair? Existe algum impacto nos serviços que precisam consultar dados nele?

[@luca0898]

Como vocês lidam com indisponibilidade do serviço? Pelo que entendi o sistema fica completamente dependente dessa estratégia

[@giannoulakis]

@@tiago.gcastro isso, mas o redash é somente pra leitura, os dados sao consultados nele através de uma api (passando o ID da query que já está salva)

[@Rychell1993]

@Rocketseat faz uma trilha de backend avançado que foque nessa parte 💜

[@dieegosf]

A ideia é trazer cada vez mais esses assuntos pras trilhas existentes.

[@samuelpaiva830]

Sempre trabalhei em monolitos. Quando parei pra estudar sobre arquitetura de microserviços, como o diego falou, o que mais foi dificil absorver foi a questão da consistência relacional de dados e concordo 100%, é uma questão de mindset e como vc enxerga o domínio da aplicacão. Parabéns pelo conteúdo.

[@cafecomdeploy]

Diego Muito bom seu vídeo, muito bem colocado... Vou compartilhar uma experiência que a mais ou menos um ano e meio eu tive... Faz uns 2 anos que sempre foquei em trabalhar com aplicações distribuídas, quando vejo que há um crescimento dessa aplicação em algum momento, e confesso que a ultima empresa que fiz parte, foi bem difícil trazer essa mudança de mindset, mesmo mostrando todos os lados positivos e o quanto para o cenário da empresa os positivos se sobressaem dos negativos. Até que fui desligado, dessa empresa rs... Não sei ao certo se foi por esse motivo, mas era muito evidente que o time estava estacionado, não aceitava sair da zona de conforto... Mas hoje eu vejo que foi a melhor coisa que aconteceu. :) Grande abraço!

[@aleodoni]

Show Diego !!! Como é bom "conversar" com mais gente pra clarear as ideias... Eu estava criando alguns projetos baseados em MS, mas estava utilizando o Rabbit pra mensageria também porque com ele a gente consegue enviar mensagens síncronas, e era isso que eu estava fazendo para buscar algumas informações entre os MS. Só que esse meu approach cria um acoplamento forte entre os MS, que eu não estava gostando muito. Acho melhor a ideia de "duplicar" algumas informações entre os BDs, e mantê-las atualizadas de maneira assíncrona, assim mesmo que um MS caia, os outros (teoricamente) podem continuar funcionando sem problemas. Grande abraço e se puder, gostaria de mais vídeos como esse... Já valeu o meu dia !!!

[@wellingtonmatos6340]

Ontem o vídeo foi ótimo, é um posicionamento que te trás mais uma via de solução com base na POC de Diego, entretanto vejo que hoje, digo hoje pois assistir o vídeo duas vezes, tomei nota da experiência dele para fortalecer as minhas decisões pois sei como é difícil propor uma nova e/ou melhor solução, e de acordo com que se reobserva a prova de conceito a gnt passa a notar que o material agrega conhecimento de valor e por isso as apresentações de Diego tem se tornado melhor a cada dia. Parabéns Diego!

[@LeapGabriel]

que video legal de se ver, adoraria ver videos nessa linha quase como um video "amador" sem tantas edições, video simples com um conteúdo sensacional.

[@JonasREJCS]

Adotamos o NestJS aqui na minha empresa e já estamos colhendo os frutos, produtividade, organização de código e facilidade de manutenção! Antes usávamos JS puro.

[@fvgoya]

Cara esse tipo de vídeo / formato acaba sendo MUITO mais VALIOSO do que um vídeo de tutorial. E olha que tutoriais são super úteis. Você comentou o problema e ainda MOSTROU a sua solução. Sensacional ver como os outros pensam.

[@lucascarvalho1367]

Fala diego, faz um video mostrando o codigo da arquitetura de microserviços e a comunicação entre os serviço. Video muito massa!!

[@rogeriopst450]

tb fiquei bem surpreso qdo soube q duplicava. mas a forma como vc colocou no livro clareou bastante e vou conseguir apoiar se alguem na empresa em q trabalho pensar ou nao em migrar p microservices. a proposito, video ficou otimo tanto conteudo como o som, fundo etc =) vlw. parabens.

[@Pedromarneto1303]

Tô justamente avaliando que abordagem usar para o próximo passo na empresa que trabalho e estava pesquisando sobre microsserviços. Não estava conseguindo imaginar iria ficar já que cada serviço deve ter seu DB, esclareceu muita coisa para mim e tenho certeza que para um monte de gente! Conteúdo super relevante! Obrigado pela contribuição para a comunidade!

[@jhoyascari]

Os videos nesse formato ficaram muito foda, parabéns.

[@rocketseat]

Que massa que curtiu, Jhoy! Importante demais esse feedback pra nós! 💜 😍

[@BrunoCAAD]

Esse tipo de vídeo com abstrações postas de forma gráfica fica muito bom, pois ajuda mentalizar os modelos. Parabéns!

[@igorvinnicyos2113]

Muito bom! Eu sempre achei muito complicado de entender a arquitetura de micro serviços, até por que eu sempre fui mais focado em front, mas esse vídeo ajudou bastante a entender de forma geral, traz o vídeo mostrando na prática!

[@rocketseat]

Wooow! Que feedback massa, Igor! Deixa com a gente! 💜 🚀

[@LucasSoaresAraujo]

Bacana o vídeo. O único problema de usar apenas Pub/Sub é que se algum serviço não estiver on-line ele vai perder a atualização. Creio que utilizar uma message queue seria uma melhor opção pra ter uma garantia maior.

[@phsdevweb]

Muito massa esses vídeos são incríveis, cara já deixando o Like Maroto e compartilhado. Sempre bom aprender contigo. Assisti o vídeo sobre tuas vídeo aulas e me deu uma luz pra resolver meu EAD. Precisei aprender React para iniciar um projeto onde trabalho, fiz a tua primeira NLW na época, só com ela eu desenvolvi o projeto e imagina o que aconteceu, virei teu aluno KKKK. Sucesso hoje e sempre e obrigado por tudo e todo o seu trabalho.

[@williandandrade]

Muito bom esses vídeos sobre os desafios do dia a dia! Na empresa a gente tá com o desafio de quebrar um monolito também e estamos fazendo algo parecido, só que com SQS e SNS. Sempre tem um trade-off, às vezes faz sentido duplicar uma informação para tornar o serviço mais independente, às vezes não. Se possível fala sobre a parte de quebrar o banco atual e como estão transferindo os dados existentes, se precisam voltar dados para o banco principal para não quebrar processos, etc.

[@ricardo.fontanelli]

Eu nao chamaria de "duplicidade", mas de "cache". No seu exemplo, [A] é o dono da informacao e [B] so faz um cache dos dados. Este dado nunca deveria ser alterado diretamente no lado de B (read-only), mas sempre atraves de eventos vindos de [A], como bem foi apresentado no seu exemplo. Em relacao ao kafka, algumas dicas que podem ajudar: - Definir uma message key (codigo do cliente, por exemplo) pra garantir a ordem das mensagens de uma mesma entidade; - Pra valer a pena o Kafka, vc provavelmente vai implementar auto-commit, e logo precisará de em um mecanismo de retry e ate um DLQ (dead letter queue) pra quando seu consumer falhar;

[@LeandroUngari]

Muito bacana esse formato de vídeo, ficou top! Sobre comunicação assíncrona, eu descobri ela no meu trabalho novo há alguns meses atrás, a gente usa tanto rabbit mq quanto o Kafka, só que estamos em um processo de modernização e estamos tendendo mais para o Kafka. Mas claro, sou bem iniciante nesse assunto queria ver mais

[@Zizaco]

18:33 Obrigado por enfatizar que elas são "duplicadas" Essa é a parte que a maioria das pessoas entende errado sobre Microservicos. Isso não é óbvio e eu diria que é o erro mais comum de quem adota Microservicos: Chamada rest pra todo lado estourando a latência. Tem um vídeo com o case da Dell chamado "Avoiding Microservicos Mega Disasters" que explica bem isso.

[@robertooliveira7558]

Muito legal o conteúdo Diego! Essas dúvidas eu tenho muito também. Já que decidi migrar para microsserviço. Vai ser muito útil se você postar mais conteúdos como esse. Parabéns mais uma vez a vc e a Rocketseat!

[@JacksonAlfonso]

Muito dificil achar um conteúdo tão claro e objetivo como vc mostrou no vídeo, parabéns ficou excelente !!!

[@marcospaulo.08]

Mano só foi que gostei demais desse formato de vídeo.... Ficou foda demais !!!!

[@gabryelfhsoares]

Muito esclarecedor esse vídeo, obrigado 👏👏👏😁

[@rafaelvieira8957]

Muito massa o video. Eu já tinha começado a estudar sobre microsserviços em uma bolsa da faculdade, e achei muito intessante, pois comecei a ter uma noção da quantidade de benefícios dessa abordagem, mas além disso da complexidade e dos problemas que podem vim, e por isso é bom estudar e avaliar para verificar se é essa transição é realmente algo viável. Além disso, também estudei esse conteúdo em uma disciplina da faculdade, e achei muito legal o professor ter trazido esse assunto e algumas tecnologias correlacionadas, como RabbitMQ e Kubertnets

[@brunorafael5665]

Muito show!! @Rocketseat várias dúvidas me surgiram em torno dessa assunto : - Qual a vantagem de usar outro banco de dados e qual seria o melhor tipo de banco para armazenamento desses informações simplificadas?? (Redis/MongoDB/PostgreSQL) - Por que não usar outra conexão para o mesmo banco, já que a ideia é tornar independente da aplicação principal? Nada impede que duas aplicações possam interrogar o mesmo banco. - Seria possível usar logstash para a sincronização desses dados? Usando templates específicas para alimentar os diferentes bancos de dados (simplificados), partindo do princípio que temos outros serviços com seu próprio banco, além desde de envio de e-mails. Desde já agradeço pelo o vídeo, e obrigado pela a resposta a este comentário.

[@dieegosf]

1. A vantagem de usar dois bancos é que os serviços ficam desacoplados e não preciso ficar buscando dados entre múltiplos serviços durante a execução. Você pode usar qualquer banco, a ideia é usarmos o conceito de banco de dados poliglota, ou seja, podemos ter bancos diferentes (Mongo, PG, MySQL) pra cada micro-serviço. 2. Duas aplicações com o mesmo banco causa acoplamento porque se o banco estiver lento por causa da aplicação A, a aplicação B sofre com isso. 3. Não sei, tenho pouco conhecimento em logstash.

[@arkenplayer]

Diego, parabéns pelo vídeo! Onde trabalho, diariamente enfrentamos este desafio e isso nos fez procurar soluções/padrões para resolver a questão. Recentemente, entramos nos estudos sobre as soluções de CDC (Change Data Capture). Já ouviu falar? Com ela, conseguimos gerar menos códigos "sincronizadores" e delegamos, à esta solução especialista em eventos de dados, a responsabilidade de sincronizar outras bases de dados ou, ainda, entregar os eventos aos serviços de mensageria. Casos de aplicação: bases analíticas e de outros microserviços (caso apresentado no seu vídeo).

[@josemorista2697]

Excelente conteúdo, gostaria bastante de conteúdos do padrão Rocket sobre uso do GRPC, Pub/Sub e afins no Node. Mas acho que um vídeo como esse entendendo o core da solução já é a base pra qualquer estudo de qualidade! :)

[@tharlysalves5630]

Incrivel o quanto o @Diego consegue tirar um pensamento que a pessoa tem na cabeça, sempre fui contra duplicação de dados mais vendo dessa forma fica tão simples de entender o porque duplicar e o cara mostra o quanto é correto : ) : )

[@luca0898]

No meu trabalho estou criando um serviço de criação de pedidos que gera uma planilha de orçamentos para ajudar o time de atendimento. Ao invés de criar a planilha no momento da criação do ticket de atendimento, publiquei numa fila e um serverless fica ouvindo as alterações nela. Dessa forma a função cria a planilha e vincula numa conta Onedrive para o time desfrutar da mesma. Ótimo vídeo Diogo 🚀

[@alonsoricardo]

Bom demais, excelente explicação

[@tyagoveras7921]

Como instrutor de banco de dados, eu realmente fiquei surpreso sobre a duplicidade dos dados. Se possível, seria ótimo mostrar tanto o diagrama dos bds e como você tá fazendo essa integração entre as aplicações 🙏

[@dieegosf]

Boa, no próximo vídeo vou trazer a parte mais técnica.

[@antoruby]

Fala Tyago, sobre a duplicação de dados, o segredo é mudar o paradigma e pensar como as empresas funcionavam antes da informática: papel carbono e três vias. Quando uma venda é realizada, o pedido é copiado e cada via usada por uma parte da empresa. Uma via para a entrega, uma para o financeiro, uma para o controle de estoque, por exemplo. Cada “microserviço” da empresa vai usar a informação que necessita para tocar a sua atividade (itens e endereço pra entrega, preço e pagamento para o financeiro, etc.). E cada “microserviço” fica responsável por “se inscrever” a eventos que mudam esses dados (a entrega recebe notificação de mudança de endereço, mas o financeiro não precisa disso). Ah! E as vias passando de mão em mão são naturalmente uma comunicação assíncrona! Pensa em uma pilha de recibos em cima da mesa esperando pra ser processado ;)

[@guijas9981]

@@antoruby analogia perfeita!

[@moisesdematosgil7860]

De fato, quando o assunto é Microserviço, acredito que esse é o ponto de maior cautela... duplicação de dados, conexoes inter-serviços, etc...

[@JhonatanMorais]

Como vc perguntou no final, acho seria bem bacana mostrar o fluxo dos dados, os eventos e a recebição deles. Ver o código ajuda, mas depois de muito tempo passei a preferir aprender como são as "Regras e passos do negocio". código mesmo a gente corre atras de fazer afinal uma mesma coisa pode ser codada de zilhoes de formas. desde que o input e output sejam os mesmos esperados

[@Guilherme22914]

Esse formato é massa demais!!

[@wiliancalora8334]

Vídeo Espetacular como sempre! Concordo completamente. O Elemar Junior da Eximia também segue essa mesma linha. Valeu por compartilhar esses conhecimentos.

[@JojiGaijin]

Muito bom, fiz um curso de banco de dados e consegui absorver como funciona o microserviço na prática Maneiro de mais.

[@marcioferlan]

Diego, parabéns pelo vídeo. O formato ficou top! Gostei muito da stack adotada para os projetos de backend isolados, também comecei a usar o Nest recentemente e estou gostando muito. O conceito que você apresentou faz muito sentido com a forma que vejo arquitetura distribuída. É realmente uma mudança de paradigma e traz seus desafios também. Achei super bacana a ideia de você mostrar aplicações reais. Queria algumas ideias para monitoramento, governança e atualização de microsserviços desacoplamos e interdependentes. A sugestão do Deschamps é muito boa. Trazer pessoas com experiência prática para abordar assuntos de interesse da comunidade e, quem sabe, mostrar um pouco de código seria bem legal. Grande abraço!

[@dieegosf]

Boa, no próximo já quero trazer código nessa parte :)

[@rvettorassi]

Mereceu meu like. Parabéns!

[@MarceloTononChiovatto]

Fala Diego! Dizer que esse conteúdo é super interessante seria "chover no molhado" :). Obrigado por abordar, colocando luz sobre o tema! O título desse vídeo é a essência do que muitos Devs sentem quando têm o primeiro contato com os microsserviços. Acho que de uma maneira bem natural, os paradigmas de normalização de bases de dados são primeiro "dogma" dos BDs relacionais que enfrentam resistência cognitiva em serem quebrados. Acho que a dúvida que você teve, todos nós temos também!!! Distribuir dados (gerando redundância), os quais, em tese, deveriam ser únicos, é como "tirar um chão" (que sempre esteve ali) sob os pés de quem há bastante tempo se calça nas Formas Normais de normalização de BD relacionais. As razões pelas quais isso DEVE acontecer (não tenho dúvidas, ou pelo menos não muitas kkk) nem sempre estão muito claras para todos. Resolvi então escrever, sob a ótica de quem está gostando muito do conteúdo, para fazer uma humilde sugestão para outros vídeos sobre o tema: Seria legal expor o Cenário, no que se refere a requisitos não funcionais. Explico melhor abaixo, mas creio que na cabeça do Dev ainda não ficam claras todas as questões que os microsserviços se propõem a solucionar. Creio que a quebra de paradigma do BD Relacional e das aplicações monolíticas se justificam quando colocamos elementos adicionais para a solução de requisitos não funcionais. Traduzindo em miúdos, o cenário para o qual os microsserviços são uma solução necessária me parecem associados a: 1o. Desacoplamento, considerando uma visão pura de manutenibilidade, disponibilidade e escalabilidade; 2o. Volume x tempo de resposta, considerando um requisito não funcional importantíssimo para aplicações de grande porte; Será que estou certo? Ou será que estou viajando no espaço sem propulsores? :) Acho que fundamentar a decisão sobre quando quebrar os paradigmas e quando não, em detrimento de alguma razão clara e mensurável, é um tema muito muito importante. Seria muito bacana expormos isso para a comunidade dar um próximo passo de maturidade em relação às suas decisões de arquitetura. Teremos mais condições de decidir que tipo de foguete a gente usa para ir para Lua e que tipo precisamos para ir a Marte. Um grande abraço e muito, muito obrigado por expor temas tão relevantes e importantes para nós desenvolvedores. O trabalho da Rocketseat não tem paralelo em termos de qualidade, relevância para o mercado e amadurecimento ágil dos Devs. #tamojunto

[@acm.marques]

Interessante a forma de pensar para micro service e eu aprendi muito de arquitetura com vc hoje, trabalho com react native mas gosto também de backend.

[@gustavomontirocha]

Muito bom! Quero ver isso tudo na prática e de preferência abordando como ficariam serviços separados com integridade referencial (ex se vc tivesse um microservico de turmas e outro de alunos).

[@rodrigoruiz976]

Como você lida com a questão de paralelismo e concorrência sem colocar a trava no banco de dados? Por exemplo, suponha que você queira atualizar um campo, mas só se ele estiver com um valor específico. Se chegarem dois requests ao mesmo tempo, um pode acabar sobrescrevendo o outro se você não tiver uma transaction no nível do banco que junta a consulta do valor com a atualização. Só que colocar no nível do banco começa a ficar ruim quando essa condição passa a precisar de mais de um banco.

[@caos-caos-caos]

Muito obrigada por compartilhar!

[@goodvandro]

Excelente didática e o novo formato de video! Estou ansioso para aprender mais sobre microserviços. Gostaria de ver a parte prática.

[@edufabricio]

Cara é isso ir com cautela é o caminho !! não ir no by the book.. a granularidade correta , na real quantidade de equipe influencia na divisão neh.. não é so a visao de negócio mesmo.. show legal começar a levar essa cultura pro publico geral ajuda a comunidade a evoluir na maturidade.

[@vinidotnet]

O que me ajudou no início foi tentar visualizar, mentalmente, como vc criaria um serviço para ser um produto único e separado. Um serviço que vc poderia até mesmo oferecer o uso dele pra outra pessoa/empresa sem precisar acoplar. Seguindo o exemplo do vídeo vc teria um produto que oferece serviço de e-mail e que sua única responsabilidade é lidar com os e-mails. Então nele teria o seu banco próprio para gravar/consultar os dados necessários pro envio (remetente, destinatários, corpo do e-mail, etc) e os dados de envio quando finalizado (data, hora, solicitante e etc). E quando precisar de consultar algo relacionado aos envios de e-mail ele seria o "source of truth".

[@dieegosf]

Perfeita essa forma de pensar.

[@miguelpanuto3820]

Na empresa onde eu trabalho, como usamos o azure pra tudo, acaba sendo utilizado o servicebus da microsoft em ambientes buildados pelo CI/CD, e em ambiente local é utilizamos o RabbitMQ, por realmente ser mais fácil. Outro fato interessante sobre, é que utilizamos muitas vezes mais de um MS pra uma feature, sendo muitas vezes um pra entrada do dado (podendo ser http2 ou amqp) e outro que utilizar esse dado pra alguma coisa, seja pra transforma, armazenar e tudo mais. Esse mundo de integrations é muito louco, cada dia me empolgo pra aprender mais sobre!

[@andresdosantos5310]

Esse trio Nest + Graphql + Prisma eu vou estudar no ano que vem. E o formato tá bem legal, ainda mais descontraído.

[@tgbaldo]

Eu só não costumo usar o termo "dados duplicados", pois pode soar pejorativamente e algumas pessoas acabam entendendo errado (experiência própria), então eu uso o termo "dados distribuídos". E se vc não trabalhar dessa forma, vai matar uma das principais vantagens da arquitetura de micro-serviço: não ter um único ponto de falha. Mas, além do desafio de manter os dados distribuídos, é lidar com transações distribuídas nessa arquitetura, aí a coisa vai ficando mais complexa, mas existem patterns para resolver isso, como SAGA, por exemplo. Sem contar que, pode acontecer do seu Message Broker falhar, e a mensagem não ser entregue ao micro-serviço X, e você acabar tendo problemas de dados inconsistentes ou até mesmo a falta deles em algum micro-serviço. Enfim, trabalhar com esse tipo de arquitetura requer um certo cuidado, estudo, testes, etc. Sugiro a leitura do livro "Microsserviços prontos para produção" da Susan J. Fowler (Ex Gerente de SRE da Uber).

[@rmedola]

Ficou legal o modelo. Utilizo serviços parecidos, porem o BD é único. Cada serviço consome o que lhe interessa da base. Obviamente o tuning da base fica justo pra aguentar a carga. Backup, replicação também são pontos sensíveis.

[@hexemeister]

Poderia fazer um POC de microserviços pra gente acompanhar o desenvolvimento

[@MrTheMcfrago]

nest é top. estou fazendo um serviço em NestJS de disparo de notificação SMS (também por voz), EMAIL e push notification para um banco (banco mesmo $) de MG. da pra fazer tudo nele para a api e lambdas

[@guilhermeabreu8459]

Parabéns pelo conteúdo publicado Diego, me pegava na mesma dúvida que vc, mas com este vídeo, felizmente, abriu ainda mais minha visão sobre o assunto...

[@rocketseat]

Que feedback massa, Guilherme! Valeu demais! 😍 🚀

[@frkdev]

Mais um dos infitos acertos da rocket esse formato ta f e n o m e n a l!! Parabéns!!!

[@chewbacca01]

Que incrível Diego! vídeo maravilhoso, to adorando esse formato vlog.

[@rocketseat]

Que massa que ta curtindo, Alex! Valeu demais pelo feedback! 💜 🚀

[@TheFigueiredorj]

Viva, Pergunta : Como foi planeado o warmup dos serviços (email services), quer dizer no reboot, como alimenta a colecção inicial?

[@CaioOliveira-bc9fr]

A duplicidade de dados e comunicação assíncrona também foram meus principais pontos de dificuldade para entender, mas depois disso as coisas ficam um pouco mais fáceis. O próximo nível que eu estou enfrentando agora é na prática. Tentei ir para um lado mais simples ainda, os domínios nem sequer estão em projetos diferentes, apenas foram separados de uma forma modular, onde sua comunicação já é feita utilizando eventos, porém de forma síncrona. O banco de dados é único para toda a aplicação e não possui duplicidade, mesmo que na camada de domínio exista contextos diferentes com dados duplicados. Essa foi a maneira que encontrei para já desenvolver esse projeto em especifico com microserviços em mente, pois sei que ele precisa escalar e não queria desenvolver novamente partes dele.

[@gustavocaetanoreis8882]

Muito bom trazer código e desenhos.. Estou curtindo muito os episódios! Parabéns!

[@rocketseat]

Que massa que ta curtindo o novo formato, Gustavo! Valeu demais pelo feedback! 💜 🚀

[@luosnv]

salve rocket, vai ter video de Github-cli?

[@pablodanilomota]

Fala Diegão! manda esse vídeo de toda essa estrutura na prática!! haha e fiquei surpreso com a parte de duplicação de dados entre os serviços, feito por integração 🤯 e aqui na FIRMA, estamos planejando usar Nest + Graphql + Prisma nos próximos projetos :PPPPP muito massa o conteúdo!! 🚀

[@dieegosf]

Maaaaaassa demais!

[@matheus_jones]

É quando começamos a falar de softwares mais complexos que fica evidenciado a importância de uma boa arquitetura. Muito bom você citar o site do Martin Fowler. Talvez seja legal também citar o livro dele DDD, e também começar a introduzir o conceito de eventos de domínio, que, facilitam a compreensão de como serviços podem se comunicar de maneiras mais compreensíveis. Uma observação para os novatos (me incluo nessa), que eu acho que não ficou bem explicado. Serviços distribuídos não podem ser síncronos, pois, isto diminui a disponibilidade. Afinal, quando um serviço cai, os outros que dependem deste, ficam indisponíveis também. No entanto, quando os serviços que dependem entre si, são assíncronos e caem, os que permanecem conseguem continuar operando. Outra observação: Nada é escrito em pedra, portanto, soluções que funcionam muito bem num determinado cenário podem não funcionar em outro.

[@mpgx.c]

Formato muito show, conteúdo muito bom, altissímo nível. \o/ a Daniele tem que trazer um code/drops nesse contexto hein! haha

[@dieegosf]

Booooooa, vamos cobrar ela! haha

[@maxuelllima2767]

Cara tô achando muito massa esse estilo de vídeo que vcs estão fazendo agora qualidade muito top.

[@rocketseat]

Que massa que ta curtindo esse formato, Maxuell! Valeu demais pelo feedback! 💜 😍

[@alexlekito819]

Achei incrível esse vídeo! Você consegui fazer eu entender de forma simples o porque de um micro serviço. Que venha o código! 😁👨🏾‍💻💻👊🏾💪🏾

[@cassiocarvalho9491]

Opaaa claro que quero ver mais sobre isso aee, se puder mostrar exemplos do uso como vocês fazem tô ansioso já

[@manoeltsf]

Estamos em um processo semelhante a esse. O monolito que foi criado chegou a um ponto de executar tantas ações que fica praticamente impossível acompanhar alguns erros ou mensurar algumas questões. A ideia de microservices parece ideal para nosso caso. O problema é que pouca coisa será reaproveitada e o problema principal está está ligado aos relacionamentos entre entidades do sistema, o que parece que será resolvido apenas com rotas restFull para todos eles ... Pelo menos parece até agora 😆. Conteúdo muito bom!

[@dieegosf]

Boa Manoel, mas lembre que uma arquitetura de micro-serviços traz ainda mais dificuldades na observabilidade da aplicação.

[@pe-sauloegito5198]

Curti demais esses conceitos. Já ouvi muito, mas ainda tinha dificuldade em duplicidade de dados. Valeu!!!

[@lucasiron8842]

Uma dúvida, nessa situação (22:04) não seria interessante ter um serviço de manipulação de usuário separado? Quero dizer, ao invés da aplicação A saber da aplicação B para enviar para ela a alteração de usuários, não seria melhor ter uma aplicação intermediária que receberia a alteração de A (ou de B) e dispararia tanto em A quanto em B o evento de alteração de usuário para que cada um lidasse como isso conforme suas necessidades?

[@joaobibiano]

Concordo 100% com a "opinião" do framework. Isso vai unificar a equipe e aumentar a produtividade! Muito massa! Cada ferramenta em seu quadrado e momento :) Recomendo o estudo do CAP theorem!

[@thedarkwithinc1]

Onde trabalho o pessoal utiliza o AWS SQS e um worker SpringBoot pra consumir a fila, mas algumas regras de negócio impedem que a comunicação seja assíncrona em todos os casos, na verdade, são poucos os casos que podem ser assíncronos (trabalho com sistema financeiro). Poderia falar um pouco mais se vcs utilzam api gateway e qual utilizam.

[@dieegosf]

Boa, a gente pensou em usar o SQS também, mas acaba que não queríamos ficar presos ao Cloud Provider.

[@GeraldoJr]

Diego mostra como ficou a infra também!

[@CalangoBit]

Muito bom! Legal programar a trigger na atualização da tabela de pessoas! Parabéns!

[@felipeleite11]

Excelente conteúdo! Queremos ver o setup do Kafka ou outra ferramenta de comunicação assíncrona.

[@georgearmando757]

Conteúdo muito bom, parabéns a ao grande Diego. A minha questão é a seguinte: Ao desenvolver uma aplicação, vou directamente para microsserviços ou começo por um monolítico? Porque parece que uma arquitetura em microsserviços poderá levar um pouquinho de mais tempo.

[@odev6764]

Diego uma dica ... troca uma ideia com a galera da netshoes de backend porque eles ja trabalham com microserviços a muito tempo e talvez possam te dar uma luz do que são aplicadas em cada aplicação .. contexto de problemas e coisas que possam ajudar. Inclusive eu sei que trabalham com o kafka, tem redis, tem rabbit e varios outras ferramentas ... talvez se você conseguir falar com eles vai te abrir uma luz .. sem contar que é mais conteúdo avançado pros videos...

[@joaobibiano]

Sugiro na parte dos logs adicionar um campo chamado "PlatformID", dessa forma, sempre que houver um erro, você consegue saber em qual micro-serviço a falha nasceu, melhorando a observabilidade.

[@dieegosf]

Fala João, cara, consegue dissertar mais sobre isso? Não entendi muito bem aonde adicionaria esse platform_id, na mensagem do Kafka?

[@joaobibiano]

@@dieegosf irá ser um atributo no body. O intuito é saber quem emitiu a mensagem, e nos logs (bugsnag, Kibana etc) também adicionar sempre esse identificador a fim de saber qual microserviço teve a excessão. No exemplo que você deu não se encaixaria, mas em microserviços, interdependentes, em que você abre mão da availability para ter o dado mais fresco, você vai ter uma requisição a ser trafegada entre 3, 4, ou mais serviços. Foi nesse intuito e cenário a sugestão.

[@thiagocola]

Dá uma olhada em HATEOAS - Hypermedia as the Engine of Application State, um modelo desenvolvido por Leonard Richardson.

[@pauloricardomaltaleal3558]

Vídeo excelente, tava estudando afundo mas não ficava claro, agora está como a água.

[@StanleySathler]

Pô, traz pra nós o próximo vídeo mostrando os serviços. Muito bom!!

[@jeanjunior-dev]

Catapimbas, o vídeo certo no momento certo. Estou passando exatamente pelo que o Diego de um ano atrás passou

[@moisesdematosgil7860]

@Diego, como tu pensa resolver a integração e chamadas de um serviço para o outro. Por exemplo, tu tem um ambiente de autenticação que guarda nome do usuario e data de nascimento, nao faz sentido duplicar esse dado em um outro Microserviço, logo esse outro microservico precisa vir buscar esse dado no ambiente de autenticação, como resolve isso? Voce integra via gRpc / SignalR ou joga a responsa para o front buscar isso? (Se bem que jogar para o front torna algo que antes era simples em algo bem mais complexo, pois no fim voce terá que chamar 3 endpoints para montar o que antes um endpoint unico retornava) Pois esse ponto é o mais problemático acredito eu.

[@moisesdematosgil7860]

Aaaah tu entra um pouco nesse assunto no minuto 11

[@moisesdematosgil7860]

Shooooooooooow demais esse video... Mas me incomoda muito manter os dados duplicados, mas se estamos falando de serviços independentes e desacoplamento total dos serviços, faz sentido. Kafka eu acho complexo demais, muito custoso. RabbitMQ me parece ser bem amigável... A ideia seria que cada MS seja um sistema que use uma metodologia de CQRS, onde, paralelo ao metodo de persistencia, ele avisa um serviço de fila para que os outros sistema peguem esse dado caso seja necessário.

[@newerton]

Eae Diegão, estou nos estudos e desenvolvimento de um projeto de microserviço, o escopo seria desenvolver uma Amazon ou Mercado Livre usando microserviços. De começo estou usando o NestJs e TypeORM, na comunicação entre os microserviço estou usando o Apache Kafka, e para as credenciais os usuários estou usando o KeyCloak, até o momento o que está desenvolvido é a api-gateway, user-engine, auth-engine e estou começando a desenvolver o product-engine, talvez esse projeto leve meses ou anos, mas estou aprendendo muito com essa nova metodologia de desacoplamento de responsabilidade de cada serviço. Talvez esse assunto seja interessante para todos, até para ninguem começar de formar errada em microserviços. Vou fazer um README lindão, e depois vou postar aqui os repositório desses microserviços.

[@dieegosf]

Booooooa, ia ser incrível compartilhar isso.

[@JoaoGomes-wy8gu]

Mais um video maravilhoso, um exemplo pratico de uma emplementação referida no video seria top!!!!!! Mas como sempre, conteudo de qualidade e de coração!!!!!!!

[@marcelolupatini5553]

26:26 Eu já conhecia essa área da arquitetura distribuída. Aprendi na faculdade, mas foi quase que puramente teórico. As práticas lá feitas foram irrisórias. Ainda não cheguei a colocar as mãos na massa, mas fazer um use case disso é um plano que tenho para um futuro próximo. Acho que todas essas ideias de sistemas distribuídos são muito interessantes e vantajosas em determinadas situações.

[@dieegosf]

No próximo vídeo pretendo trazer uma visão prática disso tudo.

[@rumoaotopo.s.a]

Massa Diego, parabéns pelo conteúdo, muito bacana essa abordagem. Já manda logo um #CodDrops disso tudo. Semana que vem já??? Kkkk

[@erinaldonascimento7733]

Nossa me apaixonei pelos vídeos de vcs , conheci pela Los grandes

[@LuizNotari]

Usamos banco de dados sob demanda no ambiente da nuvem Microsoft Azure e isso trouxe muita liberdade e muito menos preocupação com banco de dados. Num motor principal as regras de negócios e no front Nuxt. Alias no ambiente Azure tem muitos recursos sob demanda, inclusive esses envios de e-mail. De fato tem muita roda pronta para uso. Ah sim, no motor não abrimos mão do C#.

[@alexjosesilvati]

Gostei do vídeo .. mostrou bem embora resumida o que são microserviços e a mensageria

[@carlosjunior5371]

O grande desafio do desacoplamento é a consistência (Vide o teorema CAP). Para serviços que não guardam estado(Sem banco de dados), show. Agora pensando como Bounded Contexts do DDD por exemplo, é que a porca torce o rabo. Na maioria dos casos é praticamente inviável desacoplar sem usar Event-Driven com um serviço de mensageria.

[@thiago75501]

To nisso dai. Tenho o famoso exemplo de ecommerce onde quando realiza a compra o pessoal do estoque tem que remover um item do banco depois o pessoal do financeiro tem receber o dinheiro e por fim o pessoal do delivery entregar o produto. Caso ocorra um entre as transações o banco vai ficar inconsistente. To usando rabbitmq no spring e o pattern sagas.

[@douglas1alc]

Olá, Diego, gostaria de tirar uma dúvida: como fica a questão da autenticação e os hashs da senha do usuário na aplicação principal e o compartilhamento disso para as demais aplicações?

[@SitedoSobrinho]

Show de bola! Esse formato é bem bacana mesmo bem da hora...

[@valdineisantos7513]

Conteúdo show. Valeu 👍

[@rocketseat]

Que massa que curtiu, Valdinei! 💜 🚀

[@leonardodossantos4632]

No meu momento atual, estou implementando uma solução como essa, e com rabbitmq, estou gostando bastante.

[@AlexandreHPiva]

Fala Diego! Você acha que seria interessante a criação de uma rotina de sincronização das bases de tempos em tempos? A ideia seria validar os dados no caso de quedas no microserviço de envio de e-mails onde ele acabou não "escutando" alguns eventos emitidos pelo serviço principal.

[@thiago75501]

Podiam falar tbm de monolíto estruturado.

[@rcosta7239]

Outro ponto é que um microservico nunca deve consultar o banco de dados do outro. Nem se quer deveria saber se o outro serviço usa ou não banco de dados. A comunicação deve ser direta com a fila de mensageria. Assim você garante desacoplamento e independência entre os serviços.

[@rgsnobody]

Finalmente uma opinião lúcida sobre microsserviços.

[@rocketseat]

Curtiu o conteúdo, Rodrigo? 💜

[@ivanvinicius8317]

Fala Diego, acho que seria massa trazer mais sobre a parte prática!