Backends para o padrão Frontends

Esse padrão descreve como separar serviços de back-end de implementações de frontend para personalizar experiências para diferentes interfaces de cliente. Esse padrão é útil quando você deseja evitar a personalização de um back-end que serve várias interfaces. Este padrão é baseado no padrão Backends for Frontends de Sam Newman.

Contexto e problema

Considere uma aplicação que foi inicialmente concebida com uma interface de utilizador web para ambiente de trabalho e um serviço de back-end 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 de desktop 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 de desktop e o cliente móvel. Duas setas de dupla face apontam do serviço de back-end para o cliente de desktop e o cliente móvel.

Um serviço de back-end frequentemente encontra demandas concorrentes de vários sistemas frontend. Essas demandas resultam em atualizações frequentes e potenciais gargalos de desenvolvimento. Atualizações conflitantes e a necessidade de manter a compatibilidade resultam em 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 frontend e backend. Essa desconexão pode causar atrasos na obtenção de consenso e requisitos de equilíbrio. Por exemplo, as alterações solicitadas por uma equipe de frontend devem ser validadas com outras equipes de frontend antes da integração.

Solução

Introduza uma nova camada que lida apenas com os requisitos específicos da interface. Essa camada, conhecida como serviço de back-end para front-end (BFF), fica entre o cliente frontend e o serviço de back-end. Se o aplicativo suportar 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 frontend. Como cada serviço BFF é menor e menos complexo do que um serviço de back-end compartilhado, ele pode tornar o aplicativo mais fácil de gerenciar.

As equipes de frontend gerenciam de forma independente seu próprio serviço BFF, o que lhes dá controle sobre a seleção de idiomas, cadência de lançamento, priorização de carga de trabalho e integração de recursos. Essa autonomia permite que eles operem de forma eficiente sem depender de uma equipe de desenvolvimento de back-end centralizada.

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

O diagrama mostra três seções. A primeira seção consiste no cliente desktop e no cliente móvel. A segunda seção consiste no serviço BFF do cliente desktop e no serviço BFF do cliente móvel. O cliente de desktop tem uma seta sólida que aponta para o serviço BFF do cliente de desktop. O cliente móvel tem uma seta sólida que aponta para o serviço BFF associado ao cliente móvel. 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 Backends for Frontends pattern de Sam Newman.

Problemas e considerações

• Avalie o seu número ideal de serviços dependendo dos custos associados. Manter e implantar mais serviços significa aumentar a 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.

• Analise os objetivos de nível de serviço ao adicionar um novo serviço. Pode ocorrer maior latência 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 diferentes interfaces 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 o trade-off entre a duplicação de código e uma experiência mais personalizada para cada cliente.

• O serviço BFF deve lidar apenas com a lógica específica do cliente relacionada a uma experiência de usuário específica. Características transversais, como monitoramento e autorização, devem ser abstraídas para manter a eficiência. As características típicas que podem surgir no serviço BFF são tratadas separadamente com os padrões Gatekeeping, Limitação de Taxa e Roteamento.

• 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. A manutenção do 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 frontend, os serviços BFF podem não agregar 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 são normalmente recomendados.

Quando usar este padrão

Utilize este padrão quando:

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

• 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 de usuário específica, mas não para todas as interfaces de usuário.

Este padrão pode não ser adequado quando:

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

• Apenas uma interface interage com o back-end.

Design da carga de trabalho

Avalie como usar o padrão Backends 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 orientação sobre como esse padrão suporta as metas de cada pilar.

Pilar	Como esse padrão suporta os objetivos do pilar
As decisões de projeto de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantem que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha.	Quando você isola serviços para uma interface de frontend específica, você contém avarias. A disponibilidade de um cliente não afeta a disponibilidade do acesso de outro cliente. Quando você trata vários clientes de forma diferente, 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ços introduzida neste 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 recursos diferentes. - SE:04 Segmentação - SE:08 Recursos de proteção
A Eficiência de Desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente por meio de otimizações em escala, dados e 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. Quando você lida com clientes individuais de forma diferente, pode otimizar o desempenho para as restrições e funcionalidades de um cliente específico. - PE:02 Planeamento da capacidade - PE:09 Fluxos críticos

