Microsserviços Frontend: Descoberta de Serviços e Estratégias de Comunicação

A arquitetura de microsserviços revolucionou o desenvolvimento backend, permitindo que as equipes construíssem serviços escaláveis, resilientes e implantáveis independentemente. Agora, esse padrão arquitetural está sendo cada vez mais adotado no frontend, dando origem aos microsserviços frontend, também conhecidos como micro frontends. Este artigo aborda os aspectos cruciais da descoberta de serviços e da comunicação dentro de uma arquitetura de microsserviços frontend.

O que são Microsserviços Frontend?

Microsserviços frontend (ou micro frontends) são uma abordagem arquitetural onde uma aplicação frontend é decomposta em unidades menores, implantáveis independentemente e que podem ser mantidas. Cada micro frontend é tipicamente de propriedade de uma equipe separada, permitindo maior autonomia, ciclos de desenvolvimento mais rápidos e escalonamento mais fácil. Ao contrário dos frontends monolíticos, onde todos os recursos estão fortemente acoplados, os micro frontends promovem a modularidade e o baixo acoplamento.

Benefícios dos Microsserviços Frontend:

• Implantação Independente: As equipes podem implantar seus micro frontends sem afetar outras partes da aplicação, reduzindo os riscos de implantação e permitindo iterações mais rápidas.
• Diversidade Tecnológica: Cada equipe pode escolher a melhor pilha de tecnologia para seu micro frontend específico, permitindo experimentação e inovação.
• Escalabilidade Aprimorada: Os micro frontends podem ser escalados independentemente com base em suas necessidades específicas, otimizando o uso de recursos.
• Maior Autonomia da Equipe: As equipes têm total propriedade de seus micro frontends, levando ao aumento da autonomia e à tomada de decisões mais rápida.
• Manutenção Mais Fácil: Bases de código menores são mais fáceis de manter e entender, reduzindo o risco de introduzir bugs.

Desafios dos Microsserviços Frontend:

• Maior Complexidade: Gerenciar vários micro frontends pode ser mais complexo do que gerenciar um único frontend monolítico.
• Descoberta e Comunicação de Serviços: A implementação de mecanismos eficazes de descoberta e comunicação de serviços é crucial para o sucesso de uma arquitetura de micro frontend.
• Componentes Compartilhados: Gerenciar componentes e dependências compartilhadas entre micro frontends pode ser um desafio.
• Otimização de Desempenho: Otimizar o desempenho em vários micro frontends requer uma consideração cuidadosa das estratégias de carregamento e dos mecanismos de transferência de dados.
• Testes de Integração: Os testes de integração podem ser mais complexos em uma arquitetura de micro frontend, pois exigem testar a interação entre várias unidades independentes.

Descoberta de Serviços em Microsserviços Frontend

A descoberta de serviços é o processo de localizar e conectar-se automaticamente a serviços em um sistema distribuído. Em uma arquitetura de microsserviços frontend, a descoberta de serviços é essencial para permitir que os micro frontends se comuniquem entre si e com os serviços de backend. Existem várias abordagens para a descoberta de serviços em microsserviços frontend, cada uma com suas próprias vantagens e desvantagens.

Abordagens para Descoberta de Serviços:

1. Configuração Estática:

Nesta abordagem, a localização de cada micro frontend é codificada em um arquivo de configuração ou variável de ambiente. Esta é a abordagem mais simples, mas também a menos flexível. Se a localização de um micro frontend mudar, você precisa atualizar o arquivo de configuração e reimplantar a aplicação.

Exemplo:

            const microFrontendConfig = {
  "productCatalog": "https://product-catalog.example.com",
  "shoppingCart": "https://shopping-cart.example.com",
  "userProfile": "https://user-profile.example.com"
};

            

              
                Copy
              
            
          

Prós:

• Simples de implementar.

Contras:

• Não escalável.
• Requer reimplementação para alterações de configuração.
• Não é resiliente a falhas.

2. Descoberta de Serviços Baseada em DNS:

Esta abordagem usa DNS para resolver a localização de micro frontends. Cada micro frontend recebe um registro DNS, e os clientes podem usar consultas DNS para descobrir sua localização. Essa abordagem é mais flexível do que a configuração estática, pois você pode atualizar os registros DNS sem reimplantar a aplicação.

Exemplo:

Supondo que você tenha registros DNS configurados assim:

• product-catalog.microfrontends.example.com IN A 192.0.2.10
• shopping-cart.microfrontends.example.com IN A 192.0.2.11

