Best Practices für SPA, die mehrere APIs aufrufen?

Question

Mein Team versucht, die beste Architektur für das Problem unten herauszufinden. Ich würde gern vorhandene Empfehlungen für unsere Situation finden, aber es ist schwierig zu suchen.

• Wir haben eine Anwendung A mit einem SPA, ASP.NET WebAPI Backend und einer Datenbank.

• Wir haben eine andere interne WebAPI B zum Speichern und Versorgen von Dateien und anwendungsunabhängigen Metadaten. B hat eine eigene Datenbank. Diese API gehört ebenfalls zu unserem Team, soll aber letztendlich von anderen Anwendungen genutzt werden.

A hat eine Tabelle von A -spezifische Dokument-Metadaten. Diese Aufzeichnungen repräsentieren Anhänge von Dateien auf andere Dinge in A und enthalten die IDs der Dokumentdatensätze in B

Um Anlagen Liste für einen bestimmten Artikel, A Frontend erhält A Dokument Aufzeichnungen, verwendet das Ergebnis des Rufes zu A den Rest der Metadaten (Dateiname, Größe, etc.) von B

---

Wir hatten eine Idee zu holen um den zweiten Anruf zu eliminieren, indem die von einem Upload an B in A Metadaten zurückgegebenen Daten dupliziert werden.

Also, meine Fragen sind:

1. Gibt es einen Grund, die Daten nicht zu duplizieren?
2. Ich hatte bisher Probleme, es zu googeln - ich habe das Gefühl, dass mir der Jargon oder ein Begriff fehlt, der mir das bringt, was ich brauche. Gibt es einen Namen für dieses spezifische Architekturthema, das mir bei meinen Suchen helfen wird?

Dank

Answer 1

Ich denke, etwas ähnliches zu tun: ein SPA mehr Eigenbesitz und/oder Fremd apis mit dem Potenzial von mehrer Client-SPAs aufrufen.

Um dies zu tun, werde ich eine Proxy-API, die für das Weiterleiten von Anrufen an jede der anderen Apis zum richtigen Zeitpunkt verantwortlich ist.

(der Proxy-API nicht nur ein Proxy ist, weil es seine eigene durchführen kann operations-- es eher wie eine Business-Schicht ist. Nennen Sie es, was Sie wollen.)

Der Kunde nur an den Proxy-api reden und wird keine Kenntnis von der echten Apis haben.

Jede API ist nur für Daten verantwortlich, die für diese API gelten, kann jedoch mit der Proxy-API übereinstimmen, um Daten von anderen APIs zu erhalten, falls erforderlich.

Beispiel: Client C muss Informationen von den APIs A1, A2 und A3 abrufen und/oder speichern. Wir erstellen Proxy-API P. C fragt P nach kombinierten Daten von A1 und A2. P fragt A1 nach Daten und fragt dann A2 nach Daten. P kombiniert die Daten und sendet sie an C. Der Grund, warum P sie kombiniert und nicht C, ist, dass mehrere Clients die gleichen kombinierten Daten benötigen.

Ich würde die Duplizierung von Daten vermeiden, wenn es nicht absolut notwendig ist. Sie können Schlüssel in den Tabellen oder Objekten anderer Datenspeicher ablegen, nicht aber die Daten selbst - sonst sind Sie offen für schmutzige Daten, wenn/wenn es mit der einen oder der anderen der apis zu Problemen kommt.

Die Proxy-API kann bei Bedarf auch für die Autorisierung/Authentifizierung für jede API verantwortlich sein.

Auf diese Weise kann jeder Client mit dem gleichen Proxy-API kommunizieren, und der Client-Code muss nicht geändert werden.

Answer 2

Ich denke, wir von Mikro-Service sprechen kann.

Für Datenduplizierung, die davon abhängt, wie Sie es behandeln möchten. Ihre Daten müssen immer aktuell sein?

Wenn es sich um eine Art von Daten handelt, können Sie die Daten in A Backend duplizieren. Z. B: Eine Zeile in Rechnung

Andernfalls von A Backend Sie B Backend-Rufdaten zu fusionieren und senden Sie Ihren Kunden (Frontend) nur nützliche Informationen.

Ihre Clients müssen nur einen Endpunkt kennen.

Da, wenn Sie 3 Clients haben (z. B. Website, mobile App, Registerkarte App), die die gleiche Funktion haben.Morgen, B Änderungen, müssen Sie Ihren Frontend-Code überall überprüfen.

Wenn dagegen nur A weiß B, ändern Sie die Verbindung in A. Im Allgemeinen ist es transparent für Ihre Kunden

Einige lesen: http://microservices.io/patterns/data/event-sourcing