Vorteile der Verwendung separater API- und UI-Server für Webanwendungen

Bei der Arbeit haben wir eine große interne Anwendung, die seit fast zwei Jahren entwickelt wird. Ich bin erst kürzlich dem Projekt beigetreten und ein Teil der Architektur hat mich ein wenig ratlos gemacht. Deshalb hoffe ich, dass hier jemand einen Rat geben kann, bevor ich den Architekten dieselben Fragen stelle (damit ich ein fundiertes Gespräch mit ihnen führen kann) ).

Ich entschuldige mich, wenn das Folgende etwas lang ist, ich möchte nur versuchen, ein gutes Bild von dem System zu zeichnen, bevor ich meine Frage stelle :)

• Das System ist so eingerichtet, dass wir eine Hauptwebanwendung (asp.net, AngularJS) haben, die meist nur Daten von verschiedenen anderen Diensten aggregiert. Im Grunde ist es ein Host für eine AngularJS-Anwendung. Es gibt buchstäblich einen MVC-Controller, der die Clientseite bootet, und dann ist jeder andere Controller ein WebAPI-Controller.

• Anrufe von der Clientseite werden von diesen Controllern verarbeitet, die immer für Boxen bereitgestellt werden, die nur die Webanwendung hosten. Wir haben derzeit 4 solcher Boxen.

• Die Anrufe werden dann jedoch letztendlich an eine weitere Gruppe von WebAPI-Anwendungen weitergeleitet (in der Regel pro Geschäftsbereich, z. B. Sicherheit, Kundendaten, Produktdaten usw.). Alle diese WebAPIs werden auch zusammen auf dedizierten Boxen bereitgestellt. Wir haben auch 4 dieser Boxen.

• Mit einer einzigen Ausnahme werden diese WebAPIs von keinem anderen Teil unserer Organisation verwendet.

• Schließlich rufen diese WebAPIs erneut die "Back-End" -Dienste auf, bei denen es sich in der Regel um ältere asmx- oder wcf-Dienste handelt, die über verschiedene ERP-Systeme und Datenspeicher (auf die wir keinen Einfluss haben) verteilt sind.

• Der größte Teil der Geschäftslogik unserer Anwendung befindet sich in diesen WebApis, z. B. das Transformieren von Altdaten, das Aggregieren, das Ausführen von Geschäftsregeln, die übliche Art von Dingen.

Was mich verwirrt hat, ist der mögliche Nutzen einer solchen Trennung zwischen der WebApplication und den dazugehörigen WebAPIs. Da sie von niemand anderem verwendet werden, sehe ich keinen Vorteil in Bezug auf die Skalierbarkeit (dh es macht keinen Sinn, weitere 4 API-Boxen einzubauen, um die erhöhte Auslastung der API-Server zu bewältigen, da eine erhöhte Auslastung der Webserver bedeuten muss - daher muss das Verhältnis von Webserver zu Api-Server 1: 1 sein)

• Ich sehe auch überhaupt keinen Vorteil darin, einen zusätzlichen HTTP-Aufruf durchführen zu müssen. Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Backend-Dienste. (dieser HTTP-Aufruf zwischen WebApp und WebAPI ist mein Problem)

• Daher bin ich derzeit bestrebt, die aktuellen WebAPIs von separaten Lösungen auf nur separate Projekte innerhalb der WebApplication-Lösung mit einfachen Projektreferenzen dazwischen und einem einzelnen Bereitstellungsmodell zu verschieben. Sie würden also letztendlich nur zu Klassenbibliotheken.

• In Bezug auf die Bereitstellung bedeutet dies, dass wir im Gegensatz zu 4 + 4 8 Webboxen mit "vollem Stapel" hätten.

Die Vorteile des neuen Ansatzes sind:

• Leistungssteigerung, da zwischen der Webanwendung und den WebAPI-Servern ein Zyklus weniger Serialisierung / Deserialisierung stattfindet
• Tonnenweise Code, der im Hinblick auf DTOs und Mapper an den ausgehenden und eingehenden Grenzen der Webanwendungs- bzw. WebApi-Server gelöscht werden kann (dh keine Wartung / Prüfung erforderlich ist).
• Bessere Fähigkeit, aussagekräftige automatisierte Integrationstests zu erstellen, da ich einfach die Back-End-Services verspotten und die Unordnung bei den HTTP-Sprüngen der mittleren Ebene vermeiden kann.

Die Frage ist also: irre ich mich? Habe ich eine fundamentale "Magie" der Trennung von WebApplication- und WebAPI-Boxen verpasst?