Seu código frontend pode ser assim:

            const microFrontendUrls = {
  "productCatalog": `http://${new URL("product-catalog.microfrontends.example.com").hostname}`,
  "shoppingCart": `http://${new URL("shopping-cart.microfrontends.example.com").hostname}`
};

            

              
                Copy
              
            
          

Prós:

• Mais flexível do que a configuração estática.
• Pode ser integrado com a infraestrutura DNS existente.

Contras:

• Requer gerenciamento de registros DNS.
• Pode demorar para propagar as alterações.
• Depende da disponibilidade da infraestrutura DNS.

3. Registro de Serviço:

Esta abordagem usa um registro de serviço dedicado para armazenar a localização de micro frontends. Os micro frontends se registram no registro de serviço quando iniciam, e os clientes podem consultar o registro de serviço para descobrir sua localização. Esta é a abordagem mais dinâmica e resiliente, pois o registro de serviço pode detectar e remover automaticamente micro frontends não saudáveis.

Registros de serviço populares incluem:

• Consul
• Eureka
• etcd
• ZooKeeper

Exemplo (usando o Consul):

Primeiro, um micro frontend se registra no Consul na inicialização. Isso normalmente envolve fornecer o nome, endereço IP, porta e quaisquer outros metadados relevantes do micro frontend.

            // Exemplo usando Node.js e a biblioteca 'node-consul'
const consul = require('consul')({
  host: 'consul.example.com', // Endereço do servidor Consul
  port: 8500
});

const serviceRegistration = {
  name: 'product-catalog',
  id: 'product-catalog-1',
  address: '192.168.1.10',
  port: 3000,
  check: {
    http: 'http://192.168.1.10:3000/health',
    interval: '10s',
    timeout: '5s'
  }
};

consul.agent.service.register(serviceRegistration, function(err) {
  if (err) throw err;
  console.log('Registrado no Consul');
});

            

              
                Copy
              
            
          

Em seguida, outros micro frontends ou a aplicação principal podem consultar o Consul para descobrir a localização do serviço de catálogo de produtos.

            consul.agent.service.list(function(err, result) {
  if (err) throw err;
  const productCatalogService = Object.values(result).find(service => service.Service === 'product-catalog');

  if (productCatalogService) {
    const productCatalogUrl = `http://${productCatalogService.Address}:${productCatalogService.Port}`;
    console.log('URL do Catálogo de Produtos:', productCatalogUrl);
  } else {
    console.log('Serviço de Catálogo de Produtos não encontrado');
  }
});

            

              
                Copy
              
            
          

Prós:

• Altamente dinâmico e resiliente.
• Suporta verificações de integridade e failover automático.
• Fornece um ponto central de controle para o gerenciamento de serviços.

Contras:

• Requer a implantação e o gerenciamento de um registro de serviço.
• Adiciona complexidade à arquitetura.

4. API Gateway:

Um API gateway atua como um único ponto de entrada para todas as solicitações aos serviços de backend. Ele pode lidar com a descoberta de serviços, roteamento, autenticação e autorização. No contexto de microsserviços frontend, o API gateway pode ser usado para rotear solicitações para o micro frontend apropriado com base no caminho da URL ou outros critérios. O API Gateway abstrai a complexidade dos serviços individuais do cliente. Empresas como Netflix e Amazon usam extensivamente API Gateways.

Exemplo:

Vamos imaginar que você está usando um proxy reverso como Nginx como um API Gateway. Você pode configurar o Nginx para rotear solicitações para diferentes micro frontends com base no caminho da URL.

            # configuração do nginx

http {
  upstream product_catalog {
    server product-catalog.example.com:8080;
  }

  upstream shopping_cart {
    server shopping-cart.example.com:8081;
  }

  server {
    listen 80;

    location /product-catalog/ {
      proxy_pass http://product_catalog/;
    }

    location /shopping-cart/ {
      proxy_pass http://shopping_cart/;
    }
  }
}

            

              
                Copy
              
            
          

Nesta configuração, as solicitações para `/product-catalog/*` são roteadas para o upstream `product_catalog`, e as solicitações para `/shopping-cart/*` são roteadas para o upstream `shopping_cart`. Os blocos upstream definem os servidores de backend que tratam as solicitações.

Prós:

• Ponto de entrada centralizado para todas as solicitações.
• Lida com roteamento, autenticação e autorização.
• Simplifica a descoberta de serviços para clientes.

