Utilização de GraphQL como implementação do padrão BFF
Estamos na era dos APIs RESTful, eu poderia dizer que este tipo de estilo arquitetônico API está em um patamar de produtividade. Muitas plataformas suportam o estilo REST, também a comunidade e a maioria dos desenvolvedores estão familiarizados com os conceitos e ferramentas.
Então, por que alguma parte da comunidade está mudando para outro estilo ou padrões arquitetônicos? Na minha opinião, todos os estilos arquitetônicos têm alguns inconvenientes, não há almoço grátis! Acredito que o estilo arquitetônico REST está organizado em torno do modelo empresarial, a fim de proporcionar uma forte reutilização. Parece ser maravilhoso, mas alguém precisa pagar o almoço!?!
Como podemos adivinhar, a camada frontal é ainda mais dinâmica e ágil em termos de requisitos comerciais, a camada traseira onde as APIs vivem são mais burocráticas e orientadas para o processo. Então, quem precisa ser mais adaptável? A camada front-end fora de rota!
Em termos técnicos, o front-end precisa entender as APIs e geralmente fazer muitos pedidos e esconder ou transformar os campos para entregar um bom desempenho (claro, quero dizer uma melhor experiência do usuário). Os desenvolvedores front-end sofrem com este cenário, portanto é normal chegar a outras alternativas. Aqui é onde o GraphQL realmente se encaixa bem!
Backend para Front End (BFF) Padrão
E que tal BFF ? A fim de corrigir o problema relacionado ao padrão BFF (Backend For Front End) já existe e poderia ser usado para corrigir esta situação. Na maioria dos casos, o estilo arquitetônico REST foi usado extensivamente. Entretanto, faz sentido, se as APIs de minha empresa (General-Purpose) são REST, por que não minhas APIs Front End não podem ser ?
Uma coisa importante a ser considerada é que as APIs Front End devem suportar outros protocolos em vez de apenas HTTP. Outros protocolos assíncronos, tais como WebSocket ou protocolos de mensagens são muito utilizados em aplicações web e móveis e o GraphQL pode ser utilizado com esses protocolos.
Mas voltemos à definição do padrão BFF, de acordo com Sam Newman e Phil Calçado [1], o BFF está firmemente acoplado a uma experiência de usuário específica, e normalmente será mantido pela mesma equipe da interface do usuário, facilitando assim a definição e adaptação da API como o UI exige, ao mesmo tempo em que simplifica o processo de alinhamento do lançamento dos componentes do cliente e do servidor.
GraphQL
O poder do GraphQL [2] vem de uma idéia simples - em vez de definir a estrutura das respostas no servidor, a flexibilidade é dada ao cliente. Cada pedido especifica quais campos e relações deseja obter de volta, e o GraphQL construirá uma resposta sob medida para este pedido em particular. O benefício: apenas uma ida e volta é necessária para buscar todos os dados complexos que de outra forma poderiam abranger vários pontos finais REST e, ao mesmo tempo, retornar apenas os dados que são realmente necessários e nada mais.
A solução proposta
Nossa solução proposta aqui é unir o padrão BFF existente usando GraphQL como principal tecnologia API. Vamos ver como deve ser um grande quadro arquitetônico de alto nível:
Como podemos ver na figura acima, as aplicações front-end consomem as APIs Front-End utilizando a tecnologia GraphQL. A fim de implementar a tradução de REST para GraphQL, um Motor GraphQL é usado aqui como componente chave.
Todas as APIs empresariais estão disponíveis em estilo arquitetônico REST e podem ser reutilizadas para outras aplicações do cliente.
Mas o principal componente neste grande quadro é a Plataforma API, que pode ser usada aqui:
- Gerenciar e expor os APIs da empresa (REST)
- Gerenciar e expor as APIs de Front-End (GraphQL)
- Implementar e executar o motor GraphQL
Conclusão
Nossa solução proposta aqui é usar GraphQL como APIs de Front-End, mas por que ?
- Trabalha em múltiplos protocolos de comunicação, tais como WebSocket!
- Esconde a complexidade para lidar com as APIs empresariais RESTful
E que tal o Padrão BFF, por que usar ?
- Criar APIs de experiência para cada canal de comunicação.
- A equipe de desenvolvimento trabalha no front-end e também no back-end. A complexidade para lidar com APIs empresariais pode ser aplicada na camada back-end e também pode ser reutilizada.
Mas os inconvenientes sempre existem! Então, o que você consideraria?
- O GraphQL tem problemas a resolver, tais como não ter um mecanismo de cache incorporado. Nas APIs RESTful, o protocolo HTTP o trata de forma nativa.
- Ao utilizar o BFF, sua base de código pode aumentar exponencialmente, uma vez que você pode criar um comportamento personalizado para cada dispositivo.
Finalmente, se você quiser usar este tipo de arquitetura, recomendamos fortemente o uso de um Plataforma API [3] que pode ajudá-lo a lidar com o estilo arquitetônico GraphQL e REST.
Referências e Leituras Adicionais
[1] Backend para definição do Padrão de Front-End - http://samnewman.io/patterns/architectural/bff/
[2] GraphQL in the Age of REST APIs - https://medium.com/chute-engineering/graphql-in-the-age-of-rest-apis-b10f2bf09bba
[3] PlataformaSensedia API
você quer saber mais? Fale com um de nossos especialistas, basta preencher o formulário abaixo e logo entraremos em contato;)
Inicie sua jornada conosco
Estamos prontos para guiar o seu negócio rumo ao futuro, com a solução certa para você se beneficiar do potencial das APIs e integrações modernas.
Conteúdos relacionados
Confira os conteúdos produzidos pela nossa equipe
Sua história de sucesso começa aqui
Conte com nosso apoio para levar as melhores integrações para o seu negócio, com soluções e equipes profissionais que são referência no mercado.