Backend for Frontend (BFF): padrão para múltiplos clientes

1. Introdução ao padrão BFF

1.1 Problema resolvido: múltiplos clientes consumindo a mesma API monolítica

Imagine uma aplicação moderna que precisa atender a um site desktop, um aplicativo mobile Android/iOS e uma versão web responsiva. Tradicionalmente, todos esses clientes consomem a mesma API backend. O resultado é desastroso: o mobile recebe dados pesados demais (over-fetching), o web precisa fazer múltiplas requisições para montar uma única tela (under-fetching), e qualquer mudança na API impacta todos os clientes simultaneamente.

1.2 Definição e origem do conceito

O padrão Backend for Frontend (BFF) foi formalizado pela equipe do SoundCloud em 2015, em um artigo seminal de Phil Calçado. A ideia central é simples: criar um backend específico para cada tipo de cliente. Em vez de uma API genérica, você tem BFFs dedicados — um para mobile, outro para web, outro para desktop — cada um otimizado para as necessidades daquela interface específica.

1.3 Diferença entre BFF, API Gateway e Backend monolítico

Enquanto o API Gateway atua como um ponto único de entrada com funcionalidades transversais (roteamento, rate limiting, autenticação), o BFF é mais especializado. Ele não apenas roteia, mas transforma dados, agrega informações e adapta respostas para um cliente específico. O backend monolítico tradicional, por sua vez, oferece uma única interface para todos, sem qualquer otimização por cliente.

2. Casos de uso e quando adotar BFF

2.1 Cenários ideais

BFF brilha quando suas interfaces são drasticamente diferentes:
- App mobile: precisa de dados leves, respostas rápidas, agregação em uma única chamada
- Dashboard web: requer dados ricos, gráficos, múltiplas visualizações
- Smart TV: demanda interfaces simplificadas e navegação por controle remoto

2.2 Quando evitar

Projetos pequenos, times enxutos ou APIs já otimizadas por cliente não precisam de BFF. Se você tem apenas um frontend web e um app mobile simples, a complexidade adicional de manter múltiplos BFFs pode não valer a pena.

2.3 Trade-offs

Prós Contras
Performance sob medida para cada cliente Aumento de complexidade operacional
Experiência de usuário superior Duplicação de lógica entre BFFs
Independência de evolução por cliente Custos de infraestrutura
Redução de acoplamento Necessidade de coordenação entre times

3. Arquitetura de um BFF típico

3.1 Camadas

A arquitetura segue este fluxo:

Cliente (Mobile/Web/Desktop) → BFF específico → Serviços de domínio (microserviços ou APIs legadas)

3.2 Responsabilidades do BFF

  • Agregação de dados: combinar respostas de múltiplos serviços internos
  • Transformação de formato: converter dados para o formato ideal do cliente (JSON leve para mobile, JSON completo para web)
  • Autenticação/autorização: validar tokens JWT, aplicar regras de acesso específicas

3.3 Exemplo de fluxo

Quando o app mobile solicita a tela inicial, o BFF mobile faz três chamadas internas em paralelo:

Requisição: GET /mobile/home
BFF mobile realiza:
  - GET /users/profile (serviço de usuários)
  - GET /feed/posts (serviço de feed)
  - GET /notifications/unread (serviço de notificações)
Resposta agregada: { user, feed, notifications }

4. Estratégias de implementação prática

4.1 Tecnologias comuns

  • Node.js com Express ou Fastify: ideal por sua natureza assíncrona e ecossistema rico
  • Next.js API Routes: útil quando o BFF web compartilha código com o frontend
  • GraphQL como BFF: oferece flexibilidade de queries, mas exige cuidado com performance

4.2 Exemplo de código

BFF mobile em Node.js que agrega dados de dois endpoints internos:

const express = require('express');
const axios = require('axios');
const app = express();

app.get('/mobile/home', async (req, res) => {
  try {
    const [userResponse, feedResponse] = await Promise.all([
      axios.get('http://users-service/api/profile', {
        headers: { Authorization: req.headers.authorization }
      }),
      axios.get('http://feed-service/api/posts?limit=10')
    ]);

    const response = {
      user: {
        id: userResponse.data.id,
        name: userResponse.data.name,
        avatar: userResponse.data.avatar_thumb // versão leve para mobile
      },
      feed: feedResponse.data.posts.map(post => ({
        id: post.id,
        text: post.text.substring(0, 200), // truncado para mobile
        image: post.image_thumb,
        timestamp: post.created_at
      })),
      meta: {
        total_posts: feedResponse.data.total
      }
    };

    res.json(response);
  } catch (error) {
    res.status(500).json({ error: 'Failed to load home' });
  }
});

app.listen(3001, () => console.log('Mobile BFF running on port 3001'));

4.3 Versionamento e evolução

