Birçok eşzamansız çağrıya karşı API'ya yapılan tek çağrı

Javascript aracılığıyla bir HTML5 ön ucu tarafından tüketilecek bir REST API geliştiriyoruz. Uygulama kuruluş içinde kullanım içindir ve genellikle yaklaşık 300 kullanıcısı vardır, ancak 1000'e kadar kullanıcıyı ölçeklendirmek istiyoruz.

Normalde API'ya bağlantılar LAN içinde yapılacaktır, bu nedenle bağlantıların kalitesi ve gecikmesi iyi olacaktır, ancak bağlantıların daha yavaş olabileceği ve 3G / 4G üzerinden daha fazla gecikme olabileceği İnternet üzerinden arada sırada kullanılmaz.

Düşündüğümüz iki seçenek:

1. Ön uç, arayüzün çeşitli bileşenlerini yüklemek için API'ye aynı anda birkaç eşzamansız çağrı yapar.

   • Artıları: Sadelik.
   • Eksileri: Sunucuya daha fazla bağlantı.

2. Ön ucun denetleyicisi, nesnelerin getirilmesi gereken parametreler olarak API'yi tek bir çağrıda geçirir.

   • Artıları: Sunucuya yalnızca bir bağlantı, ancak sunucu veritabanına birkaç bağlantı yapacak.
   • Eksileri: Hem ön uçta hem de API'da mekanizmalar gerektirir. Tasarımı karmaşıklaştırır.

Diğer açıklamalar: Farklı kaynaklar olacak ... / Ürün ... / Lokasyonlar vs. Bu kaynaklar tek başına getirilebilir, ancak başka bir soyut kaynak ... / ekran olacak mı?

Seçenek 1 (birden fazla zaman uyumsuz çağrı) en iyi seçimdir çünkü:

1. her bir çağrı kendi varlığıdır , bu nedenle bir şeylerin başarısız olması durumunda ayrı ayrı yeniden deneyebilirsiniz. Monolitik 'tek çağrı' mimarisinde, bir şey başarısız olursa tüm çağrıyı tekrar yapmanız gerekir
2. sunucu tarafı kodu daha basit olacaktır: yine, modülerlik , farklı geliştiricilerin farklı API kaynakları üzerinde çalışabileceği anlamına gelir
3. Tipik bir MVC modelinde , bir API çağrısının birden fazla ayrı kaynak yüklemesi mantıklı değildir ; örneğin, /productsbir sayfada gösterilecek ürünlerin listesini almak için istekte bulunursanız ve ayrıca popüler ürünlerin satıldığı konumların bir listesini görüntülemek istiyorsanız, iki ayrı kaynağınız vardır: Productve Location. Aynı sayfada görüntülenmelerine rağmen, mantıklı bir şekilde arama yapamaz /productsve konumlarını da döndürmesini sağlayamazsınız
4. günlük / kullanım raporlarınız modüler yaklaşımda daha basit olacaktır. Bir istekte bulunursanız /productsve ayrıca konumlar yüklüyorsanız, günlük dosyalarınız gerçekten kafa karıştırıcı olacaktır
5. belirli bir kaynakla ilgili bir sorununuz varsa, tek arama yaklaşımı sayfanın tamamının kırılmasına neden olur ve kullanıcılarınız için neyin kırıldığı açık değildir - bu, ekibinizin sorunu düzeltmesinin daha uzun süreceği anlamına gelir; Bununla birlikte, bir şey kırılırsa modüler yaklaşımda, neyin kırıldığı çok açık olacak ve daha hızlı düzeltebilirsiniz. Ayrıca sayfanın geri kalanını da mahvetmeyecek (işler çok yakından birleştirilmedikçe ...)
6. işler ayrılırsa genel olarak değişiklik yapmak daha kolay olacaktır; Bir API çağrısı tarafından yüklenen 5 kaynağınız varsa, bir şeyi değiştirmek istediğinizde bir şeyleri nasıl kırmayacağınızı bulmak daha zor olacaktır

Asıl mesele, kaynakların ayrı olması ve bir REST API'sinde, tek bir API yolundan birçok ayrı kaynak döndürmek, "sunucuya bağlantıları kaydediyor olsanız bile" mantıklı değildir. Bu arada, koşullu olarak (farklı) kaynakları yüklemek için parametreleri kullanmak RESTful değildir.

Tüm bunlar, tek mantıklı seçenek, kaynakları ayırmak için birden fazla zaman uyumsuz istek yapmaktır: modüler yaklaşımı kullanın !

PS - Özellikle HTTP bağlantıları aşırı düşük yükte ve bir LAN'dayken, "sunucuya olan bağlantıları" erken optimize etmeyin. Yarasadan daha basit tasarımı seçmek yerine bu tür bir düşünme daha sonra başınızı belaya sokacaktır.