Ön Uç (BFF) Modeli için Arka Uç'u Anlamak: Basit Bir Kılavuz

Mikro hizmet mimarisinde sistemlerimiz Kullanıcı Hizmeti, Sipariş Hizmeti ve Ürün Hizmeti gibi düzinelerce küçük, odaklanmış hizmete bölünmüştür.

Ancak iş bu bilgiyi kullanıcılarınıza göstermeye gelince, farklı cihazların çok farklı ihtiyaçları vardır. Yüksek hızlı bir masaüstü bilgisayardaki bir web tarayıcısı; tablolar, kenar çubukları ve grafiklerle dolu zengin bir kontrol paneli ister. Yavaş bir hücresel ağdaki mobil uygulama, bant genişliğinden ve pilden tasarruf etmek için basit, hafif bir düzen istiyor. Bir akıllı saat uygulaması yalnızca tek satırlık bir metne ihtiyaç duyabilir.

Tüm bu ön uçlar tamamen aynı arka uç API’sini sorguluyorsa birisinin uzlaşması gerekir. Ya mobil uygulama büyük miktarda gereksiz veri indirmek zorunda kalıyor ya da web uygulaması ihtiyaç duyduğu her şeyi almak için düzinelerce ayrı ağ isteğinde bulunmak zorunda kalıyor.

Ön Uç için Arka Uç (BFF) Modeli tarafından çözülen sorun tam olarak budur. Bu kılavuzda, bu modeli basit kelimelerle açıklayacağız, gerçek dünyadaki bir benzetmeye bakacağız, bunu standart bir API Ağ Geçidi ile karşılaştıracağız ve pratik bir kod uygulamasını inceleyeceğiz.

Gerçek Dünya Analojisi: Restoran Menüsü

Üç farklı türde müşteriye hizmet veren bir restoran hayal edin:

1. Bir yemek eleştirmeni, ayrıntılı içerik listeleriyle birlikte 5 çeşitten oluşan tam bir tadım menüsü ister.
2. **Trende yemek için hızlı, önceden paketlenmiş atıştırmalık isteyen meşgul bir yolcu.
3. Küçük porsiyonlu ve baharatlı malzemeler içermeyen basit bir çocuk yemeği isteyen bir çocuk.

Restoranda üç seçeneğin tamamını tüm ayrıntılarıyla listeleyen tek bir menü olsaydı, bu çok zor olurdu. İşe gidip gelen kişi 5 çeşit yemek tarifini okuyarak zaman kaybedecek ve çocuğun ebeveynleri basit yiyecek seçenekleri bulmakta zorlanacaktı.

Bunun yerine restoran üç özel menü basıyor: Tadım Menüsü, Hızlı Gidilecek Menü ve Çocuk Menüsü.

Her menü aynı mutfaktan (mikro hizmetler) yararlanır, ancak seçenekleri o müşteriye (müşteriye) özel olarak biçimlendirir ve boyutlandırır.

Bu senaryoda:

• Mutfak mikro hizmetlerinizi (Kullanıcı, Katalog, Ödeme) temsil eder.
• Özel menüler BFF’lerinizdir (Web BFF, Mobil BFF, Watch BFF).
• Yemek yiyenler sizin ön uçlarınızdır (Masaüstü Tarayıcı, Mobil Uygulama, Akıllı Saat).

Sorun: “Herkese Uygun Tek Boyut” API’si

Mikro hizmetler ilk kez popüler hale geldiğinde birçok ekip, tüm ön uç istemcileri yönetmek için tek, paylaşılan bir API Ağ Geçidi oluşturdu:

Tek bir giriş noktası harika olsa da, paylaşılan bir API çeşitli ölçeklendirme darboğazları ortaya çıkarır:

• Mobil Cihazlar için Yük Şişmesi: Masaüstü web uygulaması, kullanıcının sipariş geçmişine, fatura adresine, profil resmine ve bağlılık puanlarına ihtiyaç duyar. Mobil uygulamada yalnızca “Son Sipariş: Gönderildi” ifadesinin gösterilmesi yeterlidir. Paylaşılan bir API ile mobil uygulama, profil yükünün tamamını indirerek değerli verileri boşa harcar ve yükleme sürelerini yavaşlatır.
• API Darboğazları: Tek bir ekip, paylaşılan ağ geçidi için darboğaz haline gelir. iOS ekibi küçük bir düzen alanını değiştirmek isterse, paylaşılan ağ geçidi ekibinin yeni bir sürümü dağıtmasını beklemek zorundadır, bu da geliştirme döngülerini yavaşlatır.
• Farklı Güvenlik İhtiyaçları: Bir web tarayıcısı, Siteler Arası Komut Dosyası Çalıştırmayı (XSS) önlemek için çerez tabanlı oturumlar gerektirebilirken, bir mobil uygulama, belirteç tabanlı OAuth başlıklarını tercih eder. Her ikisinin de tek bir sunucuda işlenmesi karmaşık ve karmaşık kod oluşturur.

Çözüm: BFF Modeli

BFF Modeli, tüm cihazlar için dev bir ağ geçidi oluşturmak yerine her ön uç uygulaması için özel bir arka uç sunucu oluşturmayı savunur.

