Smashing Podcast Episódio 6 Com Luca Mezzalira: O que são Micro-Frontends?

Terminamos este ano com mais um podcast Smashing! Desta vez, falaremos sobre micro-frontends. O que é um micro frontend? Como isso é diferente do tipo de abordagem que podemos estar adotando no momento? Vamos descobrir com o pioneiro do micro-frontend, Luca Mezzalira.

Mostrar notas

Atualização semanal

• “Adicionando funcionalidades dinâmicas e assíncronas aos sites JAMstack”, Jason Lengstorf
• “Ferramentas de dados quantitativos para designers de UX”, Adonis Raduca
• “Criando habilidades de voz para o Google Assistant e Amazon Alexa”, Tris Tolliday
• “Além do Sprint 0: uma alternativa para integrar equipes”, Shamsi Brinn
• “Ajudando os navegadores a otimizar com a propriedade CSS Contein”, Rachel Andrew

Microfrontends

• Site de Luca Mezzalira
• Lucas no Twitter
• “Micro-Frontends, o futuro das arquiteturas de front-end” no Medium
• Mais dos escritos de Luca sobre micro-frontends podem ser encontrados em sua conta no Medium
• O livro de Luca “Front-End Reactive Architectures”

Transcrição

Drew McLellan: Ele é um desenvolvedor do Google especialista em tecnologias da Web e gerente da comunidade JavaScript de Londres. Com mais de 15 anos de experiência, ele atualmente trabalha como vice-presidente de arquitetura, projetando a plataforma de vídeo esportivo DAZN, que oferece conteúdo esportivo sob demanda para milhões de usuários assistindo ao vivo. Ele é o autor do livro Front-End Reactive Architectures for Apress e também é revisor técnico da Apress, Packt Publishing, Pragmatic Bookshelf e O'Reilly, além de ser um orador público experiente em conferências técnicas em todo o mundo. Ele é italiano, tem uma barba bonita e claramente conhece profundamente a plataforma da web. Mas você sabia que ele cruzou a América do Sul em um avestruz? Meus amigos, por favor, dêem as boas-vindas a Luca Mezzalira. Olá, Lucas. Como você está?

Luca Mezzalira: Estou arrasando.

Drew: Eu quero falar com você hoje sobre o assunto de micro-frontends. Agora, este é um conceito completamente novo para mim, certamente pelo nome, e espero que seja novo para muitos de nossos ouvintes também. Antes de entrarmos nos micro-frontends, acho que devemos entender o problema que você quer resolver com eles. Então, talvez você possa nos contar um pouco sobre como você vê os aplicativos de uma maneira mais tradicional e que tipo de problemas essas coisas atingem que talvez os micro-frontends possam ser a solução?

Luca: Ok, esse é um bom ponto de partida, na minha opinião. Geralmente, quando você implementa ou projeta um novo projeto de campo verde e deseja trabalhar com aplicativos front-end, você tem algumas arquiteturas que podem ser aproveitadas. Você pode usar um aplicativo de página única, um aplicativo de renderização do lado do servidor ou um aplicativo de várias páginas composto por apenas páginas HTML simples. Obviamente essas são opções super válidas e acho muito usadas por muitos, muitos desenvolvedores. O problema real que estamos tentando resolver aqui é como você pode escalar esses conceitos com equipes distribuídas para centenas de desenvolvedores trabalhando na mesma base de código, porque a realidade é quando você trabalha nessas plataformas em particular, quando pensa em Plataforma SaaS, por exemplo, você precisa ter vários desenvolvedores e várias equipes trabalhando no mesmo projeto. E obviamente a forma como, por exemplo, você faz a aquisição ou retenção é completamente diferente na forma como você expõe o catálogo ou como você mostra uma parte específica de uma plataforma.