Contras:

• Pode se tornar um gargalo se não for dimensionado corretamente.
• Adiciona complexidade à arquitetura.
• Requer configuração e gerenciamento cuidadosos.

5. Backend for Frontend (BFF):

O padrão Backend for Frontend (BFF) envolve a criação de um serviço backend separado para cada frontend. Cada BFF é responsável por agregar dados de vários serviços de backend e adaptar a resposta às necessidades específicas do frontend. Em uma arquitetura de micro frontend, cada micro frontend pode ter seu próprio BFF, o que simplifica a busca de dados e reduz a complexidade do código frontend. Essa abordagem é particularmente útil ao lidar com diferentes tipos de clientes (por exemplo, web, mobile) que exigem diferentes formatos de dados ou agregações.

Exemplo:

Imagine que um aplicativo web e um aplicativo móvel precisam exibir detalhes do produto, mas exigem dados e formatação ligeiramente diferentes. Em vez de ter o frontend chamando diretamente vários serviços de backend e lidando com a transformação de dados por si só, você cria um BFF para cada frontend.

O BFF da web pode agregar dados do `ProductCatalogService`, `ReviewService` e `RecommendationService` e retornar uma resposta otimizada para exibição em uma tela grande. O BFF móvel, por outro lado, pode buscar apenas os dados mais essenciais do `ProductCatalogService` e `ReviewService` para minimizar o uso de dados e otimizar o desempenho em dispositivos móveis.

Prós:

• Otimizado para necessidades específicas do frontend.
• Reduz a complexidade no frontend.
• Permite a evolução independente de frontends e backends.

Contras:

• Requer o desenvolvimento e a manutenção de vários serviços de backend.
• Pode levar à duplicação de código se não for gerenciado corretamente.
• Aumenta a sobrecarga operacional.

Estratégias de Comunicação em Microsserviços Frontend

Depois que os micro frontends foram descobertos, eles precisam se comunicar entre si para fornecer uma experiência de usuário perfeita. Existem vários padrões de comunicação que podem ser usados ​​em uma arquitetura de microsserviços frontend.

Padrões de Comunicação:

1. Comunicação Direta:

Nesse padrão, os micro frontends se comunicam diretamente entre si usando solicitações HTTP ou outros protocolos. Este é o padrão de comunicação mais simples, mas pode levar a um acoplamento rígido e maior complexidade. Também pode levar a problemas de desempenho se os micro frontends estiverem localizados em diferentes redes ou regiões.

Exemplo:

Um micro frontend (por exemplo, um micro frontend de listagem de produtos) precisa exibir a contagem do carrinho de compras do usuário atual, que é gerenciada por outro micro frontend (o micro frontend do carrinho de compras). O micro frontend de listagem de produtos pode fazer uma solicitação HTTP diretamente ao micro frontend do carrinho de compras para recuperar a contagem do carrinho.

            // No micro frontend de listagem de produtos:

async function getCartCount() {
  const response = await fetch('https://shopping-cart.example.com/cart/count');
  const data = await response.json();
  return data.count;
}

// ... exibir a contagem do carrinho na listagem de produtos

            

              
                Copy
              
            
          

Prós:

• Simples de implementar.

Contras:

• Acoplamento rígido entre micro frontends.
• Maior complexidade.
• Potenciais problemas de desempenho.
• Difícil de gerenciar dependências.

2. Eventos (Publicar/Inscrever):

Nesse padrão, os micro frontends se comunicam entre si publicando e se inscrevendo em eventos. Quando um micro frontend publica um evento, todos os outros micro frontends que estão inscritos nesse evento recebem uma notificação. Esse padrão promove o baixo acoplamento e permite que os micro frontends reajam a alterações em outras partes da aplicação sem conhecer os detalhes dessas alterações.

Exemplo:

Quando um usuário adiciona um item ao carrinho de compras (gerenciado pelo micro frontend do carrinho de compras), ele publica um evento chamado "cartItemAdded". O micro frontend de listagem de produtos, que está inscrito nesse evento, atualiza a contagem do carrinho exibida sem chamar diretamente o micro frontend do carrinho de compras.

            // Micro Frontend do Carrinho de Compras (Publicador):

function addItemToCart(item) {
  // ... adicionar item ao carrinho
  publishEvent('cartItemAdded', { itemId: item.id });
}

function publishEvent(eventName, data) {
  // ... publicar o evento usando um message broker ou um barramento de eventos personalizado
}

