BFF ve API Gateway Farkları: Hangisi Ne Zaman Kullanılmalı

“BFF vs API Gateway”, mikro hizmet mimarisindeki en çok karıştırılan eşleşmelerden biridir. İki desen bir diyagram üzerinde benzer görünür. Her ikisi de hizmetlerinizin önünde yer alır. Her ikisi de bir istemci isteğini alır ve arka uçlara iletir. Bu yüzden ekipler bunların rakip seçenekler olduğunu varsayar, birini seçer ve yanlış sorumlulukları ona yükler.

Onlar rakip değildir. Bir Ön Uç İçin Arka Uç (BFF) ve bir API ağ geçidi farklı sorunları çözer, farklı ekipler tarafından sahiplenilir ve çok sık olarak aynı sistemde birlikte çalışır. BFF, ağ geçidinin yerine değil, arkasında veya yanında yer alır.

Bu kılavuz, aralarındaki farkı net bir şekilde ortaya koymaktadır. Her bir desenin gerçekte ne olduğunu, nerede örtüştüklerini, ne zaman birini veya her ikisini kullanacağınızı ve bunları bulanıklaştırmaktan kaynaklanan hataları öğreneceksiniz. Boyunca, API sözleşmesi sabittir: bir istek bir ağ geçidi, bir BFF veya her ikisi aracılığıyla akıp akmadığına bakılmaksızın, her katman hala tasarlamanız, test etmeniz, taklit etmeniz ve belgelemeniz gereken bir API sunar.

API Ağ Geçidi Nedir?

Bir API ağ geçidi, istemciler ve arka uç hizmetleriniz arasında yer alan merkezi bir giriş noktasıdır. Her istek ağ geçidi aracılığıyla gelir ve çağrıyı yönlendirmeden önce tutarlı bir dizi çapraz kesen endişeyi uygular.

Bu endişeler her istemci ve her hizmet için aynıdır:

• Yönlendirme: gelen bir yolu doğru yukarı akış hizmetiyle eşleştirme.
• Kimlik doğrulama ve yetkilendirme: token'ları doğrulama, yetkisiz arayanları reddetme.
• Oran sınırlama ve kısıtlama: arka uçları aşırı yüklenmeden ve kötüye kullanımdan koruma.
• Gözlemlenebilirlik: istekleri günlüğe kaydetme, metrikler yayma, hizmetler arası çağrıları izleme.
• TLS sonlandırma, önbellekleme ve istek dönüşümü: tesisatı bir kez, tek bir yerde yönetme.

Ağ geçidinin belirleyici özelliği, genel amaçlı olması ve merkezi olarak sahip olunmasıdır. Bir platform veya altyapı ekibi onu işletir ve tüm istemcilere eşit şekilde hizmet eder. Arayanın bir mobil uygulama, bir web SPA'sı veya bir iş ortağı entegrasyonu olup olmadığına aldırmaz; herkese aynı politikaları uygular.

Bu, ağ geçidini kuruluş genelindeki kurallar için doğal bir ev haline getirir. Her isteğin aynı şekilde kimlik doğrulamadan geçirilmesini veya her API'nin tutarlı bir şekilde oran sınırlanmasını istiyorsanız, ağ geçidi bu mantığı her hizmetin yeniden uygulamasına gerek kalmadan uygular. Bunun daha geniş platform araçlarından nasıl farklılaştığını görmek için API yönetimi ve API ağ geçidi yazısına bakın.

Ön Uç İçin Arka Uç (BFF) Nedir?

Sam Newman tarafından tanıtılan Ön Uç İçin Arka Uç (Backend for Frontend), yönelimi değiştirir. Her istemciye hizmet veren tek bir genel amaçlı arka uç yerine, her kullanıcı deneyimi için bir arka uç oluşturursunuz. Web uygulaması bir web BFF'si alır. Mobil uygulama bir mobil BFF'si alır. Her BFF, tam olarak tek bir ön uca göre uyarlanmıştır. Bu desen, birçok istemciye hizmet veren tek bir paylaşımlı arka ucun bir monolit gibi bir darboğaz haline geldiği mikro hizmet çalışmalarından ortaya çıkmıştır.

