Web ve mobil istemciler için API Gateway vs BFF: artılar ve eksiler

Sorun: tek bir backend, birçok istemci, değişen ihtiyaçlar

Başlangıçta yaygın bir durum basittir: tek bir backend bir dizi uç nokta sunar ve hem web uygulaması hem mobil uygulama bunları çağırır. Tek bir yerde özellik eklemek, hataları düzeltmek ve kuralları uygulamak verimli gibi görünür.

Sonra gerçek hayat girer oyuna. Web arayüzü genellikle yoğun ekranlar, filtreler, dışa aktarma ve yönetici işlemleri ister. Mobil ise genellikle daha az alan, hızlı ekranlar, çevrimdışı dostu akışlar ve pil ile veri kullanımına dikkat gerektirir. Özellik "aynı" olsa bile, her istemci için en uygun API yapısı nadiren tamamen aynıdır.

Zamanla uç noktalar sapar. Web ekibi yeni bir tablo görünümü için ekstra alanlar ekler. Mobil ekip ağır payload'ları kaldırmak ve birden fazla çağrıyı birleştirmek ister. Birisi "sadece iOS için" bir parametre ekler. Başka biri dahili bir yönetici uç noktasını kamu uygulamasında "zaten oradaydı" diye yeniden kullanır. Bir zamanlar temiz olan API, ödünler koleksiyonuna dönüşür.

Riskler çabucak görünür:

• Bir istemci diğerinden daha hızlı gönderim yaptığında kırılma yaşanması
• Büyük payload'lar veya çok sayıda round trip nedeniyle yavaşlayan uygulamalar
• Her uç noktanın tüm istemcilere hizmet etmeye çalışmasıyla daha karmaşık backend kodu
• Dahili alanlar veya işlemler kamu API'lerine sızdığında isteğe bağlı veri açığa çıkması
• "Küçük değişiklikler"in eski istemciler için küçük olmaması yüzünden acılı sürümlendirme

İşte API gateway ile BFF tartışmasının temel gerilimi budur. Mobil ve web'in güvenebileceği kararlı kamu API'leri istiyorsunuz, aynı zamanda her istemciye kendi hızında evrilme alanı vermek istiyorsunuz.

API gateway ve BFF: ne oldukları (ve ne olmadıkları)

API gateway, API'leriniz için bir ön kapıdır. İstemciler gateway'e çağrı yapar ve gateway doğru backend servisine yönlendirir. Genellikle kimlik doğrulama kontrolleri, rate limitler, istek kayıtları ve temel istek şekillendirme gibi tekrar etmek istemediğiniz ortak kaygıları ele alır.