Luca: Agora, na minha experiência, trabalho muito com aplicativos de página única. Trabalho com aplicação de renderização do lado do servidor, mas em algum momento do DAZN me pediram para pensar em uma maneira de dimensionar nossa equipe técnica. E eu preciso chegar… se para backend temos alguma solução que são microsserviços neste caso, para que possamos escalar nossas APIs de forma independente, e levar em consideração que a escala e o volume para uma taxa de transferência específica em uma API específica. No front-end, realmente, é realmente mais difícil porque se você pensar nisso, não terá problemas técnicos para resolver quando precisar dimensionar, se estiver usando um aplicativo de página única, por exemplo. Provavelmente para uma renderização do lado do servidor você tem alguns, mas em um aplicativo de página única, por exemplo, é distribuído por natureza porque está no lado do cliente, diferente do lado do cliente.

Luca: Então a única coisa que eles estão carregando são apenas alguns arquivos estáticos como CSS e HTML e JavaScript que são servidos por CDN, e nesse caso você pode escalar de acordo, não é um grande desafio. Mas o verdadeiro desafio é como você escala as equipes que trabalham na mesma plataforma, porque às vezes os desafios enfrentados por uma equipe podem ser completamente diferentes dos desafios enfrentados por outra equipe, e geralmente o que você faz é tentar encontrar muitas trocas entre as coisas. Porque se você pensar, vamos tentar pensar em um caso de uso normal. Então, geralmente, quando você inicia uma plataforma, você está começando pequeno. Então você tenta criar aquele aplicativo rápido de página única, assim como você tem seu monólito, então você apenas configura tudo em seu CICD apenas uma vez para front-end e back-end, e então você começa a iterar em sua lógica. Mas a realidade é que quando você tem sucesso, você precisa evoluir essa parte, e nem sempre é manter a mesma arquitetura que poderia, digamos, gerar o benefício para o seu negócio, porque talvez você encontre alguns gargalos.

Luca: Agora, voltando à parte do aplicativo de página única. Portanto, se quisermos dimensionar uma parte de aplicativo de página única, o desafio não é técnico, é com humanos, se você quiser. Então, como podemos escalar equipes que trabalham no mesmo aplicativo. Então, o que eu fiz há alguns anos foi começar a olhar para uma possível arquitetura e princípios que me permitiriam dimensionar o front-end e o back-end. Então, trabalhando nos princípios de back-end para que você possa encontrar os microsserviços. Comecei a olhar para a solução diferente e eles saíram com os micro-frontends que no começo nem chamávamos assim porque obviamente há anos atrás não havia, digamos, esse nome para essa arquitetura específica .

Luca: Mas a realidade é pegar um monólito, então um aplicativo de página única e cortá-lo de uma maneira que nos permita focar em um pequeno problema. Portanto, um problema menor que todo o aplicativo e tentar resolver isso da melhor maneira possível. Tecnicamente falando. Obviamente, isso leva a ter partes independentes do seu aplicativo front-end que podem ser implantadas em produção sem afetar todas as outras. Portanto, o desafio basicamente para o Micro-frontend é tentar descobrir uma maneira de pegar um aplicativo de página única ou aplicativo renderizado no lado do servidor e criar um artefato deles, digamos, o mais próximo possível de um domínio de negócios e possa ser implantado independentemente .

Drew: Quer dizer, você mencionou micro serviços no back-end. Então, conceitualmente, este é um tipo semelhante de solução para o problema. Os microsserviços servem no back-end, mas são portados para o front-end. Isso é uma equivalência aproximada ou está mais envolvido nisso?

Lucas: Sim. Não, é uma maneira de resolver o mesmo problema que está tentando resolver microsserviços no back-end, mas no front-end neste momento. Normalmente, quando eu comecei essa jornada no começo, você sabe, você começa a pensar sobre isso e começa a avaliar diferentes abordagens. E nos últimos meses eu criei o que eles chamam de framework de decisão Micro-frontend que basicamente são quatro etapas que eles usam para, digamos que você identifique uma abordagem para Micro-frontend, porque se até agora, nós geralmente escolhemos um framework que projetou a arquitetura para nós e implementamos em cima de sua arquitetura. Se você pensa em angular ou pensa em React ou Redux. Você tem todas as peças necessárias, mas não toma decisões arquitetônicas. Você tomaria decisões de design ou como implementar em cima dessa arquitetura específica.

