Editar

Compartilhar via


Padrão de back-ends para front-ends

Azure

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.

Diagrama de contexto e problema de back-ends para front-ends padrão

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.

Diagrama do padrão de back-ends para front-ends

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.

Próximas etapas