Newman'ın genel kuralı "bir deneyim, bir BFF"dir. Önemli ölçüde farklı ön uçlar kendi BFF'lerini alır; benzer olanlar (aynı ekip tarafından sürdürülen bir iOS ve bir Android uygulaması) bir tanesini paylaşabilir.

Buradaki belirleyici özellik sahiplik ve şekildir. Newman'ın sözleriyle, bir BFF "belirli bir kullanıcı deneyimiyle sıkı bir şekilde bağlantılıdır ve genellikle kullanıcı arayüzüyle aynı ekip tarafından sürdürülür." Ön uç ekibi kendi BFF'sine sahiptir. Müşteriyi ve arka ucunu birlikte geliştirirler, her değişikliği onaylaması için ayrı bir arka uç ekibini beklemek zorunda kalmazlar.

Bir BFF aslında ne yapar? Bir istemci için verileri şekillendirir:

• Agregasyon (Toplama): bir mobil ekran beş mikro hizmetten veri gerektirir. Mobil BFF, beşini de çağırır ve tek bir birleşik yanıt döndürür, böylece telefon beş yerine tek bir gidiş-dönüş yapar.
• Kırpma ve Yeniden Şekillendirme: mobil istemci kırk alandan sadece üçüne ihtiyaç duyar. BFF, bant genişliğinden tasarruf etmek için geri kalanını kaldırır.
• İstemciye özgü biçimlendirme: masaüstü uygulaması zengin bir görünüm için birden fazla sayfayı aynı anda getirir; mobil uygulama hafif kalmak için bir sayfa getirir. Her BFF, istemcisinin desenine hizmet eder.

BFF, kişilikli bir tür API toplayıcısıdır: aşağı akış çağrılarını birleştirir, ancak her zaman nötr, paylaşılan bir katman olmaktan ziyade belirli bir ön ucun hizmetinde yapar.

BFF ve API Ağ Geçidi Nerede Örtüşür?

Karışıklık anlaşılabilir çünkü iki desen yüzeysel davranışları paylaşır. Her ikisi de istemci isteklerini yakalar. Her ikisi de arka uçlara yönlendirebilir. Her ikisi de birden fazla hizmeti çağırabilir ve sonuçları birleştirebilir. Her ikisinin de bir diyagramı, istemciler ve hizmetler arasında bir kutu gibi görünür.

Örtüşme gerçek ama yüzeyseldir. Fark, niyet ve sahiplikte yatar:

• Bir API ağ geçidi, politikayı merkezileştirmek için tüm istemciler için genel olarak toplar ve yönlendirir.
• Bir BFF, belirli bir ön uç için istemcinin deneyimini optimize etmek amacıyla özel olarak toplar ve yönlendirir.

Microsoft'un kendi kılavuzu, hangi işlerin nerede olması gerektiği konusunda nettir. İzleme, yetkilendirme ve oran sınırlama gibi çapraz kesen özellikler BFF'den soyutlanmalı ve ağ geçidi tarzı desenlerle ayrı olarak ele alınmalıdır. BFF yalnızca istemciye özgü mantığı barındırmalıdır. Kimlik doğrulama ve kısıtlamayı bir BFF'ye koyarsanız, kötü bir şekilde bir ağ geçidinin yarısını yeniden inşa etmiş olursunuz ve yazdığınız her BFF'de bunu tekrar yapmanız gerekir.

Öyleyse pratik sınır şudur: eğer bir sorumluluk her istemci için aynıysa, ağ geçidinde yer alır. Eğer ön uca göre değişiyorsa, BFF'de yer alır.

BFF ve API Ağ Geçidi Birlikte Çalışıyor