// Micro Frontend de Listagem de Produtos (Assinante):

subscribeToEvent('cartItemAdded', (data) => {
  // ... atualizar a contagem do carrinho exibida com base nos dados do evento
});

function subscribeToEvent(eventName, callback) {
  // ... se inscrever no evento usando um message broker ou um barramento de eventos personalizado
}

            

              
                Copy
              
            
          

Prós:

• Baixo acoplamento entre micro frontends.
• Maior flexibilidade.
• Escalabilidade aprimorada.

Contras:

• Requer a implementação de um message broker ou um barramento de eventos.
• Pode ser difícil de depurar.
• Consistência eventual pode ser um desafio.

3. Estado Compartilhado:

Nesse padrão, os micro frontends compartilham um estado comum que é armazenado em um local central, como um cookie do navegador, armazenamento local ou um banco de dados compartilhado. Os micro frontends podem acessar e modificar o estado compartilhado, permitindo que se comuniquem indiretamente. Esse padrão é útil para compartilhar pequenas quantidades de dados, mas pode levar a problemas de desempenho e inconsistências de dados se não for gerenciado corretamente. Considere usar uma biblioteca de gerenciamento de estado como Redux ou Vuex para gerenciar o estado compartilhado.

Exemplo:

Os micro frontends podem compartilhar o token de autenticação do usuário armazenado em um cookie. Cada micro frontend pode acessar o cookie para verificar a identidade do usuário sem precisar se comunicar diretamente com um serviço de autenticação.

            // Definindo o token de autenticação (por exemplo, no micro frontend de autenticação)

document.cookie = "authToken=seu_token_de_autenticacao; path=/";

// Acessando o token de autenticação (por exemplo, em outros micro frontends)

function getAuthToken() {
  const cookies = document.cookie.split(';');
  for (let i = 0; i < cookies.length; i++) {
    const cookie = cookies[i].trim();
    if (cookie.startsWith('authToken=')) {
      return cookie.substring('authToken='.length);
    }
  }
  return null;
}

const authToken = getAuthToken();
if (authToken) {
  // ... use o token de autenticação para autenticar o usuário
}

            

              
                Copy
              
            
          

Prós:

• Simples de implementar para pequenas quantidades de dados.

Contras:

• Pode levar a problemas de desempenho.
• Inconsistências de dados podem ocorrer.
• Difícil de gerenciar as alterações de estado.
• Riscos de segurança se não for tratado com cuidado (por exemplo, armazenar dados confidenciais em cookies).

4. Eventos de Janela (Eventos Personalizados):

Os micro frontends podem se comunicar usando eventos personalizados despachados no objeto `window`. Isso permite que os micro frontends interajam mesmo que sejam carregados em diferentes iframes ou componentes da web. É uma abordagem nativa do navegador, mas requer o gerenciamento cuidadoso de nomes de eventos e formatos de dados para evitar conflitos e manter a consistência.

Exemplo:

            // Micro Frontend A (Publicador)

const event = new CustomEvent('evento-personalizado', { detail: { message: 'Olá do Micro Frontend A' } });
window.dispatchEvent(event);

// Micro Frontend B (Assinante)

window.addEventListener('evento-personalizado', (event) => {
  console.log('Evento recebido:', event.detail.message);
});

            

              
                Copy
              
            
          

Prós:

• Suporte nativo do navegador.
• Relativamente simples de implementar para comunicação básica.

Contras:

• Namespace global pode levar a conflitos.
• Difícil de gerenciar estruturas de eventos complexas.
• Escalabilidade limitada para grandes aplicações.
• Requer coordenação cuidadosa entre as equipes para evitar colisões de nomes.

5. Federação de Módulos (Webpack 5):

A federação de módulos permite que uma aplicação JavaScript carregue dinamicamente o código de outra aplicação em tempo de execução. Ele permite o compartilhamento de código e dependências entre diferentes micro frontends sem a necessidade de publicar e consumir pacotes npm. Essa é uma abordagem poderosa para a construção de frontends compostos e extensíveis, mas requer planejamento e configuração cuidadosos.

Exemplo:

Micro Frontend A (Host) carrega um componente do Micro Frontend B (Remote).

            // Micro Frontend A (webpack.config.js)

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... outras configurações do webpack
  plugins: [
    new ModuleFederationPlugin({
      name: 'MicroFrontendA',
      remotes: {
        'MicroFrontendB': 'MicroFrontendB@http://localhost:3001/remoteEntry.js',
      },
      shared: ['react', 'react-dom'], // Compartilhe dependências para evitar duplicatas
    }),
  ],
};

