Viele asynchrone Aufrufe im Vergleich zu einem einzelnen Aufruf der API

Wir entwickeln eine REST-API, die unter anderem von einem HTML5-Frontend via Javascript genutzt werden soll. Die Anwendung ist für die Verwendung in der Organisation vorgesehen und hat normalerweise etwa 300 Benutzer. Wir möchten jedoch eine Skalierung auf etwa 1000 Benutzer vornehmen.

Normalerweise werden Verbindungen zur API innerhalb des LAN hergestellt, sodass die Qualität und die Latenz der Verbindung gut sind. Es ist jedoch nicht ausgeschlossen, dass gelegentlich Verbindungen über das Internet langsamer und mit mehr Verzögerung über 3G / 4G hergestellt werden.

Die zwei Optionen, die wir dachten, sind:

1. Das Frontend ruft mehrere gleichzeitig asynchrone API-Aufrufe auf, um die verschiedenen Komponenten der Schnittstelle zu laden.

   • Vorteile: Einfachheit.
   • Nachteile: Mehr Verbindungen zum Server.

2. Der Controller des Frontends ruft einmalig die API auf und übergibt als Parameter, welche Objekte abgerufen werden müssen.

   • Vorteile: Nur eine Verbindung zum Server, obwohl der Server mehrere Verbindungen zur Datenbank herstellt.
   • Nachteile: Erfordert Mechanismen sowohl im Frontend als auch in der API. Es erschwert das Design.

Weitere Erklärungen: Es gibt verschiedene Ressourcen ... / Produkt ... / Standorte usw. Diese Ressourcen könnten alleine abgerufen werden, aber es gibt eine andere abstrakte Ressource ... / Bildschirm? Produkt & Standorte, die beide in einem Aufruf abrufen.

Option 1 (mehrere asynchrone Aufrufe) ist die beste Wahl, weil:

1. Jeder einzelne Anruf ist eine eigene Entität . Sie können ihn also einzeln wiederholen, wenn ein Fehler auftritt. Wenn in der monolithischen "One-Call" -Architektur eines fehlschlägt, muss der gesamte Anruf erneut ausgeführt werden
2. Der serverseitige Code wird einfacher: wieder Modularität , was bedeutet, dass verschiedene Entwickler an verschiedenen API-Ressourcen arbeiten können
3. In einem typischen MVC-Muster ist es nicht sinnvoll, dass ein API-Aufruf mehrere separate Ressourcen lädt . Wenn Sie beispielsweise eine Anforderung zum /productsAnzeigen einer Liste von Produkten auf einer Seite stellen und eine Liste der Standorte anzeigen möchten, an denen beliebte Produkte verkauft werden, stehen Ihnen zwei separate Ressourcen zur Verfügung: Productund Location. Obwohl sie auf derselben Seite angezeigt werden, können Sie nicht logisch einen Anruf tätigen /productsund auch Standorte zurückgeben
4. Ihre Protokollierungs- / Nutzungsberichte werden im modularen Ansatz einfacher. Wenn Sie eine Anfrage an stellen /productsund gleichzeitig Speicherorte laden, werden Ihre Protokolldateien sehr verwirrend
5. Wenn Sie ein Problem mit einer bestimmten Ressource haben, führt der One-Call-Ansatz dazu, dass die gesamte Seite unterbrochen wird und für Ihre Benutzer nicht ersichtlich ist, welche Fehler aufgetreten sind. Das bedeutet, dass Ihr Team länger braucht, um das Problem zu beheben. Wenn im modularen Ansatz jedoch eines kaputt geht, ist es sehr offensichtlich, was kaputt gegangen ist, und Sie können es schneller beheben. Es wird auch nicht den Rest der Seite ruinieren (es sei denn, die Dinge sind zu eng miteinander verbunden ...)
6. Es wird einfacher sein, Änderungen im Allgemeinen vorzunehmen, wenn die Dinge getrennt sind. Wenn Sie über 5 Ressourcen verfügen, die durch einen API-Aufruf geladen werden, ist es schwieriger, herauszufinden, wie Sie die Dinge nicht beschädigen können, wenn Sie etwas ändern möchten

Der springende Punkt ist, dass Ressourcen getrennt sind und in einer REST-API die Rückgabe vieler getrennter Ressourcen von einem einzelnen API-Pfad keinen Sinn ergibt, selbst wenn Sie "Verbindungen zum Server speichern". Übrigens ist die Verwendung von Parametern zum bedingten Laden (verschiedener) Ressourcen nicht REST-konform.

Die einzige logische Möglichkeit besteht darin, mehrere asynchrone Anforderungen zu senden, um Ressourcen zu trennen: Nehmen Sie den modularen Ansatz !

PS - Optimieren Sie "Verbindungen zum Server" nicht vorzeitig, insbesondere wenn HTTP-Verbindungen unglaublich wenig Overhead verursachen und Sie sich in einem LAN befinden. Diese Art des Denkens, anstatt gleich das einfachere Design zu wählen, wird Sie später in Schwierigkeiten bringen.