As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Comparando microfront-ends com arquiteturas alternativas

Como acontece com todas as estratégias de arquitetura, a decisão de adotar microfront-ends deve ser baseada em critérios de avaliação orientados pelos princípios da sua organização. Os microfront-ends têm vantagens e desvantagens. Se sua organização decidir usar microfrontends, você deve ter estratégias implementadas para enfrentar os desafios dos sistemas distribuídos

Ao escolher uma arquitetura de aplicativo, as alternativas mais populares aos microfront-ends são monólitos, aplicativos de n camadas e microsserviços em combinação com um front-end de aplicativo de página única (SPA). Todas essas abordagens são válidas e cada uma delas tem vantagens e desvantagens.

Monólitos

Um aplicativo pequeno que não precisa de mudanças frequentes pode ser entregue rapidamente como um monólito. Mesmo em situações em que se espera um crescimento significativo, um monólito é um primeiro passo natural. Posteriormente, o monólito pode ser retirado ou refatorado em uma estrutura mais flexível. Ao começar com um monólito, sua organização pode entrar no mercado, obter feedback dos clientes e melhorar o produto mais rapidamente.

No entanto, os aplicativos monolíticos tendem a se degradar se não forem mantidos com cuidado ou à medida que a base de código aumenta de tamanho com o tempo. Quando várias equipes contribuem significativamente para a mesma base de código, raramente todas contribuem para sua manutenção e operações. Isso resulta em um desequilíbrio de responsabilidades, o que afeta a velocidade e causa ineficiências. Ao mesmo tempo, o acoplamento inadvertido entre os módulos de um monólito leva a efeitos colaterais indesejados à medida que a base de código evolui. Esses efeitos colaterais podem resultar em avarias e interrupções.

Aplicativos de nível N

Um aplicativo mais complexo que tenha um ritmo de evolução relativamente estático pode ser construído como uma arquitetura de três camadas (apresentação, aplicativo, dados), com uma camada REST ou GraphQL entre o front-end e o back-end. Isso é muito mais flexível, e equipes de diferentes níveis podem se desenvolver de forma independente até certo ponto. A desvantagem de um aplicativo de n camadas é que é muito mais difícil implantar a funcionalidade. O front-end e o back-end são separados por meio de um contrato de API, portanto, as alterações importantes devem ser implantadas em conjunto ou a API deve ser versionada.

Considere o seguinte cenário comum: se o lançamento de um novo recurso exigir uma alteração no esquema de dados, pode levar dias para que os proprietários do produto cheguem a um acordo sobre um conjunto de funcionalidades com uma equipe de front-end. Em seguida, a equipe de front-end solicitará que a equipe de back-end desenvolva e libere a funcionalidade de sua parte. A equipe de back-end trabalhará com os proprietários dos dados para lançar uma atualização do esquema do banco de dados. Em seguida, a equipe de back-end lançará uma nova versão da API, para que a equipe de front-end possa desenvolver e lançar suas alterações. Nesse cenário, a propagação de todas as mudanças na produção pode levar semanas ou até meses, porque cada equipe tem sua própria lista de pendências, prioridades e mecanismos para desenvolver, testar e lançar mudanças.

Microsserviços

Em uma arquitetura de microsserviços, o back-end é decomposto em pequenos serviços, cada um abordando uma preocupação comercial específica dentro de um contexto limitado. Cada microsserviço também é fortemente desacoplado de outros serviços ao expor um contrato de interface claramente definido.

Vale ressaltar que contextos limitados e contratos de interface também devem existir em monólitos bem elaborados e arquiteturas de n camadas. Em uma arquitetura de microsserviços, no entanto, a comunicação acontece pela rede, geralmente pelo protocolo HTTP, e os serviços têm uma infraestrutura de tempo de execução dedicada. Isso dá suporte ao desenvolvimento, entrega e operação independentes de cada serviço de back-end.

Escolhendo a abordagem para suas necessidades

Monólitos e arquiteturas de n camadas agrupam várias preocupações de domínio em um único artefato técnico. Isso facilita o gerenciamento de aspectos como dependências e fluxo interno de dados, mas dificulta a entrega de novas funcionalidades. Para manter uma base de código coerente, uma equipe geralmente investe tempo em refatoração e desacoplamento devido à grande base de código que precisa lidar.

Os aplicativos desenvolvidos por algumas equipes podem não precisar da complexidade adicional que vem com a mudança para microfront-ends. Isso é especialmente verdadeiro se as equipes não estiverem pagando as penalidades de alto acoplamento e longos prazos de entrega para liberar as mudanças.

Em resumo, arquiteturas mais complexas e distribuídas geralmente são a escolha certa para aplicativos complexos e de rápida evolução. Para aplicativos de pequeno a médio porte, uma arquitetura distribuída não é necessariamente superior a uma monolítica, especialmente se o aplicativo não evoluir drasticamente em um curto período de tempo.