Viele asynchrone Aufrufe im Vergleich zu einem einzelnen Aufruf der API

12

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.

mattinsalto
quelle

Antworten:

12

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.

Chris Cirefice
quelle
1
Auch modular ist der Komponententest wahrscheinlich einfacher.
user949300
@ user949300 Guter Punkt, daran habe ich gar nicht gedacht! Unit-Tests wären in der Tat viel einfacher, wenn die Dinge entkoppelt wären.
Chris Cirefice
Vielen Dank für die schnelle und ausführliche Antwort. Ich stimme allen zu, aber ich glaube, ich habe es nicht OK erklärt. Es gibt verschiedene Ressourcen / Produkte / Standorte usw. Diese Ressourcen könnten alleine abgerufen werden, aber es gibt eine andere abstrakte Ressource / Bildschirm - Produkte & Standorte, die beide in einem Aufruf abrufen. Auf jeden Fall bevorzuge ich auch den einfacheren Weg.
Mattinsalto
@mattinsalto Der Ansatz von /screen?Product&Locationsist ein schlechter Ansatz, zumindest mit all der Erfahrung, die ich mit der Entwicklung von REST-APIs und einer Web-App gesammelt habe , die sie verwendet hat. Aus einer rein monolithischen Perspektive (z. B. in Ruby on Rails) ist es vollkommen in Ordnung , eine Route zu haben /screen, die beides Productund LocationRessourcen belastet . Aus REST- Sicht sollten Sie jedoch niemals mehr als eine Route laden (es sei denn, Sie verbinden Tabellen, um mehr Daten auf einmal zu erhalten). Was /screentun soll , ist eine grundlegende Layout - Seite laden und Sie AJAX API , die Daten zu erhalten ( Product, Locationusw.).
Chris Cirefice
@mattinsalto Wenn Sie eine REST-API zur Verwendung in einer Web-App (und anderen Dingen) entwickeln, müssen Sie sich nur auf die Daten konzentrieren und weniger darauf, wie Ihre Apps die Daten verwenden werden. Die REST-API sollte grundlegende Vorgänge für jede Ressource unterstützen (je nach Bedarf). Anschließend lädt Ihre Web-App alle Ressourcen, die sie für eine bestimmte Seite benötigt (z. B. /screenAJAX HTTP GETfür /products/popularund /locations). Ihre API sollte nicht diejenige sein, die mehrere Ladevorgänge ausführt, da es unwahrscheinlich ist, dass Sie die Daten in einer Web-App auf dieselbe Weise wie beispielsweise in Android anzeigen.
Chris Cirefice