Padrão de back-ends para front-ends

Esse padrão descreve como desacoplar serviços de back-end de implementações de front-end para adaptar experiências para diferentes interfaces do cliente. Esse padrão é útil quando você deseja evitar personalizar um back-end que atenda a várias interfaces. Esse padrão é baseado no padrão Back-ends for Frontends de Sam Newman.

Contexto e problema

Considere um aplicativo inicialmente projetado com uma interface do usuário da Web para desktop e um serviço de backend correspondente. À medida que os requisitos de negócios mudam ao longo do tempo, uma interface móvel é adicionada. Ambas as interfaces interagem com o mesmo serviço de back-end. Mas os recursos de um dispositivo móvel diferem significativamente de um navegador da área de trabalho em termos de tamanho de tela, desempenho e limitações de exibição.

O diagrama tem duas seções: o serviço de back-end e o cliente da área de trabalho e o cliente móvel. Duas setas bidirecionais apontam do serviço de backend tanto para o cliente da área de trabalho quanto para o cliente móvel.

Um serviço de back-end frequentemente encontra demandas concorrentes de vários sistemas de front-end. Essas demandas resultam em atualizações frequentes e possíveis gargalos de desenvolvimento. Atualizações conflitantes e a necessidade de manter a compatibilidade resultam em uma demanda excessiva em um único recurso implantável.

Ter uma equipe separada gerenciando o serviço de back-end pode criar uma desconexão entre as equipes de front-end e back-end. Essa desconexão pode causar atrasos na obtenção de requisitos de consenso e balanceamento. Por exemplo, as alterações solicitadas por uma equipe de front-end devem ser validadas com outras equipes de front-end antes da integração.

Solução

Introduza uma nova camada que trata apenas dos requisitos específicos para a interface. Essa camada, conhecida como serviço de back-end para front-end (BFF), fica entre o cliente front-end e o serviço de back-end. Se o aplicativo der suporte a várias interfaces, como uma interface web e um aplicativo móvel, crie um serviço BFF para cada interface.

Esse padrão personaliza a experiência do cliente para uma interface específica sem afetar outras interfaces. Ele também otimiza o desempenho para atender às necessidades do ambiente de front-end. Como cada serviço BFF é menor e menos complexo do que um serviço de back-end compartilhado, ele pode facilitar o gerenciamento do aplicativo.

As equipes de front-end gerenciam independentemente seu próprio serviço BFF, o que lhes dá controle sobre seleção de idioma, cadência de versão, priorização de carga de trabalho e integração de recursos. Essa autonomia permite que eles operem com eficiência sem depender de uma equipe centralizada de desenvolvimento de back-end.

Muitos serviços BFF tradicionalmente dependiam de APIs REST, mas as implementações do GraphQL estão emergindo como uma alternativa. Com o GraphQL, o mecanismo de consulta elimina a necessidade de uma camada BFF separada, pois permite que os clientes solicitem os dados necessários sem depender de pontos de extremidade predefinidos.

O diagrama mostra três seções. A primeira seção consiste no cliente da área de trabalho e no cliente móvel. A segunda seção consiste no serviço BFF do cliente da área de trabalho e no serviço BFF do cliente móvel. O aplicativo de desktop tem uma seta sólida que aponta para o serviço BFF do aplicativo de desktop. O cliente móvel exibe uma seta sólida que aponta para o serviço BFF. Cada serviço BFF tem uma seta pontilhada que aponta para a seção de serviço de back-end.

Para obter mais informações, consulte o padrão Back-ends for Frontends de Sam Newman.

Problemas e considerações

• Avalie o número ideal de serviços dependendo dos custos associados. Manter e implantar mais serviços significa maior sobrecarga operacional. Cada serviço individual tem seu próprio ciclo de vida, requisitos de implantação e manutenção e necessidades de segurança.

• Examine os objetivos de nível de serviço ao adicionar um novo serviço. A latência aumentada pode ocorrer porque os clientes não estão entrando em contato diretamente com seus serviços e o novo serviço introduz um salto de rede extra.

• Quando interfaces diferentes fizerem as mesmas solicitações, avalie se as solicitações podem ser consolidadas em um único serviço BFF. Compartilhar um único serviço BFF entre várias interfaces pode resultar em requisitos diferentes para cada cliente, o que pode complicar o crescimento e o suporte do serviço BFF.

  A duplicação de código é um resultado provável desse padrão. Avalie a compensação entre a duplicação de código e uma experiência mais personalizada para cada cliente.

• O serviço BFF deve tratar apenas a lógica específica do cliente relacionada a uma experiência específica do usuário. Funcionalidades transversais, como monitoramento e autorização, devem ser abstraídas para manter a eficiência. As funcionalidades típicas que podem surgir no serviço BFF são gerenciadas separadamente através dos padrões Gatekeeping, Rate Limiting e Routing.

• Considere como aprender e implementar esse padrão afeta a equipe de desenvolvimento. O desenvolvimento de novos sistemas de back-end requer tempo e esforço, o que pode resultar em dívida técnica. Manter o serviço de back-end existente aumenta esse desafio.