Se este 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 de área de trabalho, interagem com o Gerenciamento de API do Azure (gateway de plano de dados). Este portal funciona como uma camada de abstração e gere preocupações transversais comuns, tais como:

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

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

• Cache de solicitações. Otimiza solicitações repetidas servindo respostas do cache através de funcionalidades integradas da Gestão de API.

• 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 intermediário entre o gateway e os microsserviços subjacentes. Os serviços BFF, específicos do 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. Em contraste, o aplicativo de desktop 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 eficiente em termos de largura de banda e um navegador da Web que fornece uma interface totalmente funcional. As setas se estendem de ambos os dispositivos em direção ao 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 secção, encerrada num retângulo de linhas tracejadas, 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 o Microsoft Entra ID, 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 faz um loop de volta do portal para o dispositivo móvel, o que representa uma resposta em cache quando uma solicitação idêntica é feita novamente, reduzindo assim o processamento desnecessário. O grupo à direita dentro do retângulo tracejado concentra-se em personalizar as respostas de back-end com base no tipo de cliente que faz a solicitação. Ele possui 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 desktop. Duas setas se estendem do gateway para esses clientes de back-end 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 estendem e conectam os clientes de back-end para frontend a vários microsserviços, que lidam com a lógica de negócios real. A imagem mostra um fluxo da esquerda para a direita onde as solicitações do cliente são movidas de clientes móveis e da Web para o gateway. Esse gateway processa cada solicitação enquanto delega a autenticação para cima ao provedor de identidade e o registro para baixo no serviço de monitoramento. A partir daí, ele roteia solicitações para o cliente back-end para front-end apropriado com base no fato de a solicitação ser originada de um cliente móvel ou desktop. Finalmente, cada cliente backend-for-frontend 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 em cache estiver disponível, o gateway intercetará a solicitação e enviará a resposta armazenada diretamente para o cliente móvel, o que evita o processamento redundante.

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

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

2. A solicitação chega ao gateway de Gerenciamento de API, que a interceta e:

   1. Verifica o status da autorização. O Gerenciamento de API implementa a defesa em profundidade, por isso verifica a validade do token de acesso.

   2. Transmite a atividade de solicitação como logs para o Azure Monitor. Os detalhes do pedido são registados para auditoria e monitorização.

3. As políticas são impostas e, em seguida, a Gestão de API roteia a solicitação para o serviço BFF móvel da Azure Function.

4. Em seguida, o serviço BFF móvel da função Azure interage com os microsserviços necessários para buscar uma única página e processar os dados solicitados para fornecer uma experiência leve.

5. A resposta é devolvida ao cliente.

Fluxo B para solicitação em cache da página inicial do cliente de telemó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 aplicadas. Em seguida, o gateway identifica uma resposta em cache que corresponde aos parâmetros da 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 da função Azure.

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

1. O cliente de desktop 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 gateway de Gerenciamento de API, onde as preocupações transversais são tratadas.

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

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

3. Após a aplicação de todas as políticas, a Gestão de APIs roteia a solicitação para o serviço BFF de desktop da função Azure, que lida com o processamento de aplicações intensivas em dados. O serviço BFF do ambiente de trabalho agrega múltiplas solicitações utilizando chamadas de microsserviços subjacentes antes de responder ao cliente com uma resposta composta por várias páginas.

Desenho

• O Microsoft Entra ID serve como o provedor de identidade baseado em nuvem. Ele fornece reivindicações de público personalizadas para clientes móveis e desktop. Estas declarações são então utilizadas para autorização.

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

• O Azure Monitor funciona como a solução de monitoramento centralizado. 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 de forma eficiente a lógica de 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óximos passos

• Backends para o padrão Frontends por Sam Newman
• Autenticação e autorização para APIs no Gerenciamento de API
• Como integrar o Gerenciamento de API com o Application Insights

Recursos relacionados

• Padrão de Agregação de Gateway
• Padrão de Descarregamento de Gateway
• Padrão de Encaminhamento do Gateway
• de arquitetura de referência de aplicativo Web sem servidor