Luca: Então no Micro-frontend você precisa começar o passo atrás. Portanto, precisamos pensar em como queremos primeiro fatiar nosso aplicativo. Portanto, geralmente há duas opções para isso. Você pode dividir horizontalmente, para que possa ter vários microfrontends na mesma visualização ou pode dividir verticalmente. Portanto, você sempre carrega um Micro-frontend por vez. E essas decisões são bastante importantes porque, em seguida, elas irão cascatear algumas outras opções que você tem com base na decisão inicial a ser tomada. Então, o primeiro, como eu disse, você decide como deseja dividir seu aplicativo. A segunda é como você deseja compor seu aplicativo. Então você quer ter, por exemplo, um shell de aplicativo que está carregando um ou vários micro-frontends na mesma visualização. Você quer ter, sei lá, servidor de aplicação que esteja compondo diferentes fragmentos de suas aplicações, de modo diferente Micro-frontend e então servir a visão final para seu usuário. Ou você quer usar o edge-side incluído, é um padrão que está dentro das CDNs para compor uma página e servi-las lá.

Luca: Essas são três das opções que você tem. E, além de compor, você precisa pensar em como deseja rotear. Então, como você roteia de, eu não sei, /login ou /signin para a parte do catálogo ou um objeto de detalhe específico. Também aqui você tem três opções. Você pode fazer isso no servidor de aplicativos, no nível da CDN com o Lambda Edge ou qualquer outro web workers no CloudFlare ou qualquer outra coisa. Ou você pode fazer um site de cliente. Então você tem uma lógica dentro do shell do seu aplicativo que você diz, ok, agora para essa URL específica você precisa carregar outra view ou outro micro-frontend. E a última parte é como você se comunica com o Micro-frontend.

Luca: Normalmente, se você tem vários Micro-frontends na mesma página, há uma maior complexidade no gerenciamento dessa comunicação, porque você precisa manter os diferentes Micro-frontends independentes. Isso significa que você não pode ter nenhuma referência sobre como a página está estruturada. Então, geralmente você pode usar coisas como eventos personalizados ou um medidor de eventos que é injetado dentro de cada Micro-frontend. E então o Micro-frontend está se comunicando. Obviamente, no outro caso, quando você tem, digamos, uma divisão vertical do seu Micro-frontend é muito mais fácil, porque dentro da vertical basicamente a representação de um Micro-frontend vertical é um aplicativo de página única ou uma única página. E, nesse caso, é mais fácil, digamos, criar e compartilhar com um estado compartilhado em todo o Micro-frontend.

Luca: Então, se você pensa em ter vários Micro-frontends juntos, evite ter estados compartilhados em Micro-frontends, porque senão você está acoplando as coisas. Em vez de todo o conceito aqui é desacoplar e ter implantação independente. E, portanto, digamos que os desafios de uma divisão horizontal, que é a primeira decisão que você deve tomar ou divisão vertical, são completamente diferentes, e precisamos estar muito bem cientes de qual se encaixa no nosso caso de uso.

Drew: Então, em vez de uma solução técnica específica, os micro frontends são muito parecidos com um padrão de design que você implementaria em qualquer tecnologia apropriada para o problema específico que você está tentando resolver?

