Quer saber como projetar  uma API de Back End para todas interfaces?

O nosso desenvolvedor, André Zarlenga, preparou um artigo sobre BFF contando como ele se adequa às necessidades de cada um dos clientes.

Introdução

O padrão de design do BFF (Backend for Frontend), descrito por Phil Calçado, refere-se ao conceito de desenvolvimento de back end de nicho para cada experiência do usuário. Neste cenário podemos agrupar, minimizando os problemas de centralização.

Esse tipo de arquitetura disponibiliza alguns ambientes para diversos segmentos de usuários, cada um com diferentes experiências e necessidades de API. O usuário móvel por exemplo, utiliza um aplicativo, o usuário de desktop usa um cliente da Web.

Funcionalmente, isso é feito separando cada uma das funcionalidades em um aplicativo ou serviço da web, cada um dos quais chama uma API global. Antes que arquiteturas totalmente distribuídas se tornassem realidade, as organizações geralmente criavam um aplicativo em uma ou mais camadas.

Uma camada era um componente altamente acoplado, mas bastante independente de um aplicativo. Foi acoplado no sentido de que, ao contrário dos serviços, deveria ser usado por apenas um aplicativo.

Modelo tradicional

Essa é a configuração mais básica para uma arquitetura baseada em microsserviços.  Nesse padrão, um aplicativo cliente faz solicitações diretamente aos microsserviços.

                                                          Cliente consome micro serviços sem camada adicional

Vamos relacionar alguns possíveis problemas nesta abordagem:

• Desempenho

Mesmo uma única página do seu aplicativo pode precisar de várias chamadas para diferentes microsserviços, o que pode levar a grandes problemas de latência.

• Escalabilidade

          Como o aplicativo cliente faz referência direta aos microsserviços, praticamente qualquer alteração nos microsserviços pode causar a quebra do aplicativo. Isso dificulta a manutenção.

• Segurança

Sem uma camada intermediária, os pontos finais dos microsserviços são expostos. Isso  não necessariamente torna um aplicativo inerentemente inseguro, mas definitivamente torna mais difícil cuidar da segurança.

Vantagens

Esse tipo de abordagem também traz vantagens, como a capacidade de gravar qualquer serviço em uma tecnologia diferente e implantá-los independentemente, além de aumentar o desempenho e muito mais. Mas também vem com alguns desafios, incluindo administração e configurações complexas.

Existem padrões de design para enfrentar esses desafios comuns em microsserviços, fornecendo soluções comprovadas para tornar sua arquitetura mais eficiente em todo o processo de administração. O aprendizado sobre eles é uma ótima maneira de entender todo processo de ponta a ponta.

O API Gateway implementa os conceitos citados acima. Fornecendo uma camada extra, um único ponto de entrada entre um grupo de microsserviços e a camada de front-end. Ele aborda todas as preocupações que acabamos de mencionar, ocultando o ponto final de microsserviços do público, abstraindo referências a microsserviços do cliente e reduzindo a latência agregando  várias chamadas.

Um detalhe interessante sobre a abordagem de Api gateway, é que ele não restringe o protocolo http, ou seja, entre o api gateway é possível se trabalhar com: REST, GRPC, etc.

                                                                              Abordagem com API Gateway

No entanto, o padrão do API Gateway ainda não está protegido contra problemas de escalabilidade. É mais que suficiente quando a arquitetura gira em torno de um cliente. Mas, se houver vários aplicativos clientes, o API Gateway poderá eventualmente ficar inchado, tendo absorvido todos os requisitos variados de diferentes aplicativos clientes. 

Eventualmente, ele pode tornar-se praticamente um aplicativo monolítico, enfrentando muitos dos mesmos problemas que ocorrem com o padrão direto.

O BFF é essencialmente uma variante do padrão API Gateway. Ele também fornece uma camada adicional entre microsserviços e clientes. Porém, em vez de um único ponto de entrada, ele introduz vários gateways para cada cliente. 

Com o BFF, você pode adicionar uma API adaptada às necessidades de cada cliente, removendo muito o inchaço causado por manter tudo em um só lugar. O padrão de resultado pode ser visto na figura abaixo.

                                                                                   Abordagem BFF

Vale ressaltar que esse padrão específico ainda pode ser estendido para aplicativos particularmente complexos. Gateways diferentes também podem ser criados para domínios comerciais específicos. Esse modelo é flexível o suficiente para responder a praticamente qualquer tipo de situação baseada em microsserviços.

Nem todo aplicativo pode exigir isso, mas se você deseja criar um ecossistema de aplicativos ou planeja estendê-lo no futuro, poderá escolher um padrão de comunicação mais complexo para a escalabilidade futura.

Conclusão

À medida que os microsserviços se tornam cada vez mais populares, novos padrões de design surgem para ajudá-los a resolverem vários desafios de desenvolvimento, tornando essas arquiteturas ainda mais eficientes. Vale a pena conhecer o maior número possível deles, mas tudo se resume em escolhê-los para o seu ecossistema de software específico.