API mantığı nerede çalışmalı: veritabanı, ara katman veya uygulama?

Bir işlevi veriye yaklaştırmak uygulama sunucusunun işini azaltabilir, fakat kararın sahibini de değiştirebilir. Alan doğrulayıcı müşterinin devam edip edemeyeceğine karar vermeye başlarsa küçük optimizasyon bir iş kontrolüne dönüşür.

Kuralı ihtiyaç duyduğu veri ve yetkiye, nasıl test edileceğine ve nasıl geri alınacağına göre yerleştirin. Dil sözdizimi ve araç kolaylığı sonra gelir.

Dört yayın, ayrı katmanlar

Percona’nın 15 Ekim MySQL JavaScript yazısı ağ ve dosya erişimi olmayan sınırlı işlevleri anlatıyor. Supabase’in 15 Ekim ara katman yayını Fetch işleyicilerinde sıralı bileşimi açıklıyor.

Cloudflare’ın 14 Ekim incelemesi bağlantı durumu ve önbellek doğruluğunu ele alıyor. Postman’ın 9 Ekim yazısı buluttan yük üretimini anlatıyor. Bunlar herhangi bir API için hız artışı kanıtlamıyor.

Mimari çıkarımımız, sınırlı değer dönüşümünü, isteğin kabulünü ve iş kararını ayırmaktır. Önbellek de yeniden kullandığı yanıtın anlamını ve erişim sınırlarını korumalıdır. Her uygulama kendi teknoloji bileşimiyle doğrulanır.

Hesaplama ile yetki farklıdır

Bir işlev telefon numarasını standartlaştırıp hata listesi döndürebilir. Müşteriyi aramak, başvuruyu reddetmek veya operatöre sormak ise süreç durumuna, çalışan yetkisine ve şirket politikasına bağlıdır. Bu bağımlılıkları küçük dönüşüm işlevinde tutmak daha zordur.

Ara katman doğrulanmamış kimliği durdurabilir. Geçerli belirteç belirli bir talebi onaylama yetkisi vermez. Kayıt sahipliği, güncel durum ve izin verilen geçiş ayrıca değerlendirilir.

Bu ayrım her kural için mikroservis gerektirmez. Aynı uygulamanın parçaları arasında açık sözleşme yeterlidir: ne kontrol edildi, hangi değer üretildi, kim karar verebilir? Aksi halde kullanışlı bir işlevin tekrar kullanımı arayüz değişmeden yetki alanını büyütür.

Geri dönüş sorusu gizli bağımlılığı açığa çıkarır. Standartlaştırma kuralını geri almak eşleştirmeyi değiştirebilir. Onay politikasını geri almak ise ürün kararıdır. İkisini sıradan yardımcı kod güncellemesi saymak incelemeyi zorlaştırır.

Varsayımsal kişi aktarımı

Şirket çeşitli kaynaklardan iş ortağı kişilerini içeri aktarıyor olsun. Bir satırda boşluklu telefon, diğerinde mevcut müşteriye benzeyen ad, üçüncüsünde başka kuruluşun bilgisi var. Bu, uygulanmış sonuç değil, tasarım örneğidir.

İstek sınırı kuruluşu ve aktarım yetkisini belirler. Değer işleme normalleştirilmiş numara ve hata işaretleri üretir. Uygulama mevcut kişinin güncellenip güncellenemeyeceğine ve çakışmayı kimin çözeceğine karar verir. Benzer ad kayıt birleştirme izni değildir.

Tekrarlanan aktarımda kaynak satır kimliği ve içerik sürümü korunur. Yeni kural farklı sonuç üretirse operatör nedeni görmelidir; ilgisiz yeni kayıtla karşılaşmamalıdır. Kaynak veriyi saklamak açıklamaya yardım eder, ancak müşteri verisiyle aynı erişim disiplinini ister.

Ortak biçim sözlüğünü önbelleğe almakla kişisel yanıtı önbelleğe almak farklı politika seçimleridir. İkincisi yetki bağlamı, geçersizleştirme ve kabul edilebilir eskilik sınırı gerektirir. Daha hızlı ekran, doğru önbellek politikası kanıtı değildir.

Yer değiştiren işi ölçün

Hesaplama veritabanına taşındığında uygulama hızlanırken veritabanının yükü artabilir. Bütün istek yolunu, bağlantı rekabetini, işlem süresini ve hataları karşılaştırın. Yoksa optimizasyon kuyruğu başka yere taşır.

Geçerli girdi, çakışma ve reddedilen işlemleri yük senaryosuna ekleyin. Temiz aktarım problemli satırların maliyetini göstermez. Bulut yük üreticisi dizüstü kısıtını ayırabilir; gerçekçi olmayan senaryoyu temsil edici hale getiremez.

Yararlı kabul koşulu, aynı girdi ve yetkilerin değişiklik öncesinde ve sonrasında aynı iş kararını üretmesidir. Performans sonra değerlendirilir. Kararın bilerek değişmesi ayrı ürün kabulü gerektirir.

İş mantığı ve kurallar bu sınırları geliştiriyor. Özel API proje taslağı ilgili bağlamı veriyor. API entegrasyonu planlaması işlevin yerini seçmeden önce kararlar ve yetkilerle başlayabilir.