Luca: Sim, mais do que tecnologia, eu veria que escolhemos a arquitetura certa para o trabalho certo. Só para dar um exemplo, eu estava falando… existe um framework famoso, bastante novo para Micro-frontend, é chamado de framework Luigi, que foi lançado pela SAP open source. O que eles estão fazendo é criar alguns iframes onde estão envolvendo seu Micro-frontend dentro dele. Então, agora, se você pensar nisso, digamos, usando iframes hoje em dia, você está em um site público que talvez como o SEO ou outros recursos obrigatórios, pode ser problemático.

Luca: Mas no caso do SAP, se você pensar sobre isso, eles têm um aplicativo corporativo onde eles podem controlar o navegador que o usuário está usando, eles podem controlar o ambiente, eles não precisam estar disponíveis em vários versão diferente do navegador. Então, para eles, isso permite que eles tenham certas áreas do aplicativo que são constantes e têm certas áreas que estão mudando independentemente, sem nenhum problema. Mas obviamente uma solução iframe não funcionaria em outra situação. Só para dar outro exemplo, Spotify, estamos usando iframes no início. Na verdade, a publicação eletrônica ainda é composta por vários iframes e cada iframe é um pequeno aplicativo que faz, não sei, apenas um reprodutor de música ou apenas sua recomendação, seja lá o que for. Eles tentam ter a mesma abordagem na web, mas descartaram isso este ano para voltar a um aplicativo de página única.

Luca: E isso significa que eles explicam por que no blog técnico, eles estavam dizendo que, obviamente, se você aplicar isso a milhões de usuários que estão usando iframes, isso precisa ser carregado toda vez que o mesmo arquivo de fornecedores. E então você tem muitas dependências duplicadas e o tempo para interagir com sua página seria maior. Então, na realidade, essa abordagem pode ser adequada para determinados casos de uso, mas não para todos eles. É por isso que estou dizendo, como descrevi antes, se você tem uma estrutura de decisão que o ajuda a resolver essas coisas e pode começar a dizer, ok, eu cortei o aplicativo dessa maneira, portanto, tenho essas opções disponíveis quando eu quero compor, quando eu quero rotear, quando eu quero comunicar, ele deve te guiar para ter a decisão certa na hora certa.

Luca: Obviamente, além dessas quatro decisões, há muitas outras. Como como você cria consistência no sistema de design que você tem em todo o Micro-frontend. Ou não sei como você gerencia as dependências e evita o choque da dependência dentro do Micro-frontend, mas a realidade é que essas quatro decisões que mencionei antes permitirão que você tome todas as outras de maneira rápida sem ter o problema de pensar demais, que é a melhor solução porque você já colocou a pedra angular, os quatro pilares, que vão permitir que você tome todas as outras decisões… não digo de maneira fácil, mas de forma mais rápida do que uma revisão ou o espectro de oportunidades.

Drew: Você mencionou antes, a maneira como o Micro-frontend pode ajudar com o tipo de estrutura de equipes dentro de sua organização e ter muitas pessoas trabalhando no mesmo aplicativo. Quais são algumas das implicações então e faz alguma diferença se suas equipes são distribuídas ou co-localizadas ou se há algum desafio enfrentado lá?

Lucas: Sim. Então posso contar qual é a história do DAZN. Essa é a empresa em que estou trabalhando. Atualmente no DAZN, tivemos um belo desafio. Atualmente, temos mais de 300 pessoas trabalhando no front e no back-end de nossa plataforma. É uma plataforma OTT que está transmitindo ao vivo em eventos esportivos globalmente. E o interessante é se todos os microsserviços sabemos gerenciar mais ou menos e temos equipes distribuídas. Portanto, temos quatro centros de desenvolvimento. Gostaríamos de colocar equipes em cada centro de desenvolvimento único na frente, e tentamos essa abordagem e funcionou muito bem. Assim, com o Micro-frontend, conseguimos fornecer diferentes domínios de negócios em locais diferentes e permitir a comunicação cruzada entre equipes dentro de um domínio de negócios específico, muito porque o pior cenário é que se você tiver que falar com outra equipe no mesmo domínio de negócios , basta chegar a uma curta distância de sua mesa. Se, em vez disso, você precisar discutir algo específico na equipe de distribuição, talvez com alguém em Londres em vez de Amsterdã, ou em vez de uma empresa na Polônia, basta organizar uma ligação.

