Backend for Frontend (BFF) pattern: mobile + web için ayrı API

Bir backend servis var, hem web frontend hem de mobile app bu backend’i consume ediyor. Her ikisinin ihtiyaçları farklı. Web daha fazla data istiyor, mobile data efficiency önemli. Compromise yapılıyor, ikisi de perfect değil.

BFF (Backend for Frontend) pattern bu sorunu çözüyor. Her client için özel backend layer. Bu yazıda pratik kullanım’ını anlatacağım.

Problem: one API for all clients

Typical mimari:

[Mobile App]  →  [API]  ←  [Web Frontend]

API hem mobile hem web için aynı. Endpoint response’u generic.

Mobile ihtiyaçları:
– Minimal payload (data volume matters)
– Specific fields (avatar thumbnail, not full size)
– Combined endpoints (less round trips)
– Offline-first considerations

Web ihtiyaçları:
– Rich data (dashboard, detail views)
– SEO considerations (SSR data)
– Complete information
– Multiple endpoints OK

One-size-fits-all API compromise. Çoğu zaman mobile over-fetching, bandwidth wasted. Veya web under-fetching, multiple round trips.

BFF pattern

Her client için ayrı backend katmanı:

[Mobile App]  →  [Mobile BFF]  ↘
                                  [Core Services]
[Web Frontend]  →  [Web BFF]  ↗

Mobile BFF mobile ihtiyaçlarına optimize. Web BFF web’e. İkisi de core services’ı consume ediyor.

Avantajlar:
– Her client için optimal API
– Client teams backend BFF’i kendileri yönetebilir
– Breaking changes sadece ilgili BFF
– Platform-specific optimization

Dezavantajlar:
– Ek infrastructure (2 BFF deploy, monitor, scale)
– Code duplication (aynı business logic iki yerde)
– Operational complexity

When BFF makes sense

Value ekliyor:

1. Multiple clients significantly different needs. Mobile + web + TV + kiosk + smart watch.
2. Strong platform teams. Mobile team ownership. Web team ayrı.
3. Independent deployment cycles. Mobile weekly, web daily.
4. Performance critical per client. Mobile data sensitivity vs web richness.

Value eklemiyor:

1. Single client (sadece web veya sadece mobile).
2. Similar client needs.
3. Small team (BFF maintenance overhead).
4. Stable, slow-changing API.

Real example: e-commerce

Bir e-commerce project’te BFF pattern uyguladım.

Core services:
– ProductService
– OrderService
– UserService
– PaymentService

Mobile BFF endpoint: /mobile/products/:id

{
  "id": 123,
  "name": "iPhone 15",
  "price": 45000,
  "image": "https://cdn.../thumb-400.webp",
  "rating": 4.5,
  "stockStatus": "available"
}

8 field. 200 bytes payload.

Web BFF endpoint: /web/products/:id

{
  "id": 123,
  "name": "iPhone 15",
  "description": "Lorem ipsum...",
  "price": 45000,
  "oldPrice": 50000,
  "discount": 10,
  "images": [
    {"url": "...full-1920.webp", "alt": "..."},
    // 10+ images
  ],
  "specifications": { /* 50 fields */ },
  "relatedProducts": [ /* 10 items */ ],
  "reviews": [ /* 20 reviews */ ],
  "breadcrumbs": [ /* SEO */ ]
}

30+ field. 5KB+ payload.

İki BFF de ProductService, ReviewService, RecommendationService’i consume ediyor. Ama aggregation farklı.

BFF architecture

BFF’in çalışma prensibi:

1. Client request → BFF
2. BFF downstream services’e parallel call atıyor
3. Response’ları aggregate ediyor, client-optimized format’a çeviriyor
4. Single response client’a

Pseudocode:

// Mobile BFF
async function getProductDetails(productId) {
  const [product, stock, rating] = await Promise.all([
    productService.get(productId),
    inventoryService.getStock(productId),
    reviewService.getAverageRating(productId)
  ]);
  
  return {
    id: product.id,
    name: product.name,
    price: product.price,
    image: product.thumbnail,  // small version only
    rating: rating.average,
    stockStatus: stock > 0 ? 'available' : 'out_of_stock'
  };
}

3 downstream call parallel. Single optimized response.

Tech stack choices

BFF için hangi tech?

Node.js/Express: Most common. JavaScript shared with frontend. Fast development.

GraphQL layer (Apollo): BFF-like functionality. Client query’nin istediği field’ları dön. Özellikle web için güçlü.

Go/Rust: Performance-critical BFF’ler. Latency çok önemliyse.

Kotlin/Spring: Mobile BFF için Android team’in rahat etmesi.

Çoğu project için Node.js pragmatic. Team skillset’i önemli.

BFF deployment

Option 1: Alongside clients. Mobile team BFF repo’su, web team BFF repo’su. Platform team’i ownership.

Option 2: Central infrastructure team. BFF’ler ayrı team’de. Client teams sadece consume.

Benim tercih option 1. Ownership client team’e.

Deployment pattern:
– Mobile BFF API gateway behind, multiple instances, horizontal scale
– Web BFF next to web server (SSR ile birlikte), edge deployment (Cloudflare Workers) option

Common antipatterns

1. BFF’te business logic. BFF aggregation layer. Business rules core services’te. BFF’te business logic sızarsa, farklı BFF’lerde inconsistency.

2. BFF’ten database access. Core services’e gitmeli. BFF direct DB’ye bağlanırsa, core service’in database’ini bypass ediyor.

3. BFF’ler arası coupling. Mobile BFF, Web BFF’i çağırıyor. Ağ ilişkisi karmaşık.

4. Too many BFFs. 5 client için 5 BFF. Maintenance yük exponentially artıyor.

BFF versioning

Mobile app versioned. Backend BFF de versioned.

/mobile/v1/products/:id
/mobile/v2/products/:id

v1 deprecated olana kadar support. Mobile app update’leri yavaş, eski client’lar hâlâ v1’e gidiyor.

Web için genelde single latest version. Web deploy ile update.

Performance optimization

BFF’lerin performansı önemli. Client’ın görebildiği latency BFF + downstream.

Tactics:

1. Request parallelization. Mümkün olan her zaman downstream call’ları parallel.
2. Caching. BFF’te Redis cache, downstream response’ları cache’le.
3. Connection pooling. Downstream services’e connection pool.
4. Circuit breaker. Downstream slow ise degraded response.
5. Edge deployment. Web BFF CDN edge’de (Cloudflare Workers), latency azalıyor.

Monitoring

BFF’ler monitor edilmesi gereken noktalar:

• Request rate per client. Mobile vs web.
• Latency p50/p95/p99. Her endpoint için.
• Downstream service response times. Hangi core service yavaş?
• Error rate. Client-side vs server-side.
• Cache hit rate. Caching etkili mi?

Grafana dashboard’ları per-BFF. Anomaly detection automated.

Sonuç

BFF pattern multi-client sistemlerin performans ve developer experience’ini artırıyor. Each client için optimal API.

Cost: ek infrastructure, operational complexity. Küçük takımda overkill. Büyük takım + multiple clients’ta essential.

GraphQL BFF’in modern bir varyantı. Client query’nin istediği field’ları dön. Specific BFF yazmadan similar benefits.

Karar verirken client diversity’ye, team structure’a, performance requirement’ına bak.