Ich habe einige N-Tier-Architekturmaterialien recherchiert, kann aber anscheinend nichts darin finden, was einen konkreten Vorteil für unsere Situation bietet (da Skalierbarkeit, soweit ich das beurteilen kann, kein Problem darstellt und dies eine interne App ist) Sicherheit in Bezug auf die WebAPI-Anwendungen ist kein Problem.)

Und was würde ich in Bezug auf die Vorteile verlieren, wenn ich das System zu meinem vorgeschlagenen Setup umstrukturieren würde?

Ein Grund ist die Sicherheit - wenn (haha! Wann ) ein Hacker Zugriff auf Ihren Front-End-Webserver erhält, erhält er Zugriff auf alles, worauf er Zugriff hat. Wenn Sie Ihre mittlere Schicht auf dem Webserver abgelegt haben, hat er Zugriff auf alles, was sie hat - dh auf Ihre Datenbank. Als nächstes führt er "select * from users" in Ihrer Datenbank aus und entfernt sie aus dem Offlinemodus Passwort knacken.

Ein weiterer Grund ist die Skalierung - die Webebene, in der die Seiten erstellt und zerlegt und XML verarbeitet werden. All dies beansprucht viel mehr Ressourcen als die mittlere Ebene, die häufig eine effiziente Methode ist, um Daten von der Datenbank in die Webebene zu übertragen. Ganz zu schweigen von der Übertragung aller statischen Daten, die sich auf dem Webserver befinden (oder zwischengespeichert sind). Das Hinzufügen weiterer Webserver ist eine einfache Aufgabe, sobald Sie die erste Stufe hinter sich haben. Es sollte kein 1: 1-Verhältnis zwischen Web- und Logikebenen geben - ich habe bereits 8: 1 gesehen (und ein 4: 1-Verhältnis zwischen Logik Tier und DB). Es hängt jedoch davon ab, was Ihre Ebenen tun und wie viel Caching in ihnen vor sich geht.

Websites interessieren sich nicht wirklich für die Leistung von Einzelbenutzern, da sie maßstabsgetreu aufgebaut sind. Es spielt keine Rolle, dass ein zusätzlicher Anruf die Leistung ein wenig verlangsamt, wenn Sie mehr Benutzer bedienen können.

Ein weiterer Grund, warum es gut sein kann, diese Ebenen zu haben, ist, dass sie mehr Disziplin in der Entwicklung erfordern, wenn eine API entwickelt (und als eigenständige API leicht getestet wird) und dann die Benutzeroberfläche entwickelt wird, um sie zu nutzen. Ich habe an einem Ort gearbeitet, an dem dies geschah - verschiedene Teams haben unterschiedliche Ebenen entwickelt, und es hat gut funktioniert, da sie Spezialisten für jede Ebene hatten, die Änderungen sehr schnell durchführen konnten, weil sie sich nicht um die anderen Ebenen kümmern mussten - dh einen JAVScript-Entwickler für die Benutzeroberfläche Sie können der Site einen neuen Abschnitt hinzufügen, indem Sie einfach einen neuen Webservice nutzen, den eine andere Person entwickelt hat.

Ich denke, hier gibt es keine richtige / falsche Antwort. Haben Sie Ihre Kollegen nach dem Zweck dieser Architektur gefragt?

Soweit ich Ihre Beschreibungen verstehe, dient das " WebAPI " in Ihrer Architektur als selbst erstellte Middleware. Jetzt können Sie untersuchen, welche Vorteile die Verwendung einer Middleware bietet. Grundsätzlich müsste Ihre Webapp nie angepasst werden, wenn Sie Ihr Backoffice-System geändert haben (solange die WebAPI- Oberfläche dieselbe bleibt).

Um fortzufahren: Stellen Sie sich vor, Sie haben eine Kundendatenbank (Back-End-Service) und Sie haben 5 Web-Apps, die mit dieser Datenbank kommunizieren. Wenn Sie das Kundendatenbanksystem durch ein neues System ersetzen (wie von einem anderen Anbieter, und Sie können die Webservice-Schnittstellen nicht beeinflussen), müssen Sie höchstwahrscheinlich die Kommunikationsschicht aller 5 Webanwendungen ändern. Wenn Sie über Ihr WebAPI kommunizieren , müssen Sie nur die Kommunikationsschicht des WebAPI ändern .

Grundsätzlich wird Layer-Architektur heutzutage sowohl als Muster als auch als Anti-Muster betrachtet. (Siehe: Lasagne-Code ) Wenn Sie nur ein System haben, das in den nächsten Jahren nicht weiter ausgebaut werden soll, würde ich dies eher als Anti-Pattern betrachten. Aber dies wird ein unrealistisch taff Richter sein, da ich die genauen Umstände / Situation nicht kenne :)