Gerçek mikro hizmet sistemlerinde, nadiren birini seçersiniz. Her ikisini de katmanlı olarak çalıştırırsınız. Ağ geçidi kenarda yer alır. BFF'ler ise onun arkasında bulunur.

Tipik bir istek akışı şöyle görünür:

1. Mobil istemci, kimlik doğrulama token'ı ile bir istek gönderir.
2. API ağ geçidi, token'ı doğrular, oran sınırlamalarını uygular, gözlemlenebilirlik için isteği günlüğe kaydeder, ardından mobil BFF'ye yönlendirir.
3. Mobil BFF, ürün hizmetini, envanter hizmetini ve fiyatlandırma hizmetini çağırır, sonuçları toplar, mobil ekranın ihtiyaç duyduğu veriyi kırpar ve tek bir yanıt döndürür.
4. Ağ geçidi, yanıtı istemciye geri aktarır.

Microsoft'un bu desen için referans mimarisi tam da bunu yapar: bir API yönetimi ağ geçidi yetkilendirme, izleme, önbelleğe alma ve yönlendirmeyi halleder, ardından sunucusuz işlevler olarak çalışan istemciye özgü BFF hizmetlerine iletir ve bu hizmetler altta yatan mikro hizmetleri çağırır.

Her katman iyi olduğu işi yapar. Ağ geçidi, tek tip olması gereken politikaları yönetir. BFF, belirli olması gereken şekli yönetir. Ön uç ekibi, ağ geçidi yapılandırmasına dokunmadan BFF'sinde değişiklikleri devreye alır ve platform ekibi, herhangi bir BFF'yi yeniden dağıtmadan bir oran sınırını sıkılaştırır.

Bu katmanlama ilişkisi, bir ağ geçidinin diğer altyapılarla nasıl bir arada var olduğuna benzer, onu değiştirmek yerine. Bir ağ geçidi bir yük dengeleyici (API ağ geçidi vs yük dengeleyici) veya bir hizmet ağı (hizmet ağı vs API ağ geçidi) değildir; her biri istek yolunun ayrı bir katmanını ele alır ve bir BFF de sadece bir başka ayrı katmandır. Bu, API liderliğindeki bağlantının arkasındaki aynı prensiptir: her katmana net bir iş verin ve sadece onu yapmasına izin verin.

Karar Tablosu: BFF vs API Ağ Geçidi

Bunu sorumluluklar için bir yönlendirme sorusu olarak okuyun. Herkes için aynı olan ağ geçidine gider. Ön uca göre farklı olan BFF'ye gider. Bir sorumluluk hem ağ geçidinde hem de BFF'de (merkezi kimlik doğrulama istediğiniz ancak istemci başına veri şekillendirme de istediğiniz) olduğunda, bu bir taraf seçmek yerine her iki katmanı da çalıştırmak için bir sinyaldir.

Hangisini Ne Zaman Kullanmalı

Bir API ağ geçidi kullanın, birden fazla hizmetiniz olduğunda ve kimlik doğrulama, oran sınırlama ve yönlendirmeyi uygulamak için tek, tutarlı bir yere ihtiyacınız olduğunda. Neredeyse her mikro hizmet sistemi bundan faydalanır. İstemcilere maruz kalan bir avuçtan fazla hizmetiniz varsa, başka bir şeyden önce bir ağ geçidi istersiniz.

Bir BFF kullanın, farklı istemcilerin aynı arka uçtan anlamlı derecede farklı ihtiyaçları olduğunda ve paylaşılan genel amaçlı bir API darboğaz haline geldiğinde. Microsoft'un kılavuzuna göre yaygın tetikleyiciler:

• Paylaşılan bir arka ucun sürdürülmesi büyük çaba gerektirir çünkü rakip ön uçlara hizmet eder.
• Birden fazla arayüze uyum sağlamak için genel amaçlı bir arka ucu sürekli olarak özelleştirirsiniz.
• Mobil ve web'in gerçekten farklı veri ve performans ihtiyaçları vardır.

