APIs
6
min de leitura
2 de janeiro de 2019

Utilização de GraphQL como implementação do padrão BFF

Rafael Rocha
Head of Solutions and Presales
Tecnólogo formado em Tecnologia da Informação pela UNESP e pós-graduado em MBA em Gestão Empresarial pela UNIMEP.
Mais sobre o autor

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 ?

  1. Trabalha em múltiplos protocolos de comunicação, tais como WebSocket!
  2. Esconde a complexidade para lidar com as APIs empresariais RESTful

E que tal o Padrão BFF, por que usar ?

  1. Criar APIs de experiência para cada canal de comunicação.
  2. 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;)

Obrigado pela leitura!