• Avalie se você precisa desse padrão. Por exemplo, se sua organização usa o GraphQL com resolvedores específicos de front-end, os serviços BFF podem não adicionar valor aos seus aplicativos.

  Outro cenário é um aplicativo que combina um gateway de API com microsserviços. Essa abordagem pode ser suficiente para alguns cenários em que os serviços BFF normalmente são recomendados.

Quando usar esse padrão

Use esse padrão quando:

• Um serviço de back-end compartilhado ou de uso geral requer uma sobrecarga substancial de desenvolvimento para manter.

• Você deseja otimizar o back-end para os requisitos de interfaces de cliente específicas.

• Você faz personalizações em um back-end de uso geral para acomodar várias interfaces.

• Uma linguagem de programação é mais adequada para o back-end de uma interface do usuário específica, mas não todas as interfaces do usuário.

O padrão pode não ser adequado nestes casos:

• As interfaces fazem as mesmas solicitações ou solicitações semelhantes ao back-end.

• Apenas uma interface interage com o back-end.

Design de carga de trabalho

Avalie como usar o padrão Back-ends for Frontends no design de uma carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.

Pilar	Como esse padrão apoia os objetivos do pilar
As decisões de design de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha.	Quando você isola os serviços em uma interface de front-end específica, você contém defeitos. A disponibilidade de um cliente não afeta a disponibilidade do acesso de outro cliente. Ao tratar vários clientes de forma diferente, você pode priorizar os esforços de confiabilidade com base nos padrões de acesso esperados do cliente. - RE:02 Fluxos críticos - RE:07 Autopreservação
As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho.	A separação de serviço introduzida nesse padrão permite que a segurança e a autorização na camada de serviço sejam personalizadas para as necessidades específicas de cada cliente. Essa abordagem pode reduzir a área de superfície da API e limitar o movimento lateral entre back-ends que podem expor diferentes funcionalidades. - SE:04 Segmentação - SE:08 Proteção de recursos
A Eficiência de Desempenho ajuda sua carga de trabalho a atender com eficiência às demandas por meio de otimizações no dimensionamento, nos dados e no código.	A separação de back-end permite otimizar de maneiras que podem não ser possíveis com uma camada de serviço compartilhado. Ao lidar com clientes individuais de forma diferente, você pode otimizar o desempenho para as restrições e funcionalidades de um cliente específico. - PE:02 Planejamento de capacidade - PE:09 Fluxos críticos

Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Exemplo

Este exemplo demonstra um caso de uso para o padrão no qual dois aplicativos cliente distintos, um aplicativo móvel e um aplicativo da área de trabalho, interagem com o Gerenciamento de API do Azure (gateway de plano de dados). Esse gateway serve como uma camada de abstração e gerencia preocupações transversais comuns, como:

• Autorização. Garante que apenas identidades verificadas com os tokens de acesso adequados possam chamar recursos protegidos usando o Gerenciamento de API com a ID do Microsoft Entra.

• Monitorização. Captura e envia detalhes de solicitação e resposta ao Azure Monitor para fins de observabilidade.

• Solicitar cache. Otimiza solicitações repetidas, fornecendo respostas do cache por meio de recursos embutidos no gerenciamento de APIs.

• Roteamento e agregação. Direciona as solicitações de entrada para os serviços BFF apropriados.

Cada cliente tem um serviço BFF dedicado em execução como uma função do Azure que serve como um intermediário entre o gateway e os microsserviços subjacentes. Esses serviços BFF específicos para cada cliente garantem uma experiência personalizada para paginação e outras funcionalidades. O aplicativo móvel prioriza a eficiência da largura de banda e aproveita o cache para melhorar o desempenho. Por outro lado, o aplicativo da área de trabalho recupera várias páginas em uma única solicitação, o que cria uma experiência de usuário mais imersiva.