// Micro Frontend A (Componente)

import React from 'react';
import RemoteComponent from 'MicroFrontendB/Component';

const App = () => {
  return (
    

      
Micro Frontend A
      
    
  );
};

export default App;

// Micro Frontend B (webpack.config.js)

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... outras configurações do webpack
  plugins: [
    new ModuleFederationPlugin({
      name: 'MicroFrontendB',
      exposes: {
        './Component': './src/Component',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
};

// Micro Frontend B (src/Component.js)

import React from 'react';

const Component = () => {
  return 
Olá do Micro Frontend B!
;
};

export default Component;

            

              
                Copy
              
            
          

Prós:

• Compartilhamento e reutilização de código sem pacotes npm.
• Carregamento dinâmico de componentes em tempo de execução.
• Tempos de compilação e eficiência de implantação aprimorados.

Contras:

• Requer Webpack 5 ou posterior.
• Pode ser complexo de configurar.
• Problemas de compatibilidade de versão com dependências compartilhadas podem surgir.

6. Componentes Web:

Componentes Web são um conjunto de padrões da web que permitem criar elementos HTML personalizados reutilizáveis ​​com estilo e comportamento encapsulados. Eles fornecem uma maneira agnóstica de plataforma para construir micro frontends que podem ser integrados em qualquer aplicação web, independentemente da estrutura subjacente. Embora ofereçam excelente encapsulamento, eles podem exigir ferramentas ou estruturas adicionais para lidar com cenários complexos de gerenciamento de estado ou vinculação de dados.

Exemplo:

            // Micro Frontend A (Componente Web)

class MyCustomElement extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' }); // Shadow DOM encapsulado
    this.shadowRoot.innerHTML = `
      
      
Olá do Componente Web!
    `;
  }
}

customElements.define('my-custom-element', MyCustomElement);

// Usando o Componente Web em qualquer página HTML



            

              
                Copy
              
            
          

Prós:

• Agnóstico da estrutura e reutilizável em diferentes aplicações.
• Estilo e comportamento encapsulados.
• Tecnologia web padronizada.

Contras:

• Pode ser verboso de escrever sem uma biblioteca auxiliar.
• Pode exigir polyfills para navegadores mais antigos.
• O gerenciamento de estado e a vinculação de dados podem ser mais complexos em comparação com soluções baseadas em estruturas.

Escolhendo a Estratégia Certa

• O tamanho e a complexidade da sua aplicação. Para aplicações menores, uma abordagem simples como configuração estática ou comunicação direta pode ser suficiente. Para aplicações maiores e mais complexas, uma abordagem mais robusta como um registro de serviço ou arquitetura orientada a eventos é recomendada.
• O nível de autonomia exigido pelas suas equipas. Se as equipas precisarem ser altamente autónomas, é preferível um padrão de comunicação fracamente acoplado, como eventos. Se as equipas conseguirem coordenar-se mais de perto, um padrão mais fortemente acoplado, como comunicação direta, pode ser aceitável.
• Os requisitos de desempenho da sua aplicação. Alguns padrões de comunicação, como a comunicação direta, podem ter melhor desempenho do que outros, como eventos. No entanto, os benefícios de desempenho da comunicação direta podem ser compensados ​​pela maior complexidade e acoplamento forte.
• Sua infraestrutura existente. Se você já possui um registro de serviço ou message broker, faz sentido alavancar essa infraestrutura para seus microsserviços frontend.

Melhores Práticas

• Mantenha simples. Comece com a abordagem mais simples que atenda às suas necessidades e aumente gradualmente a complexidade conforme necessário.
• Favoreça o baixo acoplamento. O baixo acoplamento torna sua aplicação mais flexível, resiliente e fácil de manter.
• Use um padrão de comunicação consistente. Usar um padrão de comunicação consistente em seus micro frontends torna sua aplicação mais fácil de entender e depurar.
• Monitore seus serviços. Monitore a integridade e o desempenho de seus micro frontends para garantir que eles estejam funcionando corretamente.
• Implemente tratamento de erros robusto. Lide com erros com elegância e forneça mensagens de erro informativas aos utilizadores.
• Documente sua arquitetura. Documente os padrões de descoberta de serviços e comunicação usados ​​em sua aplicação para ajudar outros desenvolvedores a entendê-la e mantê-la.

Conclusão