Backend for Frontend

¿Qué es?

Backend for Frontend (BFF) es un patrón arquitectónico donde cada tipo de cliente — web, móvil, IoT, aplicaciones de escritorio — tiene su propio backend dedicado. En lugar de forzar a todos los clientes a consumir las mismas APIs genéricas, cada BFF actúa como una capa de adaptación que agrega, transforma y optimiza datos específicamente para las necesidades de su cliente.

El patrón surge de la realidad práctica de que diferentes clientes tienen diferentes patrones de acceso a datos, restricciones de red, capacidades de procesamiento y experiencias de usuario. Una aplicación web puede necesitar datos ricos y detallados, mientras que una aplicación móvil requiere respuestas más ligeras y optimizadas para conexiones lentas. Un dispositivo IoT podría necesitar solo un subconjunto mínimo de datos en formato binario.

Cada BFF es propiedad del equipo frontend correspondiente, lo que permite mayor autonomía y velocidad de desarrollo. Esto contrasta con un API Gateway centralizado que intenta servir a todos los clientes con una interfaz única.

Patrones de implementación

BFF por plataforma

El patrón más común es crear un BFF dedicado para cada plataforma cliente:

// BFF Web - Optimizado para aplicaciones web
app.get('/api/dashboard', async (req, res) => {
  const [user, analytics, notifications, settings] = await Promise.all([
    userService.getProfile(req.userId),
    analyticsService.getDashboardData(req.userId),
    notificationService.getRecent(req.userId, 10),
    settingsService.getUserPreferences(req.userId)
  ]);
 
  // Agregación rica para web con múltiples widgets
  res.json({
    user: {
      name: user.fullName,
      avatar: user.profileImage,
      role: user.role
    },
    dashboard: {
      metrics: analytics.summary,
      charts: analytics.chartData,
      notifications: notifications.map(n => ({
        id: n.id,
        message: n.content,
        timestamp: n.createdAt,
        priority: n.priority
      })),
      quickActions: settings.enabledActions
    }
  });
});
 
// BFF Mobile - Optimizado para dispositivos móviles
app.get('/api/dashboard', async (req, res) => {
  const [user, criticalNotifications] = await Promise.all([
    userService.getProfile(req.userId),
    notificationService.getCritical(req.userId, 3)
  ]);
 
  // Respuesta ligera para móvil
  res.json({
    user: user.displayName,
    avatar: user.thumbnailImage,
    alerts: criticalNotifications.length,
    hasUpdates: criticalNotifications.length > 0
  });
});

BFF con GraphQL

GraphQL puede actuar como un BFF natural, permitiendo a cada cliente solicitar exactamente los datos que necesita:

# Schema GraphQL como BFF
type Query {
  dashboard(platform: Platform!): DashboardData
}
 
type DashboardData {
  user: User
  metrics: [Metric]
  notifications: [Notification]
  settings: UserSettings
}
 
enum Platform {
  WEB
  MOBILE
  TABLET
}

// Resolver que adapta según la plataforma
const resolvers = {
  Query: {
    dashboard: async (_, { platform }, { userId }) => {
      const baseData = await getDashboardData(userId);
      
      switch (platform) {
        case 'WEB':
          return {
            ...baseData,
            metrics: baseData.metrics, // Datos completos
            notifications: baseData.notifications.slice(0, 10)
          };
        case 'MOBILE':
          return {
            user: baseData.user,
            metrics: baseData.metrics.filter(m => m.priority === 'HIGH'),
            notifications: baseData.notifications.slice(0, 3)
          };
        default:
          return baseData;
      }
    }
  }
};

Cuándo usar BFF

Escenarios ideales

• Múltiples tipos de cliente con necesidades de datos significativamente diferentes
• Equipos frontend autónomos que necesitan iterar rápidamente sin depender de cambios en APIs centralizadas
• APIs de microservicios granulares que requieren múltiples llamadas para completar una operación de cliente
• Optimizaciones específicas por plataforma como compresión de imágenes, formatos de datos o protocolos de comunicación

Cuándo evitar BFF

El patrón BFF añade complejidad innecesaria en ciertos escenarios:

• Un solo tipo de cliente — un API Gateway genérico es suficiente
• Equipos pequeños donde mantener múltiples BFFs supera la capacidad de desarrollo
• Diferencias mínimas entre clientes — solo formato de respuesta o campos opcionales
• APIs ya optimizadas que proporcionan exactamente lo que cada cliente necesita

Comparación de patrones

Antipatrones comunes

BFF como proxy simple

// ❌ Antipatrón: BFF que solo reenvía llamadas
app.get('/api/users/:id', (req, res) => {
  // Solo proxy, sin valor añadido
  return userService.getUser(req.params.id);
});

// ✅ Patrón correcto: BFF que agrega valor
app.get('/api/users/:id', async (req, res) => {
  const [user, permissions, preferences] = await Promise.all([
    userService.getUser(req.params.id),
    authService.getUserPermissions(req.params.id),
    settingsService.getPreferences(req.params.id)
  ]);
 
  return {
    profile: {
      name: user.fullName,
      email: user.email,
      avatar: user.profileImage
    },
    capabilities: permissions.map(p => p.action),
    settings: preferences.ui
  };
});

Lógica de negocio en BFF

Los BFFs deben limitarse a agregación y transformación de datos, no implementar lógica de negocio compleja que debería residir en los microservicios subyacentes.

Integración con arquitectura

Un BFF puede coexistir con otros patrones arquitectónicos:

• Con API Gateway: El gateway maneja autenticación, rate limiting y routing, mientras el BFF se enfoca en agregación de datos
• Con Event-Driven Architecture: Los BFFs pueden suscribirse a eventos para mantener caches locales o notificar cambios a clientes
• Con Micro-frontends: Cada micro-frontend puede tener su propio BFF, manteniendo la autonomía del equipo

¿Por qué importa?

El patrón BFF resuelve el problema fundamental de APIs genéricas que intentan servir múltiples clientes con necesidades divergentes. En organizaciones con equipos frontend autónomos, permite que cada equipo optimice su backend para patrones de acceso específicos sin impactar otros clientes. Esto reduce la latencia, mejora la experiencia de usuario y acelera el desarrollo al eliminar dependencias entre equipos. Sin embargo, introduce complejidad operacional — cada BFF debe ser desplegado, monitoreado y mantenido independientemente, lo que requiere considerar cuidadosamente el tradeoff entre autonomía del equipo y overhead de infraestructura.

Referencias

• Pattern: Backends for Frontends — Sam Newman. El artículo original que definió el patrón BFF.
• Backends for Frontends pattern — Microsoft, 2023. Guía de implementación en Azure.
• The Back-end for Front-end Pattern (BFF) — Phil Calçado, 2015. Análisis detallado del patrón con casos de uso.
• Building Microservices — Sam Newman, O'Reilly, 2021. Capítulo sobre BFF en contexto de microservicios.
• Thinking in Graphs — GraphQL Foundation. Conceptos fundamentales de GraphQL como BFF.
• Micro Frontends — Martin Fowler, 2019. Integración de BFF con arquitecturas de micro-frontends.