Crie serviços de back-end separados a serem consumidos por aplicativos de front-end específico ou interfaces. Esse padrão é útil quando você deseja evitar a personalização de um único back-end para várias interfaces. Esse padrão foi descrito pela primeira vez por Sam Newman.
Contexto e problema
Inicialmente, um aplicativo pode ser direcionado a uma interface do usuário da Web da área de trabalho. Normalmente, um serviço de back-end é desenvolvido paralelamente, o que fornece os recursos necessários para essa interface do usuário. À medida que a base de usuários do aplicativo aumenta, é desenvolvido um aplicativo móvel que deve interagir com o mesmo back-end. O serviço de back-end se torna um back-end para fins gerais, atendendo aos requisitos de ambas as interfaces móvel e de área de trabalho.
Mas os recursos de um dispositivo móvel são muito diferentes de um navegador de área de trabalho quanto ao tamanho da tela, ao desempenho e às limitações de exibição. Como resultado, os requisitos para um back-end aplicativo móvel diferem da interface do usuário da Web da área de trabalho.
Essas diferenças resultam em requisitos concorrentes do back-end. O back-end requer alterações regulares e significativas para atender à interface do usuário da área de trabalho da Web de e ao aplicativo móvel. Muitas vezes, equipes de interface separadas trabalham em cada front-end, fazendo com que o back-end vire um gargalo no processo de desenvolvimento. Requisitos conflitantes de atualização e a necessidade de manter o serviço funcionando para ambos os front-ends podem fazer com que se ponha muito esforço em um único recurso implantável.
Como a atividade de desenvolvimento se concentra no serviço de back-end, uma equipe separada pode ser criada para gerenciar e manter o back-end. Por fim, isso resulta em uma desconexão entre as equipes de desenvolvimento de interface e de back-end, sobrecarregando a equipe de back-end para equilibrar os requisitos concorrentes das diferentes equipes da interface do usuário. Quando uma equipe da interface precisa de alterações no back-end, essas alterações devem ser validadas com outras equipes da interface antes de serem integradas no back-end.
Solução
Crie um back-end por interface do usuário. Ajuste o comportamento e o desempenho de cada back-end para atender da melhor maneira possível às necessidades do ambiente de front-end, sem se preocupar em afetar outras experiências de front-end.
Como cada back-end é específico para uma interface, ele pode ser otimizado para essa interface. Como resultado, ele será menor, menos complexo e provavelmente mais rápido do que um back-end genérico que tenta satisfazer os requisitos de todas as interfaces. Cada equipe da interface tem autonomia para controlar seu próprio back-end e não depende de uma equipe centralizada de desenvolvimento de back-end. Isso dá flexibilidade à equipe da interface quanto à seleção da linguagem, cadência da versão, priorização de carga de trabalho e integração de recursos no back-end.
Para obter mais informações, consulte Padrão: back-ends para front-ends.
Problemas e considerações
- Leve em consideração quantos back-ends serão implantados.
- Se interfaces diferentes (como clientes móveis) vão fazer as mesmas solicitações, veja se é necessário implementar um back-end para cada interface ou se um back-end único será suficiente.
- A duplicação de códigos entre serviços é altamente provável quando esse padrão é implementado.
- Serviços de back-end voltados ao front-end devem conter apenas o comportamento e a lógica específicos do cliente. A lógica de negócios gerais e outros recursos globais devem ser gerenciados em outro local do seu aplicativo.
- Pense em como esse padrão pode se refletir nas responsabilidades de uma equipe de desenvolvimento.
- Leve em consideração o tempo que levará para implementar esse padrão. O esforço para compilar os novos back-ends implicará em dívida técnica enquanto você continua a oferecer suporte ao back-end genérico existente?
Quando usar esse padrão
Use esse padrão quando:
- Um serviço de back-end compartilhado ou de uso geral deve ser mantido com significativa sobrecarga de desenvolvimento.
- Você deseja otimizar o back-end para os requisitos de interfaces de cliente específicas.
- As personalizações são feitas para um back-end de 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.
Esse padrão pode não ser adequado:
- Quando interfaces fazem solicitações iguais ou semelhantes para o back-end.
- Quando apenas uma interface é usada para interagir com o back-end.
Design de carga de trabalho
Um arquiteto deve avaliar como o padrão Backends para 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 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 a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. | Ter serviços separados exclusivos para uma interface de front-end específica contém problemas de funcionamento; portanto, a disponibilidade de um cliente pode não afetar a disponibilidade do acesso de outro cliente. Além disso, ao tratar vários clientes de maneira diferente, você pode priorizar 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. | Devido à separação de serviços introduzida neste padrão, a segurança e a autorização na camada de serviço que permite 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 diferentes capacidades. - 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 em dimensionamento, dados e código. | A separação de back-end permite otimizar de maneiras que talvez não fossem possíveis com uma camada de serviço compartilhada. Ao lidar com clientes individuais de maneira 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 |
Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este padrão.