Luca: Mas esses tipos de comunicação são mais raros do que os que estão acontecendo entre equipes dentro do mesmo local. E é por isso que começamos a trabalhar nisso. Então, a primeira coisa que eles fizeram foi ver como nossos usuários estavam interagindo com nosso site, como a empresa estava estruturada. E quando identificamos as quatro áreas principais em que estamos trabalhando, que atualmente são aquisição e retenção, digamos, portar seu aplicativo principal em várias TVs e dispositivos móveis e ter o domínio principal que para nós é o player de vídeo e a fase de descoberta de nosso conteúdo. E, finalmente, todos os elementos de back office. Consegui identificar essas quatro áreas e as quatro áreas que designamos para cada centro de desenvolvimento.

Luca: Obviamente, existem alguns pontos de contato entre essas áreas, mas existem maneiras de, digamos, mitigar e ter algum workshop inicial com as diferentes equipes que estão em locais diferentes e depois trabalhar para o mesmo contrato de API, por exemplo, ou o mesmo objetivo de ter alguns checkpoints durante o desenvolvimento. Mas o legal da abordagem que permitiu a abordagem com Micro-frontend é o fato de que finalmente entendemos profundamente como nosso sistema estava funcionando. Sentamos e analisamos como estávamos estruturados e mudamos não só a forma como fomos afetados, mas também como a empresa estava funcionando. E essa foi uma abordagem diferente do que eles viram até agora. Mas está provando que está funcionando muito bem no caso de cada equipe poder interagir com a equipe do mesmo local no mesmo domínio.

Luca: Então eles estão falando exatamente na mesma linguagem se você estiver falando sobre o design orientado a domínio. E isso é que se eles precisarem interagir com outras equipes, eles podem literalmente compartilhar o workshop ou voar para outro centro de desenvolvimento e isso é menos que um problema. Mas dessa forma, digamos, aumentar a taxa de transferência e reduzir a sobrecarga de comunicação e a extensão das dependências que estavam acontecendo em outra situação em que eles estavam trabalhando.

Drew: E todas essas equipes precisam usar como uma estrutura JavaScript padronizada? Todos eles precisam codificar as mesmas coisas, todos precisam ser React ou Angular ou permitir a interoperabilidade entre eles ou as pessoas podem usar coisas diferentes para diferentes Micro-frontend?

Lucas: Sim. Então, no DAZN, decidimos dividir verticalmente nosso Micro-frontend e essa foi uma decisão que nos permitiu ter a liberdade de escolher a tecnologia que precisamos para cada Micro-frontend. Considerando que toda vez que carregamos um Micro-frontend por vez e isso significa, por exemplo, que a forma como temos uma página de destino é diferente da jornada de login / inscrição. Para que possamos atualizar... estamos usando principalmente React no momento. Mas se, por exemplo, eu me lembro de quando o React 16 era um lançamento que nós conseguimos lançar em produção o React 16, também se ele não estava na versão estável para apenas uma landing page e ver se estava funcionando sem afetar todos os outras equipes.

Luca: E então, em seu próprio ritmo, em seu próprio ritmo, eles estavam atualizando suas próprias coisas. Então isso nos permite também, digamos, tentar novas tecnologias ou novas suposições que temos sobre o aplicativo existente com uma certa quantidade de usuários. Porque implementamos as versões também candidatas para front-end. Implementamos, digamos, várias práticas que nos permitem apenas experimentar certos momentos na produção e ver como as coisas estão funcionando.

