Ferramentas e Arquitetura de Software: Rails/React/BFF?

Danilo Barion. Quando iniciamos a modernização do nosso principal software web de contratação, voltado às empresas, nós precisávamos definir a arquitetura base que manteria o código funcionando de forma tão estável quanto ele tinha sido nos últimos 20 anos.

Ao mesmo tempo, estas escolhas deveriam permitir o uso das melhores tecnologias disponíveis, considerando-se frameworks, bibliotecas e linguagens de programação, inclusive para a implementação de um front-end altamente complexo e interativo.

Após diversas pesquisas, fizemos algumas escolhas que nos permitiram trabalhar com nosso principal framework web, já em uso em outras APIs da empresa, Ruby on Rails, e para o front-end foi escolhida a biblioteca React.

Ruby foi a linguagem de programação escolhida já desde o início da migração do código legado, escrito em asp.net, há cerca de 6 anos na época. Também já usávamos uma boa quantidade de ferramentas de forma conjunta, como MongoDB, Redis, RabbitMQ, PostgreSQL, etc, todos eles com um ótimo suporte para Ruby.

Na época, em 2015, o Rails tinha acabado de lançar sua versão 5.1, sugerindo o uso do Webpack como o compilador recomendado para JavaScript (que inclusive se tornaria o padrão no Rails 6), que permitia utilizar bibliotecas front-end com React, Vue, Angular, etc., mesmo que mantendo o tradicional asset pipeline para CSS, imagens e conteúdo estático.

Além disso, com o time de front-end crescendo rápido, a separação de responsabilidades, tanto no fluxo de desenvolvimento em si, quanto nas bases de código e linguagens/frameworks, nunca fez tanto sentido.

Do Básico à Arquitetura

Com tudo isso em mente, nossa decisão final para as ferramentas básicas não foi tão difícil.

Mas quanto à arquitetura, nós não queríamos que o novo app se tornasse um "monstro" após alguns meses da migração das principais features do projeto para a nova estrutura.

Portanto, nós pensamos: como podemos estruturar estas novas ferramentas e frameworks, qual a arquitetura que mais se encaixaria e atenderia melhor nossas necessidades?

Chegamos a pensar em usar GraphQL, mas não queríamos ter que reescrever todas as nossas principais APIs para dar suporte a isso, principalmente não logo no início do projeto, pois a migração do sistema legado em si já traria complexidade suficiente em relação às regras de negócios e requisitos não-funcionais.

Entretanto, o uso de GraphQL ficou numa lista de possíveis candidatos para futuras novas APIs.

Após ouvirmos sobre um padrão arquitetural emergente na época, principalmente no mundo dos microserviços, chamado “Backend For Frontends” (ou BFF de forma abreviada), pensamos ter encontrado o que precisávamos.

Decisão Final: BFF é a solução!

Esta opção apareceu em um dos Radares de Tecnologia, publicados pela empresa, e artigos aprofundados sobre ela podem ser lidos aqui e aqui.

O padrão BFF é uma tentativa de oferecer um suporte do back-end para cada tipo de aplicação cliente (Web, Mobile, etc.) que esteja consumindo os seus serviços/APIs. Seu principal objetivo é desacoplar as APIs ou microserviços dos seus consumidores.

Basicamente, o que nós fizemos foi incluir uma camada extra (o BFF) entre nossas APIs e client front-end (inicialmente só o cliente Web), atendendo seus requerimentos específicos. Por exemplo, digamos que nosso aplicativo mobile seja mais simples que nosso cliente Web, e que no app a lista de itens de uma empresa cliente não precise mostrar todos os detalhes deles ao mesmo tempo ou na mesma página.

Idealmente, estes novos backends BFF devem ser construídos em uma parceria bem direta com cada front-end que irá consumi-lo, para garantir que cada um deles atenda de forma adequada às necessidades de seu consumidor.

Se ambos os clientes (Web e Mobile) solicitarem as informações da mesma rota de API, o Mobile iria receber todos os dado, assim como o cliente Web, mas não utilizaria a maioria deles, consumindo recursos de rede de forma desnecessária, e consequentemente tornando-o mais lento e mais pesado, mesmo que no final irá somente descartar a maioria destas informações.

Portanto, a criação de dois BFFs resolveria este problema, pois ambos leriam da mesma rota de API, um deles retornando tudo e o outro somente um subconjunto das informações que serão usadas pelo cliente Mobile.

Isso também reduz muito o trabalho do front-end de juntar todas as informações de diversas fontes, já que o BFF já fez isso por ele, inclusive podendo ter feito pequenos ajustes nos formatos dos dados retornados.

Além disso, com o uso dos BFFs é possível aplicar lógicas diferenciadas por cliente, como regras de autenticação ou autorização, regras de negócio, comunicando possíveis erros ao front-end, somente com o mínimo necessário de informações, ou links para outras features que poderão ser carregadas sob demanda, conforme o usuário acessar outras páginas.

Considerações Finais

Claro que este foi um exemplo um pouco enviesado, mas quando você precisar fazer requisições para 2, 3 ou mais APIs diferentes, algumas vezes chamando mais de uma rota em cada uma delas, para renderizar uma página com todas as suas informações, fazer isso trazendo somente os dados que são estritamente necessários irão reduzir em muito a carga que o equipamento de seus usuários precisarão lidar, economizando rede ao reduzir o tráfego.

Como as possibilidades, quando se trata de arquitetura de software, sempre são tão numerosas, eu recomendo fortemente que você leia os dois artigos citados acima, para entender de forma ainda mais profunda esse padrão, e julgar se ele se encaixa ou pode ser adaptado para as necessidades da sua empresa, projeto ou time.

Você já usou a arquitetura de BFF em algum de seus projetos? Quais foram os principais desafios que você encontrou? Na sua opinião, quais as melhores e piores experiências de trabalhar com este padrão?