BFF (backend-for-frontend), belirli bir istemci veya istemci grubu (örneğin "web" ve "mobil") için inşa edilmiş küçük bir backend'dir. İstemci kendi BFF'ine çağrı yapar, BFF ise alttaki servislere çağrı yapar. Ana fikir odaklanmadır: BFF istemcinin dilini (ekranlar, akışlar, payload'lar) konuşabilir; temel servisler daha genel kalsa bile.

Bu desenlerin ne olmadığına dair önemli bir nokta: iyi domain servislerinin veya temiz bir veri modelinin yerini almazlar. Çekirdek servisleriniz, veritabanlarınız ve iş kurallarınız gerçeğin kaynağı olmaya devam etmelidir. Gateway veya BFF, yavaş yavaş gerçek backend'iniz haline gelen devasa bir iş mantığı yığını olmamalıdır.

Basit bir ayrım:

• Gateway: tek giriş noktası, paylaşılan kaygılar, yönlendirme ve koruma
• BFF: istemciye özgü API'ler, istemci işini azaltır ve dahili karmaşıklığı gizler

Ayrıca bunları birleştirebilirsiniz. Yaygın bir kurulum, kamuda gateway, arkasında ise web ve mobil için ayrı BFF'lerdir. Gateway dış güvenliği ve trafik kurallarını ele alırken, her BFF istemci için uç noktaları ve yanıtları şekillendirir.

Her desenle istek yolunun nasıl değiştiği

API gateway ile BFF arasındaki en büyük fark, "ön kapı" mantığını nereye koyduğunuzdur: yönlendirme, kimlik doğrulama kontrolleri ve yanıt şekillendirme.

API gateway ile istemci genellikle tek bir paylaşılan giriş noktasına konuşur. Gateway istekleri dahili servislere iletir, genellikle token doğrulama, rate limit ve yol bazlı yönlendirme gibi temel işleri yapar.

BFF ile her istemci tipi (web, iOS, Android) için spesifik olarak inşa edilmiş bir backend çağrılır. Bu BFF alttaki servislere çağrı yapar ve o istemcinin ekranları ve kısıtları için özelleştirilmiş bir yanıt döner.

İstek yolunu basitçe şöyle düşünebilirsiniz:

• API gateway yolu: İstemci -> Gateway -> Servis(ler) -> Yanıt
• BFF yolu: İstemci -> BFF (web veya mobil) -> Servis(ler) -> Yanıt

Sahiplik de genellikle kayar. Gateway tipik olarak platform veya altyapı ekibi tarafından sahiplenilir çünkü herkesi ve her servisi etkiler. BFF ise genellikle özellik ekibi tarafından sahiplenilir çünkü UI ile birlikte hareket eder ve sürüm döngüsüne bağlıdır.

Kimlik doğrulama genelde şu şekilde akar: istemci bir token gönderir, kenar katmanı (gateway veya BFF) bunu doğrular veya bir auth servisine iletir ve sonra kimlik bilgilerini (kullanıcı id, roller) aşağıdaki servislere iletir. Fark, istemci kurallarını nerede uyguladığınızdadır. Gateway ile politikalar genellikle istemciler arasında genel ve tutarlı olur. BFF ile ise mobil için daha küçük payload döndürmek veya yavaş ağlarda birden fazla servis çağrısını tek bir yanıta birleştirmek gibi istemciye özgü şekillendirmeler ekleyebilirsiniz.

İşte BFF'lerin parladığı nokta şekillendirme adımıdır, fakat bu ayrıca dağıtılacak ve tutarlı tutulacak daha fazla hareketli parça anlamına gelir.

Açık vs dahili uç noktaları güvenle ayırmak

Açık bir uç nokta, web uygulamanızın, mobil uygulamanızın, ortaklarınızın veya üçüncü tarafların erişebileceği herhangi bir API rotasıdır. Varsayılan olarak düşmanca muamele edin; çünkü ağını veya çağrı yapan istemci kodunu kontrol edemezsiniz.

Dahili uç nokta, sisteminiz içindeki servisler arası trafik içindir. Daha hızlı değişebilir, daha fazla bağlam varsayabilir ve daha zengin veri açığa çıkarabilir; ancak asla doğrudan genel internetten erişilebilir olmamalıdır.

API gateway ile ayrım genellikle fiziksel ve anlaşılması kolaydır: sadece gateway açığa çıkar ve hangi dış rotaların var olacağını o kararlaştırır. Arkasındakiler özel kalır. Dahili servis API'lerini ifade edici tutabilir, gateway ise daha küçük ve güvenli bir yüzeyi zorlar.

BFF deseninde ayrım daha çok ürün sınırları hakkındadır. Her istemci (web, iOS, Android) sadece kendi BFF'iyle konuşur ve BFF dahili servislere çağrı yapar. Bu, iç karmaşıklığı gizlemenize izin verir: BFF üç servisi çağırıp sonuçları birleştirip istemcinin gerçekten ihtiyaç duyduğu basit bir yanıt sunabilir.

Ayrım yalnızca pratik kontroller eklediğinizde güvenlidir:

• Her rota için özel yetkilendirme: sadece "giriş yapılmış" anahtarı değil, roller ve scope'lar
• Açık uç noktalar için kullanıcı, token ve IP başına rate limitler
• Payload filtreleme: istemciye yalnızca gerekeni döndürün, dahili ID'leri, debug bilgilerini ve sadece adminlere özel alanları çıkarın
• Temiz allowlist'ler: hangi uç noktaların kamuya açık olduğu, hangilerinin sadece dahili olduğu

Örnek: mobil uygulama "Siparişlerim" ekranına ihtiyaç duyuyor. BFF /orders gibi sadece sipariş durumu ve toplamları döndürebilir; dahili sipariş servisi ise ayrıntılı maliyet dökümleri ve dolandırıcılık bayraklarını gizli tutar.

Sürümleme: ne kolaylaşıyor, ne zorlaşıyor

Sürümleme acısı genellikle web ve mobilin farklı hızlarda hareket etmesiyle ortaya çıkar. Web ekibi saatler içinde yayın yapıp geri alabilir. Mobil uygulama ise uygulama mağazası incelemesi ve kullanıcıların güncelleme yapmaması yüzünden güncellemeleri günler veya haftalar alabilir. Bu boşluk API gateway vs BFF kararını pratik kılar.

API gateway ile sürümlendirmeyi tek bir ön kapıya koyabilirsiniz (örneğin /v1/..., /v2/...). Bu açıklaması kolay ve yönlendirmesi basittir. Dezavantajı, birçok istemci ve entegrasyon eski sürümlere takıldığında gateway'in bir sürüm müzesine dönüşebilmesidir. Aynı verinin eski şekillerini daha uzun süre destekleme ihtiyacı doğar.

BFF ile sürümlendirme genellikle "istemci başına"dır. Mobil BFF eski bir kontratta kalabilirken web BFF daha hızlı hareket edebilir; her ikisi de aynı dahili servislere konuşuyor olabilir. Bu genellikle kamu sürümlerini sonsuza kadar yaşatma baskısını azaltır. Takas, yönetilecek ve konuşlandırılacak daha fazla hareketli parça olmasıdır.

Servis içinde sürümlendirme de çalışabilir, ama bu istemci odaklı değişiklikleri sisteminizin derinlerine itebilir. Ayrıca servis mantığı istemci sürümlerine göre dallanmaya başladığında dahili kodu okumayı zorlaştırır.

Kırılmayan değişiklikler en iyi arkadaşınızdır: isteğe bağlı alanlar eklemek, yeni uç noktalar eklemek veya ekstra giriş alanlarını kabul etmek. Kırıcı değişiklikler alanın adını değiştirmek, tipini değiştirmek (string -> number) veya bir uç noktayı kaldırmaktır.

Emeklilik (deprecation) planlıyken en iyi çalışır:

• Net bir sonlandırma tarihi belirleyin ve erken haber verin
• Eski sürüm kullanımını takip edin (loglar, metrikler) ve geride kalanları izleyin
• Önce istemci güncellemelerini yayınlayın (özellikle mobil), sonra eski yolu kaldırın
• Eski sürüm engellendiğinde net bir hata mesajı döndürün

Performans: gecikme, payload boyutu ve çağrı sayısı

API gateway vs BFF düzeninde performans çoğunlukla bir takastır: sisteminiz içinde bir ekstra hop eklemek mi, yoksa istemciden gelen daha az ama daha gecikmeli ağ çağrıları mı? En hızlı seçenek genellikle istemcinin yavaş, güvenilmez ağ zamanını azaltandır, küçük bir sunucu tarafı adım eklemek bile olsa.

BFF, istemci aksi takdirde birçok çağrı yapacaksa genelde kazanır. Web ve mobil beş uç noktayı çağırıp sonuçları cihazda birleştirmek yerine, BFF sunucu tarafında gerekenleri çekip tek bir yanıt dönebilir. Hücresel ağlarda her istek gecikme eklediği için bu genelde mobilde toplam gecikmeyi azaltır.

Gateway veya BFF'den elde edilen yaygın performans kazançları:

• Toplama: birden fazla servisten veriyi tek yanıtta birleştirme
• Daha akıllı önbellekleme: kenarda veya BFF'de yoğun okuma ekranları için önbellekleme
• Daha küçük payload'lar: ekranın ihtiyaç duyduğu alanları döndürme
• Daha az round trip: konuşkan istemci davranışını azaltma
• Tutarlı sıkıştırma ve zaman aşımı: tek yerde varsayılanları zorlamak

Ama bu desen de zarar verebilir. Her ek katman CPU işi ve bekleme yerleri ekler. Web ve mobil için aynı toplama mantığını çoğaltırsanız işi iki kere yapar ve tutarsız davranışlar yaratabilirsiniz. Aşırı veri çekme (over-fetching) başka yaygın bir kayıp: her ekranı tatmin etmeye çalışan genel bir uç nokta büyük payload'lar döndürebilir ve bant genişliği ile zamanı boşa harcar.

Mobil gerçekleri bu takasları daha keskin yapar. Güvenilmez ağlar yeniden denemeler ve zaman aşımı anlamına gelir; her ekstra çağrı pil tüketir. Soğuk başlangıçlar da önemlidir: uygulama ilk ekran için kullanılabilir olmadan önce birkaç isteğe ihtiyaç duyuyorsa bunu kullanıcı hisseder.

Pratik bir kural: önce istemci istek sayısını azaltmak için optimize edin, sonra ek hop için optimizasyon yapın.

Tasarımı hızlıca değerlendirmek için

Bir ekran 2-3 ardışık çağrıdan fazla ihtiyaç duyuyorsa, toplama (aggregation) düşünün. Yanıtlar büyük ve çoğu kullanılmıyorsa, uç noktaları bölmeyi veya istemciye özel bir BFF kullanmayı düşünün.

Operasyon: dağıtım, izleme ve ölçeklendirme

API gateway vs BFF ile asıl operasyonel soru, kaç tane hareketli parçayı çalıştırıp desteklemeye istekli olduğunuzdur. Gateway genellikle birçok ekip ve istemci için paylaşılmış altyapı haline gelir. BFF'ler genellikle daha küçük servislerdir, ama istemci başına (web, iOS, Android, ortak) bir tane olursa yayın ve on-call yükü artar.

Test ve sürümlerde gateway, yönlendirme, auth ve rate limit gibi ihtiyaçlarınız ağırlıktaysa daha güvenli olabilir. Değişiklikler merkezileştiği için bir hata herkesi etkileyebilir. BFF'ler patlama yarıçapını azaltır çünkü web'e özel bir değişiklik web BFF'e gönderilir, mobil BFF değil. Takas daha fazla pipeline ve birden fazla sürümün eş zamanlı yönetilmesi gerekliliğidir.

Gözlemlenebilirlik için tek bir kullanıcı isteğini katmanlar boyunca görmeniz gerekir, özellikle tek bir mobil çağrı birkaç backend çağrısını tetikliyorsa.

• Bir korelasyon ID'si kullanın ve gateway, BFF ve backend loglarında iletin
• Zamanın nerede harcandığını görmek için izler (tracing) yakalayın (gateway, BFF, downstream servisler)
• Yapılandırılmış loglar tutun (istemci, uç nokta, durum kodu, gecikme, payload boyutu)
• Her uç nokta için birkaç ana metrik izleyin: hata oranı, p95 gecikme, throughput

Ölçeklendirme de farklı görünür. Gateway paylaşılmış bir boğulma noktasıdır: pikleri ve sıcak uç noktaları handle edebilmelidir. BFF'ler istemci başına ölçeklemenize izin verir; örneğin web trafiği iş saatlerinde ani artış gösterirken mobil sabit kalabilir.

Olay anında arızalar desenlere göre "taşınabilir". Gateway ile sorunlar genelde yaygın 5xx veya auth hataları olarak görünür. BFF'lerle sorunlar bir istemcinin özelliğine izole olabilir. Runbook'ları nereye bakılacağını açık yapın ve yedek davranışı basit tutun (örneğin zaman aşımı yerine azaltılmış bir yanıt döndürmek).

Nasıl seçilir: basit adım adım karar süreci

API gateway ile BFF arasındaki seçim teoriden çok, istemcilerinizin günlük ihtiyaçları hakkındadır.

Pratik bir karar akışı

1. Sunucularınızdan değil, istemcilerinizden başlayın. Desteklediğiniz her istemciyi (web uygulaması, iOS, Android, ortak API, dahili admin) yazın ve her birinin ana ekranlarının neye ihtiyaç duyduğunu listeleyin. Aynı "Müşteri detayları" görünümü istemciler arasında farklı alanlar ve çağrı desenleri gerektiriyorsa, bu istemciye özel şekillendirme için güçlü bir sinyaldir.

2. Bugün sahip olduklarınızı haritalayın. Mevcut uç noktalarınızı alın ve hangi parçaların paylaşıldığını (siparişler, ödemeler, kullanıcılar gibi çekirdek domain operasyonları) ve hangi parçaların sunum-şeklinde olduğunu (dashboard özeti, birleşik "ana ekran" payload'ı) işaretleyin. Paylaşılan parçalar çekirdek backend'e aittir. Sunum-şeklindeki parçalar genellikle bir BFF'e daha uygundur.

3. Şekillendirme ve kuralların nerede olması gerektiğine karar verin. Eğer ağırlıklı olarak yönlendirme, auth, rate limit, önbellekleme ve açık vs dahili uç noktaların güvenli açılması gerekiyorsa gateway doğal yerdir. Gerçek bileşim (birden fazla servisi çağırıp altı çağrıyı birleştirmek gibi) gerekiyorsa, o mantığı test edilebilir ve okunabilir tutmak için BFF kodunda tutun.

4. Uygulanabilir bir sürümleme ve emeklilik kuralı seçin. Örneğin: "Kırıcı değişiklikler yeni bir sürüm olmadan yapılmaz ve her kullanımdan kaldırılan alan 90 gün boyunca yaşatılır." Gateway-only yaklaşımda kamu yüzeyini sürümlendirmek ve arkada çeviri yapmak zorunda kalabilirsiniz. BFF'lerde genelde çekirdek API'leri sabit tutup sadece istemci uç noktalarını sürümlendirirsiniz.

5. Yayılımı planlayın ve ölçün. Değişiklik yapmadan önce baz metrikleri alın: p95 gecikme, ekran başına çağrı sayısı, payload boyutları ve hata oranları. Önce küçük yüzdede yayınlayın, önce-sonra karşılaştırın, sonra genişletin.

Basit bir örnek: mobil uygulamanız aylık çıkıyor ama web portalınız günlük yayın yapıyorsa, küçük bir mobil BFF uygulamanın sık backend değişikliklerinden etkilenmesini engelleyebilir, web ise hızlıca ilerlemeye devam edebilir.

Örnek: farklı yayın hızlarına sahip web portal + mobil uygulama

Bir şirket düşünün: web'de bir müşteri portalı ve sahada çalışanlar için bir mobil uygulama var. Her ikisi de aynı çekirdek verilere ihtiyaç duyuyor: müşteriler, işler, faturalar ve mesajlar. Portal haftalık değişiyor. Mobil uygulama daha yavaş güncelleniyor çünkü uygulama mağazası incelemesi gerekiyor ve zayıf sinyal ile çalışması gerekiyor.

Ağrı çabucak görünür. Mobil kullanıcılar kompakt cevaplar, daha az çağrı ve çevrimdışı çalışmayı destekleyen akışlar istiyor (örneğin bugünün işlerini bir kere indirip sonra değişiklikleri senkronize et). Web portal daha fazla çağrı yapmaya ve daha zengin ekranlar yüklemeye uygundur çünkü her zaman çevrimiçi ve güncellemesi daha kolaydır.

Seçenek A: Kararlı servislere önünde API gateway

Gateway-öncelikli seçim backend servislerinizi büyük ölçüde değişmeden tutar. Gateway kimlik doğrulama, yönlendirme ve başlık, rate limit ve basit alan eşleştirme gibi küçük ayarlamaları yapar.

Sürümleme çoğunlukla servis API seviyesinde kalır. Bu iyi olabilir: daha az hareketli parça. Ancak mobil-özel değişiklikler genellikle altında yatan uç noktalar paylaşıldığı için /v2 gibi geniş sürümlere itebilir.

Uç nokta açılımı daha net olur eğer gateway'i tek kamu kapısı olarak görürseniz. Dahili uç noktalar arkada kalsın, ama gateway'in erişebileceklerini ve yayınlayacaklarını sıkı tutmanız gerekir.

Seçenek B: "Mobil" konuşan bir mobil BFF

Mobil BFF ile mobil uygulama mobil ekranlara ve senkronizasyon akışlarına uygun uç noktalarla konuşur. BFF veriyi birleştirebilir (iş detayı + müşteri + son mesaj), alanları kırpabilir ve uygulamanın ihtiyaç duyduğu tek bir payload döndürebilir.

Ne değişir:

• Sürümleme istemci başına daha kolay olur: mobil BFF'i sürümlendirip web portalı zorlamazsınız
• Performans genelde mobil için iyileşir: daha az round trip ve daha küçük cevaplar
• Açık vs dahili ayrım daha net olur: BFF kamuya açık olur, dahili servisler hiç açılmak zorunda kalmaz

Yaygın hatalar ve kaçınılması gereken tuzaklar

API gateway vs BFF tartışmasındaki en büyük tuzak gateway'i mini bir backend'e dönüştürmektir. Gateway yönlendirme, auth, rate limit ve basit istek şekillendirme için harikadır. İçine iş kuralları doldurduğunuzda, test etmesi zor, debug'ı zor ve konfigürasyon değişikliğinde kolayca kırılabilir bir yapı ortaya çıkar.

BFF'ler ters yönde yanabilir: ekipler her ekran veya özellik için bir BFF yaratır ve bakım patlar. Bir BFF genelde istemci tipine (web, iOS, Android) veya net bir ürün alanına göre olmalıdır, her UI görünümü için değil. Aksi halde aynı kuralları on yerde çoğaltır ve sürümlendirme tam zamanlı bir iş haline gelir.

Sürümleme hataları uç nokta. Her şeyi ilk gün sürümlendirirseniz API'nizi çok erken dondurursunuz ve eski varyantları sonsuza kadar yaşatırsınız. Hiç sürümlendirme yapmazsanız istemeden kırıcı değişiklikler gönderirsiniz. Pratik bir kural: küçük ekleyici değişiklikler için sürümlendirme yapmayın; bir alan kaldırıldığında veya anlamı değiştiğinde sürüm oluşturun.

Açık vs dahili uç noktalar ise ekipleri yaralar. Dahili servisleri geçici de olsa internete açmak her dahili değişikliği potansiyel bir kesinti veya güvenlik olayı yapar. Net bir sınır tutun: sadece gateway veya BFF kamuya açık olsun, dahili servisler özel kalsın.

Performans problemleri genelde kendi yarattığınızdır: aşırı büyük payload'lar, çok fazla round trip ve gecikme bütçesi yokluğu. Örneğin mobil uygulama yalnızca sipariş durumu ve toplamlara ihtiyaç duyarken tam sipariş objesini (her satır öğesi ve audit alanlarıyla) alıyorsa, hücresel ağda her istek yavaş olacaktır.

Dikkat işaretleri:

• Gateway konfigürasyonları "iade uygunluğu" veya "VIP kuralları" gibi iş kavramlarına referans veriyorsa
• BFF'ler, hizmet verdikleri istemcilerden daha hızlı çoğalıyorsa
• API sürümleme stratejinizi bir cümleyle açıklayamıyorsanız
• Dahili servis uç noktaları genel internetten erişilebiliyorsa
• Yanıtlar "belki sonra işe yarar" diye büyümeye devam ediyorsa

Hızlı kontrol listesi ve sonraki adımlar

API gateway vs BFF kararında takılı kaldıysanız, önce gerçekte neyin ilk kırılacağını düşünün: sürümler, payload'lar ve güvenlik sınırları.

Hızlı kontrol listesi

Bu sorulardan birkaçına "hayır" diyorsanız, istemcileriniz büyüdükçe mevcut kurulumunuz muhtemelen zarar verecektir:

• Bir backend servisini tüm istemcileri aynı hafta güncellemek zorunda kalmadan değiştirebiliyor musunuz?
• Açık uç noktalar (internet için güvenli) ile dahili uç noktalar (sadece güvenilir sistemler) arasında net bir sınır var mı?
• Web ve mobil yalnızca ihtiyaç duyduklarını mı alıyor (büyük "mutfak lavabosu" yanıtı değil)?
• Değişiklikleri kademeli olarak (önce küçük bir yüzde) yayınlayıp hataları, gecikmeyi ve alışılmadık trafiği çabucak görebiliyor musunuz?
• Her uç noktanın sözleşmesinden kim sorumlu ve kırıcı değişiklikleri kim onaylıyor biliyor musunuz?

Sonraki adımlar

Cevapları bir plana dönüştürün. Amaç mükemmel mimari değil, gönderirken daha az sürpriz olsun.

API sözleşmenizi sade dille yazın (girdi, çıktı, hata kodları, neyin değişmesine izin verildiği). Sahiplik modelini seçin: istemci ihtiyaçlarından (web/mobil) kim sorumlu ve çekirdek domain servislerinden kim sorumlu? Sürümlemenin nerede olacağına karar verin (istemci bazlı mı, merkezi mi) ve uyacağınız bir emeklilik kuralı belirleyin.

Büyük refaktörlerden önce temel izlemeyi ekleyin: istek oranı, p95 gecikme, hata oranı ve payload boyutuna göre en büyük uç noktalar. En riskli istemci akışlarını önce prototipleyin.

Eğer AppMaster (appmaster.io) ile inşa ediyorsanız, pratik bir yaklaşım çekirdek iş mantığını ve veri modellerini üretilen backend'de tutmak, sonra bir istemci gerçekten farklı payload şekillendirme veya sürüm izolasyonu gerektiğinde ince bir gateway veya BFF katmanı eklemektir.

Eğer kontrol listesi cevapları zor geliyorsa, bunu daha fazla uç nokta eklemeden önce sözleşmeyi basitleştirmek ve açık vs dahili ayrımı sıkılaştırmak için bir işaret olarak alın.