BFF'yi atlayın, tüm arayüzleriniz aynı veya benzer istekleri yaptığında veya arka uçla yalnızca bir arayüz konuştuğunda. Bir BFF, bir ağ atlaması, dağıtılacak daha fazla hizmet ve muhtemelen BFF'ler arasında bazı kod tekrarı ekler. Eğer tek bir paylaşılan API her istemciye iyi hizmet ediyorsa, bir BFF ihtiyacınız olmayan bir yüktür. Microsoft, ön uca özgü çözümleyicilere sahip bir GraphQL katmanının, istemciler tam olarak istedikleri alanları talep ettiği için ayrı bir BFF ihtiyacını da ortadan kaldırabileceğini belirtir.

Her ikisini de kullanın, mikro hizmetleri ölçekli çalıştırdığınızda: kenarda tek tip politika için ağ geçidi, arkasında istemciye özgü şekillendirme için BFF'ler. Bu, egzotik değil, yaygın nihai durumdur.

Yaygın Hatalar

• Kimlik doğrulama ve oran sınırlamayı BFF'ye koymak. Bu, en büyük hatadır. Çapraz kesen endişeler ağ geçidine aittir. Bunları BFF'ler arasında çoğaltırsanız, sapma yaşarsınız: mobil BFF bir politikayı, web BFF başka bir politikayı uygular ve güvenlik duruşunuz kazara tutarsız hale gelir.
• BFF'nin ikinci bir monolit haline gelmesine izin vermek. Bir BFF'nin küçük ve tek bir deneyime odaklanması amaçlanmıştır. Ekipler paylaşılan iş mantığını ona yığdığında, tekrar genel amaçlı bir arka uca dönüşür ve desenin kaldırması gereken darboğazı yeniden yaratmış olursunuz.
• Bir ağ geçidini BFF olarak kullanmak. Bazı ekipler, bir BFF oluşturmaktan kaçınmak için istemci başına istek dönüşüm kurallarını doğrudan ağ geçidi yapılandırmasına ekler. Bu küçük ölçekte işe yarar, ancak ağ geçidi merkezi olarak sahiplenildiği için, ön uç ekibi artık her istemciye özgü ayarlama için platform ekibine taleplerde bulunur. Yanlış ekipleri birbirine bağlamış olursunuz.
• Tek bir istemci varken BFF oluşturmak. Tek bir web uygulamanız varsa ve ufukta başka bir istemci yoksa, bir BFF erken bir adımdır. Paylaşılan API'yi yayınlayın. İkinci, farklı bir istemci gerçekten geldiğinde BFF'yi ekleyin.
• Sözleşmeyi unutmak. Her BFF ve her ağ geçidi yolu bir API sunar. Her birinin, diğer tüm API'ler gibi tanımlanmış bir sözleşmeye, testlere ve belgelere ihtiyacı vardır. Bunu atlarsanız, "ince" BFF katmanınız, sahip olan ekip dışından kimsenin entegre edemeyeceği belgelenmemiş bir kara kutu haline gelir. Bunun neden önemli olduğunu görmek için API sözleşmesi nedir makalesine bakın.

Apidog Nereye Uyar

Bir istek bir API ağ geçidi, bir BFF veya her ikisi aracılığıyla akıp akmadığına bakılmaksızın, her katman bir API sözleşmesi sunar. Apidog, bu sözleşmeleri tasarladığınız, test ettiğiniz, taklit ettiğiniz ve belgelediğiniz yerdir. Bir ağ geçidi veya bir BFF'yi inşa etmez, barındırmaz veya değiştirmez; bunların sunduğu API yüzeyleri için size tek bir çalışma alanı sağlar.

Somut olarak:

