Como sabemos, a experiência na web em dispositivos móveis – com pequenas telas, planos de dados limitados e limites em requisições –difere em muitos aspectos da experiência em navegadores web desktop. Um dispositivo móvel precisa de menos dados, mas esses dados frequentemente são de tipo diferente. Além disso, fornecem interações adicionais, tais como um leitor de códigos de barras e câmera. Isso significa que precisamos adicionar funcionalidades nas APIs de backend para suportar os dispositivos móveis. Sam Newman descreveu em seu blog um padrão para as APIs de backend tratarem essa diferença entre dispositivos com diferentes tipos de experiências para os usuários.
Newman, desenvolvedor na Thoughtworks, descreve uma solução de construir API de backend com propósitos gerais servindo todos os tipos de interface de usuários. Devido as diferentes necessidades, isso na prática significa adicionar funcionalidades e complexidade no backend. Podendo também ser um gargalo atrasando o processo de publicação devido a todas as mudanças necessárias para suportar todos os dispositivos. Quando trabalhamos com um backend de propósitos gerais, algumas vezes uma equipe especial é criada especialmente para o backend, que na experiência de Newman pode aumentar o problema, agora a equipe de frontend tem uma equipe separada para negociar, uma equipe que tem que priorizar as necessidades de todas as outras equipes também.
Outra solução que Newman tem visto em uso é ter uma API backend para cada experiência de usuário. Conceitualmente uma aplicação focada em usuário consiste de dois componentes, um no lado cliente e outro no lado servidor, um Backend para um Frontend (Backend for Frontend - BFF, é um termo cunhado pelo Phil Calçado quando trabalhava na SoundCloud).
Ao trabalhar com o BFF, normalmente ele fica acoplado a uma interface de usuário em específico, sendo ambos mantidos pela mesma equipe. Quando tratamos com o mesmo tipo de interface de usuário, mas com plataformas diferentes, tal como: Android e iOS. Newman descreve duas abordagens, uma com BFF para cada plataforma e outra com BFF para cada tipo de interface.
Newman prefere um modelo rigoroso de BFF para cada plataforma, por exemplo: um para Android e outro para iOS. Uma preocupação com essa abordagem é o risco de terminar com muitas duplicações entre os BFFs com o mesmo tipo de agregação ou códigos similares que ligam aos serviços de downstream, mas ele não está realmente preocupado com essa duplicação já que é um limite do processo. Misturar um serviço de API de proposito geral com um serviço específico de interface de usuário pode não ser muito bom, já que provavelmente ao longo do tempo vai deixar o código inchado.
Usar um BFF por tipo especifico de cliente, tal como: um para ambos Android e iOS, é uma abordagem que ele viu em uso na SoundCloud. Sua preocupação com essa abordagem é que quanto mais tipos de clientes, maior será o risco de inchar o BFF.
Lukasz Plotnicki, também trabalhando para a Thoughtworks, escreveu uma postagem recente em seu blog explicando sobre o trabalho com BFF na SoundCloud durante sua mudança de uma aplicação monolítica em Rails para usar microservices.
No último Radar Tecnológico da Thoughtworks, o BFF é mencionado como uma técnica a ser seguida.