O diagrama é estruturado em quatro seções que ilustram o fluxo de solicitações, autenticação, monitoramento e processamento específico do cliente. Dois dispositivos cliente iniciam solicitações: um aplicativo móvel otimizado para uma experiência de usuário com eficiência de largura de banda e um navegador da Web que fornece uma interface totalmente funcional. As setas se estendem de ambos os dispositivos para o ponto de entrada central, que é o gateway de Gerenciamento de API, para indicar que todas as solicitações devem passar por essa camada. Na segunda seção, delimitada por um retângulo de linha tracejada, a arquitetura é dividida em dois grupos horizontais. O grupo esquerdo representa o Gerenciamento de API que lida com solicitações de entrada e determina como processá-las. Duas setas se estendem para fora desse gateway de plano de dados. Uma seta aponta para cima para a ID do Microsoft Entra, que gerencia a autorização. Outra seta aponta para baixo para o Azure Monitor, que é responsável pelo registro em log e pela observabilidade. Uma seta retorna do gateway para o cliente móvel, que representa uma resposta armazenada em cache quando uma solicitação idêntica é repetida, o que reduz o processamento desnecessário. O grupo direito dentro do retângulo tracejado concentra-se na personalização de respostas de back-end com base no tipo de cliente que faz a solicitação. Ele apresenta dois clientes de back-end para front-end separados, ambos hospedados usando o Azure Functions para computação sem servidor. Um é dedicado ao cliente móvel e o outro ao cliente da área de trabalho. Duas setas se estendem do gateway para esses clientes de backend para frontend, o que ilustra que cada solicitação de entrada é encaminhada para o serviço apropriado, dependendo do tipo de cliente. Além dessa camada, as setas tracejadas se estendem e conectam os clientes backend-for-frontend a vários microsserviços, que lidam com a lógica real de negócios. A imagem mostra um fluxo da esquerda para a direita em que as solicitações do cliente são movidas de clientes móveis e Web para o gateway. Esse gateway processa cada solicitação ao delegar a autenticação para cima para o provedor de identidade e fazer logon para baixo no serviço de monitoramento. A partir daí, ele roteia as solicitações para o cliente de back-end para front-end apropriado com base na origem da solicitação de um cliente móvel ou da área de trabalho. Por fim, cada cliente de back-end para front-end encaminha a solicitação para microsserviços especializados, que executam a lógica de negócios necessária e retornam a resposta necessária. Se uma resposta armazenada em cache estiver disponível, o gateway intercepta a solicitação e envia a resposta armazenada diretamente ao cliente móvel, o que impede o processamento redundante.

Fluxo A para a solicitação da primeira página do cliente móvel

1. O cliente móvel envia um pedido GET para a página 1, incluindo o token OAuth 2.0 no cabeçalho de autorização.

2. A solicitação atinge o gateway de Gerenciamento de API, que o intercepta e:

   1. Verifica o status de autorização. O Gerenciamento de API implementa a defesa detalhadamente, portanto, verifica a validade do token de acesso.

   2. Transmite a atividade de solicitação como logs para o Azure Monitor. Os detalhes da solicitação são registrados para auditoria e monitoramento.

3. As políticas são impostas e, em seguida, o Gerenciamento de API encaminha a solicitação para o serviço BFF móvel de funções do Azure.

4. O serviço BFF móvel da função Azure interage com os microserviços necessários para buscar uma única página e processar os dados solicitados, proporcionando uma experiência otimizada.

5. A resposta é retornada ao cliente.

Fluxo B para a primeira solicitação armazenada em cache do cliente móvel

1. O cliente móvel envia a mesma GET solicitação de página 1 novamente, incluindo o token OAuth 2.0 no cabeçalho de autorização.

2. O gateway de Gerenciamento de API reconhece que essa solicitação foi feita antes e:

   1. As políticas são impostas. Em seguida, o gateway identifica uma resposta armazenada em cache que corresponde aos parâmetros de solicitação.

   2. Retorna a resposta armazenada em cache imediatamente. Essa resposta rápida elimina a necessidade de encaminhar a solicitação para o serviço BFF móvel de funções do Azure.

Fluxo C para a primeira solicitação do cliente de desktop

1. O cliente da área de trabalho envia uma GET solicitação pela primeira vez, incluindo o token OAuth 2.0 no cabeçalho de autorização.

2. A solicitação chega ao gerenciamento do gateway de API, onde os interesses transversais são tratados.

   1. Autorização: A validação de token é sempre necessária.

   2. Transmita a atividade de solicitação: Os detalhes da solicitação são registrados para observabilidade.

3. Depois que todas as políticas forem impostas, o Gerenciamento de API roteia a solicitação para o serviço BFF da área de trabalho do Azure, que lida com o processamento de aplicativos de dados pesados. O serviço BFF para desktop agrega várias solicitações usando chamadas de microsserviços subjacentes antes de responder ao cliente com uma resposta em várias páginas.

Projetar

• A ID do Microsoft Entra serve como o provedor de identidade baseado em nuvem. Ele fornece declarações de audiência personalizadas para clientes de dispositivos móveis e de desktop. Essas declarações são usadas para autorização.

• O Gerenciamento de API serve como um proxy entre os clientes e seus serviços BFF, o que estabelece um perímetro. O Gerenciamento de API é configurado com políticas para validar os Tokens Web JSON e rejeita solicitações que não têm um token ou contêm declarações inválidas para o serviço BFF de destino. Ele também transmite todos os logs de atividades para o Azure Monitor.

• O Azure Monitor funciona como a solução de monitoramento centralizada. Ele agrega todos os logs de atividades para garantir uma observabilidade abrangente de ponta a ponta.

• O Azure Functions é uma solução sem servidor que expõe com eficiência a lógica do serviço BFF em vários pontos de extremidade, o que simplifica o desenvolvimento. O Azure Functions também minimiza a sobrecarga de infraestrutura e ajuda a reduzir os custos operacionais.

Próximas etapas

• Padrão "Backends for Frontends" por Sam Newman
• Autenticação e autorização em APIs no Gerenciamento de API
• Como integrar o Gerenciamento de API ao Application Insights

Recursos relacionados

• Padrão de agregação de gateway
• Padrão de descarregamento de gateway
• Padrão de roteamento de gateway
• arquitetura de referência de aplicativo Web sem servidor