AngularJS: Serverseitige Architektur

Question

In unserem Intranet haben wir einige End-Service-Plattformen wie BPM, Dokumenten-Management-System, etc. Diese End-Service-Dienste offenbaren REST-API. Wir entwickeln Web-Anwendungen mit AngularJS als Frontend.

Es gibt zwei Möglichkeiten, wie wir von AngualJS zu diesen Endpunktdiensten telefonieren können.

Option 1: Wenn diese Endpunktservices REST verfügbar machen, rufen Sie diese REST-API direkt aus AngualrJS auf.

Option 2: eine mittlere Schicht einführen (auf einem Anwendungsserver wie WebLogic oder Tomcat). Erstellen Sie eine Java-Anwendungsschicht, die die Endpunkt-REST-API aufruft. und hosten Sie es auf dieser millde Schicht. Das AngularJS ruft REST auf, das von dieser mittleren Schicht bereitgestellt wird; Diese mittlere Ebene ruft in den Endpunkt REST auf.

Ich persönlich bevorzuge die Option 1; aber Ich lade Ihre Openion zu diesem Thema ein. Ich habe die Vor- und Nachteile von Option 1 aufgeführt, so wie ich sie sehe.

Vorteile von Option 1:

• Bessere Leistung (Durchsatz) ein weniger Hop für HTTP-Anfragen gegeben.
• Geringere Entwicklungs-/Bereitstellungsbemühungen aufgrund einer Komponente weniger.
• Geringere Anzahl von Fehlerstellen. Wenn es ein Problem gibt, kennen wir es entweder in Angualrs oder im Endservice.

Nachteile von Option 1:

• Sicherheitsfragen? Da bin ich mir nicht sicher - möchte dazu Expertenmeinungen machen.
• CORS: die Enddienste müssen Access-Control-Allow-Origin zu den entsprechenden Domänen aktivieren.
• Schlechte Protokollierung? Wenn etwas schief geht, sind die Protokolle nur auf Benutzerrechnern (IE/Chrome-Entwicklungstool) oder im End-Service verfügbar.
• Zu viel Verarbeitung in AngualJS Schicht? Diese Verarbeitung analysiert hauptsächlich das Ergebnis des End-Service. Dies hängt auch von der Art des verwendeten Endservice ab.

Answer 1

Sie erwähnen "In unserem Firmenintranet". Je nachdem, wie die Endpunkte gesichert sind, könnte Option 1 eine Herausforderung darstellen.

Angular wird in einem Webbrowser ausgeführt. Wenn diese Dienste nur über VPN/Intranet zugänglich sind, funktioniert die Web-App nur, wenn Ihr Computer mit diesem Intranet verbunden ist (dh es funktioniert nicht, wenn Sie es ausführen von zu Hause). Eine weitere Sicherheitsproblematik mit Option 1 besteht darin, dass, wenn die Endpunkte spezielle Authentifizierungs- "Geheimnisse" (API-Tokens, Passwörter, Zertifikate usw.) erfordern, diese Geheimnisse für jeden sichtbar und sichtbar sind, der die Web-App verwendet da jeder den Verkehr zwischen seinem Browser und dem Server sehen kann.Mit Option 2 können diese Geheimnisse hinter der mittleren Ebene verborgen bleiben.

Schließlich, auch wenn Angular direkt mit diesen Endpunkten spricht, müssen Sie das HTML/JS/CSS auf einigen Webservern gehostet haben. Sie benötigen möglicherweise keinen vollständigen Anwendungsserver, aber Sie benötigen etwas, auf das Ihr Webbrowser verweisen kann.

Wenn diese Bedenken nicht auf Ihren Fall zutreffen, dann liegt es wirklich an Ihnen, die Wahl zu treffen, mit der Sie und Ihr Team am bequemsten sind.

Answer 2

Option 2 meiner Meinung nach ist eine bessere Option auf lange Sicht. Dafür gibt es wenige Gründe.

Sicherheit ist in erster Linie, Wenn Sie eine Middleware dazwischen haben, können Sie inhärente Sicherheit haben, was bedeutet, dass Sie nur die REST-APIs verfügbar machen können, die Ihre eckige Webanwendung benötigt. Sie können auch einen Sicherheitsmechanismus wie oAuth verwenden, da Sie die Middleware steuern.

Protokollierung ist eine andere. Sicherlich braucht heutzutage jede Anwendung irgendeine Art von Auditing. Sicherheit und Protokollierung sind Layer vor Ihren eigentlichen REST-Aufrufen.

Sie könnten einige Aspekte zu jeder Schlüssel-REST-API hinzufügen, sodass, falls diese API aufgerufen wird, eine E-Mail ausgelöst wird, es immer praktisch ist, diese Flexibilität zu haben, die wir gerade nicht brauchen.

Sie können die Reaktionstransformation und die Fehlerbehandlung effizient einbeziehen. Sobald Sie die Antwort vom Dienst erhalten, können Sie in Ihrer Middleware die Antwort transformieren, unnötige oder kritische Felder entfernen, einige Werte zaubern usw. Das alles kann auch mit eckigen erfolgen, aber dann ist die echte Antwort oder der Fehler dem Client ausgesetzt.

Auf der negativen Seite haben Sie richtigerweise erwähnt, Leistung ist eine, aber imo halten Sie Ihre REST-Middlware in Einklang mit Diensten REST ist mehr Fluch. Jede neue API, die von Services hinzugefügt wird, muss in die Middleware aufgenommen, neu kompiliert und erneut implementiert werden. Aber es hängt auch davon ab, wie hoch die Wahrscheinlichkeit und Häufigkeit dieser Änderungen ist. für alle diese Änderungen müssen Sie in eckigen Webapps ändern, um es einzuschließen.

Answer 3

Danke für so einen schönen Artikel.

Wenn Sie sich mit Sicherheit befassen und Ihre Projektanforderungen auf Sicherheit konzentrieren. Man muss mit Option 2 gehen.

Wenn Sicherheit keine große Sorge ist. Optionen 2 ist besser.