• Tasarım: BFF'nin toplu yanıtını veya ağ geçidinin yönlendirilmiş uç noktalarını görsel tasarımcıda şema-önce modelleyin, ardından hem ön uç hem de arka uç ekiplerinizin karşı geliştirmesi için OpenAPI oluşturun.
• Taklit (Mock): BFF'nin akış aşağı hizmetleri mevcut olmadan mobil ekibin ekranlarını geliştirebilmesi için BFF'nin akıllı bir taklidini kurun. Bu, paralel ön uç ve arka uç çalışmasını mümkün kılan API-öncelikli iş akışıdır.
• Test: gerçek bir istemcinin yapacağı gibi ağ geçidi önündeki uç noktalara vuran otomatik test senaryoları oluşturun, kimlik doğrulamayı, durum kodlarını ve toplanan yük şeklini doğrulayın.
• Belgeleme: her BFF ve ağ geçidi yolu için etkileşimli belgeler yayınlayın, böylece her tüketen ekip uygulamayı okumadan sözleşmeyi bilir.

Seçtiğiniz desen bir mimari kararıdır. Her katmanın sunduğu sözleşme sabittir. Apidog bu sabiti yönetir, böylece BFF'leriniz ve ağ geçitleriniz nasıl bağlarsanız bağlayın tasarlanmış, test edilmiş, taklit edilmiş ve belgelenmiş kalır.

Arka uç kodu yazmadan önce BFF ve ağ geçidi sözleşmelerinizi tasarlamak ve taklit etmek için Apidog'u ücretsiz deneyin.

Sıkça Sorulan Sorular

• BFF bir API ağ geçidi türü müdür? Hayır. Her ikisinin de yönlendirme ve toplama yapabilmesi açısından örtüşseler de, BFF bir ön uç ekibine aittir ve tek bir istemci deneyimine göre uyarlanmıştır, oysa bir API ağ geçidi merkezi olarak sahiplenilir ve tüm istemcilere tekdüze hizmet eder. Bir BFF genellikle bir ağ geçidinin arkasında yer alır.
• BFF'yi bir API ağ geçidi olmadan kullanabilir miyim? Evet, ancak ölçekli durumlarda genellikle yapmamalısınız. Bir ağ geçidi olmadan, her BFF'nin kimlik doğrulama ve oran sınırlama gibi çapraz kesen endişeleri yeniden uygulaması gerekir, bu da tutarsızlığa yol açar. Ağ geçidi bunları merkezileştirir, böylece her BFF yalnızca istemciye özgü şekillendirme ile ilgilenir.
• Kaç tane BFF'm olmalı? Sam Newman'ın "bir deneyim, bir BFF" kuralını takip edin. Önemli ölçüde farklı her ön uç için ayrı bir BFF oluşturun. Aynı ekip tarafından sürdürülen benzer istemciler (örneğin iOS ve Android uygulamaları) bir BFF'yi paylaşabilir.
• BFF, API ağ geçidimin yerini alır mı? Hayır. Bunlar tamamlayıcı katmanlardır. Ağ geçidi kenarda tek tip politikayı uygular; BFF ise arkasındaki belirli bir istemci için verileri şekillendirir. Çoğu gerçek mikro hizmet sistemi her ikisini de çalıştırır.
• Ne zaman bir BFF oluşturmamalıyım? Tüm istemciler benzer istekler yaptığında, yalnızca bir istemci mevcut olduğunda veya ön uca özgü çözümleyicilere sahip bir GraphQL katmanı zaten istemcilerin tam olarak ihtiyaç duydukları verileri almasını sağladığında atlayın.
• Kimlik doğrulama ve oran sınırlama nereye ait, BFF'ye mi yoksa ağ geçidine mi? Ağ geçidine. Bunlar, tüm istemcilerde tek tip olması gereken çapraz kesen endişelerdir. Bunları BFF'ye koymak, her BFF'de mantığı tekrarlar ve politika sapmasına davetiye çıkarır.