Crie serviços de back-end separados para serem consumidos por aplicações ou interfaces de front-end específicas. Este padrão é útil quando pretende evitar a personalização de um único back-end para várias interfaces. Este padrão foi descrito pela primeira vez por Sam Newman.
Contexto e problema
Uma aplicação pode ser inicialmente direcionada para uma IU Web do ambiente de trabalho. Normalmente, um serviço de back-end é desenvolvido em paralelo, fornecendo as funcionalidades necessárias para essa IU. À medida que a base de utilizadores da aplicação aumenta, uma aplicação móvel é desenvolvida, que tem de interagir com o mesmo back-end. O serviço de back-end torna-se um back-end para fins gerais, que serve os requisitos das interfaces de ambiente de trabalho e de aplicação móvel.
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. Como resultado, os requisitos de um back-end de aplicação móvel diferem dos da IU Web do ambiente de trabalho.
Estas diferenças resultam em requisitos concorrentes para o back-end. O back-end requer alterações regulares e significativas para servir a IU Web do ambiente de trabalho e a aplicação móvel. Muitas vezes, equipas de interface separadas trabalham em cada front-end, fazendo com que o back-end se torne um estrangulamento no processo de desenvolvimento. Os requisitos de atualização em conflito e a necessidade de manter o serviço a funcionar nos dois front-ends podem resultar em bastante esforço dispendido num único recurso implementável.
Como a atividade de desenvolvimento se centra no serviço de back-end, uma equipa separada pode ser criada para gerir e manter o back-end. Em última análise, isto resulta numa interrupção entre as equipas de desenvolvimento de interface e back-end, sobrecarregando a equipa de back-end para equilibrar os requisitos concorrentes das diferentes equipas de IU. Quando uma equipa de interface precisa de alterações ao back-end, essas alterações têm de ser validadas por outras equipas de interface antes de poderem ser integradas no back-end.
Solução
Crie um back-end por interface de utilizador. Ajuste o comportamento e o desempenho de cada backend para melhor atender às necessidades do ambiente de frontend, sem se preocupar em afetar outras experiências de frontend.
Dado que cada back-end é específico para uma interface, pode ser otimizado para essa interface. Como resultado, será mais pequeno, menos complexo e, provavelmente, mais rápido do que um back-end genérico que tenta satisfazer os requisitos de todas as interfaces. Cada equipa de interface tem autonomia para controlar os seus próprios back-ends e não depende de uma equipa de desenvolvimento de back-end centralizada. Isto proporciona flexibilidade à equipa de interface na seleção de linguagem, cadência de lançamento, atribuição de prioridades da carga de trabalho e integração de funcionalidades no back-end.
Para obter mais informações, veja Padrão: Back-ends para Front-ends.
Problemas e considerações
- Considere a quantidade de back-ends a implementar.
- Se interfaces diferentes (por exemplo, clientes móveis) efetuarem os mesmos pedidos, considere se é necessário implementar um back-end para cada interface ou se um único back-end será suficiente.
- A duplicação de código em serviços é muito provável ao implementar este padrão.
- Os serviços de back-end focados em front-end apenas devem conter lógica e comportamento específicos do cliente. A lógica de negócio geral e outras funcionalidades globais deverão ser geridas noutro local da sua aplicação.
- Considere a forma como este padrão poderá refletir-se nas responsabilidades de uma equipa de desenvolvimento.
- Considere quanto tempo demora a implementação deste padrão. O esforço de criar os novo back-ends resultará em dívida técnica, enquanto continua a suportar o back-end genérico existente?
Quando utilizar este padrão
Utilize este padrão quando:
- Um serviço de back-end partilhado ou para fins gerais tem de ser mantido com custos gerais de desenvolvimento importantes.
- Pretende otimizar o back-end para os requisitos de interfaces específicas de cliente.
- As personalizações são efetuadas num back-end para fins gerais, 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 interfaces fazem os mesmos pedidos, ou semelhantes, ao back-end.
- Quando é utilizada apenas uma interface para interagir com o back-end.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão Backends for Frontends pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| 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 a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. | Ter serviços separados que são exclusivos para uma interface de frontend específica contém avarias, de modo que a disponibilidade de um cliente pode não afetar a disponibilidade do acesso de outro cliente. Além disso, quando você trata vários clientes de forma diferente, pode priorizar os esforços de confiabilidade com base nos padrões de acesso do cliente esperados. - 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. | Devido à separação de serviços introduzida nesse padrão, a segurança e a autorização na camada de serviço que suporta um cliente podem ser adaptadas à funcionalidade exigida por esse cliente, reduzindo potencialmente a área de superfície de uma API e o movimento lateral entre diferentes 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 |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.