it-swarm.com.de

Viele asynchrone Aufrufe im Vergleich zu einem einzelnen Aufruf der API

Wir entwickeln eine REST API), die unter anderem von einem HTML5-Frontend über Javascript verwendet wird. Die Anwendung ist für die Verwendung innerhalb des Unternehmens vorgesehen und hat normalerweise ungefähr 300 Benutzer, aber wir möchten skalieren gut bis zu 1000 Benutzer oder so.

Normalerweise werden Verbindungen zur API innerhalb des LAN hergestellt, sodass die Qualität und Latenz der Verbindung gut ist, obwohl eine gelegentliche Verwendung über das Internet nicht ausgeschlossen ist, wenn die Verbindungen langsamer und mit größerer Verzögerung über 3G/4G sein können.

Die zwei Optionen, die wir dachten, sind:

  1. Das Frontend führt mehrere gleichzeitige asynchrone Aufrufe der API durch, um die verschiedenen Komponenten der Schnittstelle zu laden.

    • Vorteile: Einfachheit.
    • Nachteile: Mehr Verbindungen zum Server.
  2. Der Controller des Frontends ruft die API einmal 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 wird verschiedene Ressourcen geben .../Produkt .../Standorte usw. Diese Ressourcen könnten alleine abgerufen werden, aber es wird eine andere abstrakte Ressource geben .../Bildschirm? Produkt & Standorte, die beide in einem Aufruf abrufen.

12
mattinsalto

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

  1. jeder einzelne Aufruf ist eine eigene Entität, sodass Sie es einzeln wiederholen können, wenn etwas fehlschlägt. Wenn in der monolithischen "One-Call" -Architektur eines fehlschlägt, müssen Sie den gesamten Anruf erneut ausführen
  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 es ist nicht sinnvoll, einen API-Aufruf mehrere zu laden separate Ressourcen; Wenn Sie beispielsweise /products anfordern, eine Liste der auf einer Seite anzuzeigenden Produkte abzurufen, und eine Liste der Standorte anzeigen möchten, an denen beliebte Produkte verkauft werden, stehen Ihnen zwei separate Ressourcen zur Verfügung: Product und Location. Obwohl sie auf derselben Seite angezeigt werden, können Sie nicht logisch/products aufrufen und auch Speicherorte zurückgeben
  4. ihre Protokollierungs-/Nutzungsberichte werden im modularen Ansatz einfacher. Wenn Sie eine Anfrage an /products stellen und auch 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 beschädigt wird und es für Ihre Benutzer nicht offensichtlich ist was ist kaputt gegangen - und dies bedeutet, dass es länger dauert Ihr Team, um das Problem zu beheben; Wenn jedoch beim modularen Ansatz eines kaputt geht, ist es sehr offensichtlich, was kaputt gegangen ist, und Sie können es schneller beheben. Es wird auch den Rest der Seite nicht 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 5 Ressourcen haben, die von einem API-Aufruf geladen werden, ist es schwieriger herauszufinden wie man Dinge nicht kaputt macht, wenn Sie etwas ändern möchten

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

Die einzige logische Option besteht darin, mehrere asynchrone Anforderungen an separate Ressourcen zu stellen: modularer Ansatz!

PS - Optimieren Sie "Verbindungen zum Server" nicht vorzeitig, insbesondere wenn HTTP-Verbindungen einen unglaublich geringen Overhead aufweisen 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.

14
Chris Cirefice