Mantenha BFFs específicos por versão de cliente:

/mobile/v1/home    → BFF mobile versão 1
/mobile/v2/home    → BFF mobile versão 2 (nova interface)
/web/v1/dashboard  → BFF web versão 1
/web/v2/dashboard  → BFF web versão 2 (com gráficos adicionais)

5. BFF e performance para múltiplos clientes

5.1 Redução de over-fetching e under-fetching

O BFF web pode incluir dados completos de produtos, enquanto o BFF mobile retorna apenas campos essenciais:

// Resposta BFF web para /web/product/123
{
  "id": 123,
  "name": "Produto Exemplo",
  "description": "Descrição completa com HTML...",
  "price": 99.90,
  "images": ["url1_hd.jpg", "url2_hd.jpg"],
  "reviews": [/* lista completa */],
  "related_products": [/* 10 itens */]
}

// Resposta BFF mobile para /mobile/product/123
{
  "id": 123,
  "name": "Produto Exemplo",
  "price": 99.90,
  "image_thumb": "url1_thumb.jpg"
}

5.2 Cache e otimização

Implemente cache no BFF para respostas agregadas:

const cache = new Map();
const CACHE_TTL = 60000; // 1 minuto

app.get('/mobile/feed', async (req, res) => {
  const cacheKey = `feed_${req.user.id}`;
  if (cache.has(cacheKey) && Date.now() - cache.get(cacheKey).timestamp < CACHE_TTL) {
    return res.json(cache.get(cacheKey).data);
  }
  // ... lógica de agregação
  cache.set(cacheKey, { data: response, timestamp: Date.now() });
  res.json(response);
});

5.3 Estratégias de fallback

Para redes móveis lentas, o BFF mobile pode retornar dados essenciais primeiro:

app.get('/mobile/home', async (req, res) => {
  // Retorna dados críticos imediatamente
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.write(JSON.stringify({ user: userData }));

  // Carrega feed em segundo plano
  const feed = await loadFeed();
  res.write(JSON.stringify({ feed }));
  res.end();
});

6. Segurança e governança no BFF

6.1 Autenticação centralizada

O BFF valida tokens JWT antes de encaminhar requisições:

app.use('/mobile/*', async (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'Token required' });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    res.status(401).json({ error: 'Invalid token' });
  }
});

6.2 Controle de acesso por cliente

Impeça que o mobile acesse endpoints administrativos:

app.get('/mobile/admin/users', (req, res) => {
  res.status(403).json({ error: 'Mobile clients cannot access admin endpoints' });
});

6.3 Proteção contra ataques

Implemente rate limiting específico por BFF:

const rateLimit = require('express-rate-limit');
const mobileLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100, // 100 requisições por 15 minutos para mobile
  message: { error: 'Too many requests' }
});
app.use('/mobile', mobileLimiter);

7. Monitoramento e manutenção de BFFs

7.1 Métricas-chave

  • Latência por cliente: mobile deve ter P99 < 200ms, web pode tolerar 500ms
  • Taxa de erro por BFF: cada BFF deve ter erro < 1%
  • Volume de requisições: ajuda no dimensionamento de recursos

7.2 Logging estruturado

Use trace IDs para correlacionar requisições:

app.use((req, res, next) => {
  req.traceId = uuidv4();
  logger.info({
    traceId: req.traceId,
    client: 'mobile',
    path: req.path,
    method: req.method
  });
  next();
});

7.3 Testes

Testes de integração entre BFF e serviços de domínio:

describe('Mobile BFF - Home endpoint', () => {
  it('should aggregate user and feed data', async () => {
    const response = await request(bffApp)
      .get('/mobile/home')
      .set('Authorization', 'Bearer valid_token');

    expect(response.status).toBe(200);
    expect(response.body).toHaveProperty('user');
    expect(response.body).toHaveProperty('feed');
    expect(response.body.feed.length).toBeLessThanOrEqual(10);
  });
});

8. Alternativas e evolução do padrão

8.1 GraphQL como substituto ou complemento

GraphQL pode substituir o BFF quando você precisa de flexibilidade de queries. No entanto, BFFs específicos ainda são superiores para cenários onde cada cliente tem necessidades radicalmente diferentes e você quer controle granular sobre performance.

8.2 BFF serverless

AWS Lambda, Cloudflare Workers ou Vercel Edge Functions permitem escalar BFFs sob demanda, pagando apenas pelo uso. Ideal para startups ou aplicações com picos de tráfego imprevisíveis.

8.3 Tendências futuras

  • BFFs para voz: APIs otimizadas para assistentes virtuais (Alexa, Google Assistant)
  • BFFs para IoT: respostas ultra-leves para dispositivos com recursos limitados
  • BFFs contextuais: que se adaptam dinamicamente com base no dispositivo, rede e preferências do usuário

Referências