Luca: A beleza dessas abordagens é que podemos decidir independentemente ter a ferramenta certa para o trabalho certo mais do que ter um denominador comum em toda a pilha. Porque como você pode imaginar, quando você começou a trabalhar em um projeto, a decisão que você tomou nos primeiros anos provavelmente é diferente da decisão que você tomou em uma trajetória onde a empresa está crescendo, o negócio está evoluindo e estes se tornaram mais maduros e o desafio é completamente diferente. Então não seria flexível o suficiente ou ágil o suficiente, se você pensar sobre isso, o fato de continuarmos com a mesma decisão que tomamos há dois anos. Em particular uma instituição como o DAZN, que passamos de basicamente zero para 3.000 funcionários em três anos. Então, como você pode imaginar, foi um grande crescimento e foi um grande crescimento para a empresa e também para a base de usuários.

Drew: Existe uma maneira estabelecida para que os diferentes Micro-frontend compartilhem dados e se comuniquem, por exemplo, apenas para manter um ao outro em sintonia com a mesma visão ou existe uma maneira de fazer isso?

Lucas: Sim, existe. Depende de qual estrutura de decisão, qual caminho você vai tomar. Porque se for pegar o slice vertical ficou muito fácil. Então, o que temos para nos comunicar através do Micro-frontend é um shell de aplicativo que está sendo carregado no Micro-frontend dentro de si mesmo. E o que ele faz é armazenar tudo o que precisa ser, digamos, compartilhado em diferentes Microfrontends ou em um armazenamento na web, seja uma sessão ou armazenamento local ou na memória. E então, com base nessas informações, o Micro-frontend é carregado, pode recuperar do shell do aplicativo essas informações e consumi-las, corrigi-las ou alterá-las. Depende completamente de como você divide o aplicativo, mas neste caso, apenas para fornecer um exemplo, se você pensa quando é usuários autenticados e precisa ir para a página de login, quando você entra e as APIs são consumidas e eles estão fornecendo um token JWT, o Micro-frontend está passando isso para o shell do aplicativo e o shell do aplicativo.

Luca: Depois disso, o shell do aplicativo está carregando a nova área autenticada para esse aplicativo específico e essas áreas autenticadas, eles estão recuperando o token JWT do shell do aplicativo e executando um token de acesso de atualização ou validando alguns dados começando dentro do Token JWT. Então está usando basicamente as informações que foram produzidas por outro Micro-frontend em sua própria roda.

Drew: Parece um conceito muito interessante e posso ver muitas grandes vantagens em trabalhar dessa maneira, mas não pode ser sem seus desafios, com certeza. Existem coisas específicas que são mais difíceis de lidar ao arquitetar as coisas dessa maneira?

Luca: Acho que, em primeiro lugar, os principais desafios que vejo são a mudança de mentalidade. Porque antes estávamos acostumados a ter, digamos, líderes de tecnologia ou desenvolvedores líderes que decidiam tudo em torno de um aplicativo inteiro tomando todas as decisões. Agora, finalmente, passamos dessa entidade centralizada para uma entidade descentralizada que é local para cada estado. Como você pode imaginar, isso está trazendo alguns desafios porque se antes tínhamos alguém que está traçando o caminho, agora é que temos, digamos, várias pessoas no topo definindo o caminho certo dentro de seu domínio, e isso é uma grande mudança de mentalidade.

Luca: Por outro lado, acho que a complexidade é aceitar às vezes que fazer a abstração errada pode ser, digamos, mais caro do que duplicar código. E eu sei que há algo que achei muito desafiador no gerenciamento de desenvolvedores porque eles estão pensando: “Ok, agora posso reutilizar esse objeto ou essa biblioteca específica centenas de vezes dentro do projeto”, mas a realidade é muito diferente. Eu vi bibliotecas de componentes que eram abstratas e eles gastam muito tempo fazendo isso como o melhor código de todos os tempos ou o melhor em uma forma perfeita. Mas a realidade foi usada apenas duas vezes. Então o esforço de fazer isso, não era exatamente isso. Vi nas bibliotecas do outro lado que elas começaram com alguns casos de uso para um componente específico. E então esses casos de uso se tornaram 10 e então o código se tornou insustentável.