Şunlara sahip olacaksınız:

• Web BFF: Masaüstü tarayıcısından gelen istekleri işler. Tam profilleri, ürün kataloglarını ve ayrıntılı ödeme bilgilerini bir araya getirir.
• Mobil BFF: iOS ve Android uygulamalarından gelen istekleri yönetir. Hızlı performans sağlamak için verileri toplar, gereksiz alanları filtreler ve son yanıtı sıkıştırır.

API Ağ Geçidi ve BFF: Fark Nedir?

Bu iki modeli karıştırmak yaygındır çünkü her ikisi de müşteri ile mikro hizmetler arasında yer alır. İşte ayrım:

Pratik Bir Uygulama (Node.js/Express)

Bunun pratikte nasıl çalıştığını anlamak için basit bir Node.js örneği yazalım.

Dahili olarak çalışan iki mikro hizmetimiz olduğunu düşünün:

• Kullanıcı Hizmeti (temel kullanıcı profili bilgilerini döndürür)
• Sipariş Hizmeti (tüm ayrıntılarıyla birlikte siparişlerin listesini döndürür)

Masaüstü sitemize ve mobil uygulamamıza farklı şekilde hizmet vermek için bir Web BFF ve bir Mobil BFF oluşturmak istiyoruz.

1. Paylaşılan Mikro Hizmetler Sahte

İlk olarak, iki temel mikro hizmetimizin sahte verilerini burada bulabilirsiniz:

// Internal User Service Response
const userProfile = {
    id: 42,
    username: "dev_coder",
    email: "coder@ghaznix.com",
    avatarUrl: "https://ghaznix.com/avatars/42.png",
    preferences: { theme: "light", newsletter: true }
};

// Internal Order Service Response
const orderHistory = [
    { id: "ORD-99", date: "2026-06-25", items: ["Laptop", "Mouse"], status: "Shipped", tax: 15.00, total: 1215.00 },
    { id: "ORD-88", date: "2026-05-12", items: ["Keyboard"], status: "Delivered", tax: 5.00, total: 105.00 }
];

2. Web BFF (Tam Ayrıntılı Yükü Döndürür)

Web BFF tüm alanları bir araya getirir çünkü masaüstü ekranında bunları gösterecek çok yer vardır:

const express = require('express');
const webBff = express();

webBff.get('/dashboard', (req, res) => {
    // Web needs everything: profile + full order details + settings
    const responsePayload = {
        user: {
            username: userProfile.username,
            email: userProfile.email,
            avatar: userProfile.avatarUrl,
            theme: userProfile.preferences.theme
        },
        orders: orderHistory // Send all order details, taxes, and items
    };
    
    res.json(responsePayload);
});

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

3. Mobil BFF (Minimize Edilmiş, Toplu Yük Getirir)

Mobile BFF, gereksiz alanları (e-posta, ayarlar ve vergiler gibi) filtreler ve bant genişliğinden tasarruf etmek için sipariş öğelerini bir araya getirir:

const express = require('express');
const mobileBff = express();

mobileBff.get('/dashboard', (req, res) => {
    // Mobile only wants: username, avatar, and summary of the latest order
    const latestOrder = orderHistory[0];
    
    const responsePayload = {
        user: {
            username: userProfile.username,
            avatar: userProfile.avatarUrl
        },
        latestOrderStatus: {
            orderId: latestOrder.id,
            status: latestOrder.status,
            date: latestOrder.date,
            itemCount: latestOrder.items.length // Send count instead of array list
        }
    };
    
    res.json(responsePayload);
});

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

Yük Boyutu Karşılaştırması

• Web BFF Yanıt Boyutu: İç içe konfigürasyonu, tercihleri, tam sipariş listesini, vergileri, öğeleri vb. içerir (Yaklaşık 400 bayt).
• Mobil BFF Yanıt Boyutu: Temel temelleri temsil eden yalnızca 6 anahtar/değer çifti içerir. (Yaklaşık 120 bayt—ağ boyutunda %70 azalma!).

BFF Modeli’nin Artıları ve Eksileri

Son derece etkili olmasına rağmen, BFF modelinin ödünleşimleri vardır:

Çözüm

Ön Uç için Arka Uç (BFF) Modeli, web, mobil ve IoT cihazları gibi birden fazla istemci türüne hizmet veren sistemler için güçlü bir mimaridir. Her bir ön uç için özelleştirilmiş ağ geçitleri oluşturarak, müşteri geliştirme sürecini birbirinden ayırır, yük boyutunu en aza indirir ve daha hızlı, daha duyarlı bir kullanıcı deneyimi sunarsınız.

Sisteminizde yalnızca tek bir web uygulaması varsa, paylaşımlı bir API Ağ Geçidi yeterlidir. Ancak web uygulamanızın yanı sıra mobil uygulamalar veya özel cihaz deneyimleri oluşturmaya başladığınız anda, bir BFF uygulamak, ön uç ve arka uç mimarilerinizi temiz, optimize edilmiş ve bağımsız tutmanın en iyi yoludur.

Ghaznix Blogunda daha fazla yazılım geliştirme ve arka uç mühendisliği öngörülerini keşfedin →