Luca: Então, tentar adicionar uma nova função dentro do mesmo componente pode ser mais arriscado do que benéfico. Então, acho que a outra coisa que precisamos entender com o Micro-frontend é o quanto queremos compartilhá-lo e o quanto queremos duplicar. E não há mal nenhum, honestamente, duplicar. No nosso caso, por exemplo, temos uma duplicação de rodapé e cabeçalho, e fizemos isso principalmente porque mudamos três vezes o cabeçalho em quatro anos. Então, como você pode imaginar, o fato de estarmos centralizando isso, ser atribuído a uma equipe e criar uma dependência externa para todas as equipes, todas as centenas de desenvolvedores que temos, é mais um problema do que um benefício para a empresa, porque não estamos agregando um valor enorme.

Luca: Ao mesmo tempo, atualmente estamos refatorando nossas bibliotecas compartilhadas que seriam bibliotecas de pagamento, porque obviamente o pagamento tem alguma lógica por trás disso e se quisermos mudar uma vez, não queremos aplicar isso duas vezes em várias partes do código. Queremos ter apenas uma biblioteca que seja uma fonte de verdade, mas para o cabeçalho e rodapé, também se houver uma discrepância ou por pixel ou houver uma função que seja implantada uma semana depois, não prejudicará o inscrição.

Drew: Então, existem alguns sinais indicadores que as pessoas devem procurar ao avaliar um aplicativo e pensar: “Ah, sim, esse seria um bom candidato para migrar para um tipo de arquitetura Micro-frontend?”

Luca: Sim, então minha sugestão seria, em primeiro lugar, eu não iniciar um projeto greenfield com Micro-frontend a menos que saibamos exatamente como ele deve ser construído. E geralmente é muito improvável que você tenha essas informações porque, principalmente se você tem uma nova plataforma ou um novo projeto e é a primeira vez que está trabalhando nisso, pode ser uma tarefa não trivial encontrar essas informações. Normalmente, o que eu sugiro é começar com uma arquitetura existente que seria um aplicativo de página única e depois evoluir isso. Em particular, por exemplo, descobri que acho que usar o Micro-frontend para aplicativos legados ou quando queremos substituir parte específica do aplicativo ou quando temos um projeto que queremos evoluir e dimensionar para várias equipes, esses são três casos de uso que eu sinto muito forte poderia se adequar à arquitetura Micro-frontend. Obviamente isso não significa que de agora em diante tudo deva ser feito de Micro-frontend, porque Micro-frontend não é a bala de prata.

Luca: O que eles são é uma arquitetura adicional que podemos aproveitar no mundo do front-end. E até agora tínhamos uma certa quantidade de arquiteturas, agora temos uma adicional. Mas isso é um monte de desafios porque obviamente você precisa, se antes da renderização do lado do servidor ou de um aplicativo de página única, houver padrões claros que foram explorados e implementados por vários frameworks e assim por diante. Com Micro-frontend atualmente, é uma maneira de fazer as coisas. Mas adicionar a estrutura de decisão provavelmente deve permitir que as pessoas tomem as decisões corretas para seus casos de uso. Porque muitas vezes há muitos equívocos sobre o que são Micro-frontends e como eles devem ser usados. E muitas pessoas estão pensando que talvez, digamos, são maus por, eu não sei, ter muitas bibliotecas em uma visão ou outras coisas.

Luca: A realidade é que você precisa entender profundamente o conceito, entender como implementar isso e então você pode começar a trabalhar nisso. Concordo plenamente que existem desafios técnicos e muitas decisões que você precisa tomar e não pode começar imediatamente com um editor na sua frente escrevendo código e pensando, ok, agora estou criando um micro-frontend arquitetura. Porque você precisa entender o conceito, entender o contexto e criar, também governança em torno disso, porque a complexidade não é apenas escrever o código, é também entender como todas as peças estão se encaixando na parte CICD, na parte SEO e assim por diante.

Luca: Então o Micro-frontend fornece, digamos, um nível de flexibilidade e exige muito esforço para definir o direito de governança. Porque quando você tem a governança certa, tudo seria tranquilo. Muitas vezes e infelizmente eu diria com muita frequência, vi empresas que não gastam tempo suficiente no lado da governança, entendendo o CICD, por exemplo, porque não acham que isso seja importante. Mas, em vez de Micro-frontend, como para microsserviços, ter a automação correta permitirá que você acelere o desenvolvimento. Se você não gastar tempo suficiente no bit de automação, corre o risco de ter mais encargos do que benefícios.

Drew: Acho que é como muitas coisas no mundo do desenvolvimento web onde as pessoas correm o risco de mergulhar com uma solução técnica antes de realmente entenderem o problema. E parece que com o Micro-frontend é muito mais um caso que você precisa ver o problema e depois implementar a solução para saber qual problema você está resolvendo. Acho que a própria natureza do Micro-frontend torna muito fácil iniciar a integração em um aplicativo existente, identificar um pequeno problema e trocá-lo por um Micro-frontend para resolver esse problema. É uma sugestão razoável?

Luca: Sim, eu diria que sim. Neste caso, a única coisa que eu sugiro se começarmos desta forma é olhar mais para o fatiamento vertical sobre o fatiamento horizontal, porque senão você precisa resolver tantos problemas, vamos supor que, por exemplo, você esteja usando Angular e você deseja migrar para uma nova versão do Angular. Se você precisa ter duas versões do Angular vivendo juntas sem usar o I-frame, pode ser complicado ou até mesmo impossível. Então se você começar, você o aspecto não de... se você verificar o desafio, não do ponto de vista técnico, mas do ponto de vista do negócio. Talvez, por exemplo, você possa pegar, não sei, a parte de login que você deseja escrever com uma versão diferente ou a mesma versão, mas mais versão de atualização de uma estrutura e isso pode ser uma boa maneira. E então você rota através do caminho. Essa pode ser uma boa maneira de substituir lentamente, mas com firmeza, um aplicativo específico.

Luca: O que fizemos no nosso caso foi basicamente aplicar o padrão strangler que é um padrão bem conhecido para microsserviços, mas no front-end. Portanto, com base na URL e com base no navegador e no país do usuário. De forma lenta mas constante, basicamente estávamos matando o monólito, que nesse caso era aplicação de página única, liberando nosso novo aplicativo com mais frequência e ver os comportamentos dos usuários, se estava melhorando a experiência, estava causando algum problema em nosso sistema ou não. E isso nos permitiu fornecer valor imediato ao negócio, mas ao mesmo tempo nos permitiu testar nossas premissas e ver se estávamos indo na direção certa ou não.

Drew: Parece uma solução muito atraente para alguns problemas que tenho certeza que muitas pessoas estão enfrentando. Se eu, como desenvolvedor, quisesse começar a investigar mais sobre Micro-frontend, onde seria um bom lugar para começar?

Luca: Sim, então atualmente estou gastando muito do meu tempo livre tentando defender essas arquiteturas, porque acho que há muitos equívocos. Na minha conta Medium. Eu escrevi vários artigos que estão disponíveis lá também. A gravou muitos vídeos em conferências que você pode encontrar no YouTube sem nenhum problema. E a outra coisa que eu sugiro se você estiver procurando por algum exemplo de código em alguns frameworks, o que eu recomendaria para começar é um único SPA, principalmente porque tem uma abordagem de fatiamento vertical, é mais fácil pegá-lo e você pode começar a entender o benefício dessa arquitetura. Depois, há muitos outros que estão disponíveis. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.