Die besten Möglichkeiten, über Angular CLI eine Verbindung zum Server herzustellen

Jeder, der Angular CLI verwendet hat, weiß, dass es sich um ein leistungsstarkes Tool handelt, mit dem ein Front-End-Entwicklungsjob auf ein völlig anderes Niveau gebracht werden kann. Es hat alle gängigen Aufgaben wie Live-Reload, Transpiling von Typoskripten, Minimierung und mehr. Und alles ist vorkonfiguriert und mit einem einfachen Befehl einsatzbereit:

ng build, ng serve, ng test.

Es gibt jedoch eine (und eine sehr wichtige) Aufgabe, die konfiguriert werden muss, sobald die Anwendung bereit ist, einige Daten vom Server anzuzeigen.

Ja, egal wie großartig das Angular-Framework ist und wie schnell und leistungsfähig seine Komponenten sind - am Ende besteht der Zweck von SPA (Single Page Application) darin, über HTTP-Anforderungen mit dem Server zu interagieren.

Und hier ist das erste Hindernis, das vor jedem Angular CLI-Neuling auftritt: Das Angular-Projekt wird auf einem eigenen Server ausgeführt (der standardmäßig unter // localhost: 4200 ausgeführt wird). Daher sind die Anforderungen an den API-Server domänenübergreifend , und wie Sie vielleicht wissen, verbietet die Sicherheit des Webbrowsers das Erstellen domänenübergreifender Anforderungen.

Ansatz 1: Proxy

Natürlich haben die Mitarbeiter von Angular CLI dieses Problem vorausgesehen und sogar eine spezielle Option zum Ausführen eines Angular-Projekts mithilfe einer Proxy-Konfiguration erstellt:

ng serve —-proxy-config proxy.conf.json

Was ist ein Proxy? In Browsern können Sie keine domänenübergreifenden Anfragen stellen, in Servern jedoch. Die Verwendung der Proxy-Option bedeutet, dass Sie den Angular CLI-Server anweisen, die von Angular gesendete Anforderung zu verarbeiten und sie erneut vom Entwicklungsserver zu senden. Auf diese Weise ist derjenige, der mit dem Server der API „spricht“, der Server von Angular CLI.

Die Proxy-Konfiguration erfordert die Datei proxy.conf.jsonDatei, die dem Projekt hinzugefügt werden soll. Dies ist eine JSON-Datei mit einigen Grundeinstellungen. Hier ist ein Beispiel für den Inhalt von proxy.conf :

{ "/api/*": { "target": "//localhost:3000", "secure": false, "pathRewrite": {"^/api" : ""} }}

Dieser Code bedeutet, dass alle Anforderungen, die mit api / beginnen , an // localhost: 3000 erneut gesendet werden(Dies ist die Adresse des API-Servers.)

Ansatz 2: CORS

Mit der Browsersicherheit können Sie keine domänenübergreifenden Anforderungen stellen, es sei denn, der Control-Allow-OriginHeader ist bei der Antwort des Servers vorhanden. Sobald Sie Ihren API-Server so konfiguriert haben, dass er mit diesem Header antwortet, können Sie Daten aus einer anderen Domäne abrufen und veröffentlichen.

Diese Technik wird als Cross Origin Resource Sharing oder CORS bezeichnet. Die meisten gängigen Server und Server-Frameworks wie Node.js 'Express oder Java Spring Boot können einfach konfiguriert werden, um CORS verfügbar zu machen.

Hier ist ein Beispielcode, mit dem der Node.js Express-Server CORS verwendet:

const cors = require('cors'); //<-- required installing 'cors' (npm i cors --save)const express = require('express');const app = express();app.use(cors()); //<-- That`s it, no more code needed!

Beachten Sie, dass bei Verwendung von CORS vor dem Senden jeder HTTP-Anforderung nach der OPTIONS-Anforderung (unter derselben URL) geprüft wird, ob das CORS- Protokoll verstanden wird. Diese „doppelte Anforderung“ kann Ihre Leistung beeinträchtigen.

Produktionsansatz

Ok, Ihr Angular-Projekt „spricht“ reibungslos mit dem Server und ruft Daten in der Entwicklerumgebung ab und sendet sie. Aber die Zeit der Bereitstellung ist endlich gekommen und Sie müssen Ihre schöne und vorformende Angular-App irgendwo hosten (weit weg von Papa Angular CLI). Sie haben also wieder das gleiche Problem: Wie stellen Sie eine Verbindung zum Server her?

Erst jetzt gibt es einen großen Unterschied: In der Produktionsumgebung (nach dem Ausführen des ng buildBefehls) besteht die Angular-App nur aus einer Reihe von HTML- und JavaScript-Dateien.

Tatsächlich ist die Entscheidung, wie die Anwendung auf dem Produktionsserver gehostet werden soll, eine architektonische Entscheidung, und die Architektur geht weit über den Rahmen dieses Artikels hinaus. Ich empfehle jedoch, eine Option in Betracht zu ziehen.

Statische Dateien vom Server der API bereitstellen

Ja, Sie können Ihr Angular-Projekt (sobald es nur HTML- und JavaScript-Dateien enthält) auf demselben Server hosten, von dem aus Daten (APIs) bereitgestellt werden.

Einer der Vorteile dieser Strategie besteht darin, dass Sie jetzt keine domänenübergreifenden Probleme mehr haben, da sich Client und API tatsächlich auf demselben Server befinden!

Für diesen Ansatz muss der Server der API natürlich ordnungsgemäß konfiguriert sein.

Hier ist der Code, der das "öffentliche" Verzeichnis verfügbar macht, in dem Angular-Dateien bei Verwendung des Node Express-Servers gehostet werden können:

app.use(express.static('public')); //<-- public directory that contains all angular files

Beachten Sie, dass sich in diesem Fall die Art und Weise, wie Ihre App in der Entwicklungsumgebung auf die API zugreift, von der Art und Weise unterscheidet, wie die API in der Produktion darauf zugegriffen hat. Daher müssen Sie möglicherweise unterschiedliche HTTP-URLs in unterschiedlichen Umgebungen verwenden (z. B. api / users / 1 bei dev und users / 1 bei der Produktion). Sie können die Umgebungsoption von Angular CLI verwenden, um dies zu erreichen:

// users.service.ts
const URL = 'users';return this.http.get(`${environment.baseUrl}/${URL}`);...
// example of environment.ts file:export const environment = { production: false, baseUrl: 'api',//<-- 'API/' prefix needed for proxy configuration };
// example of environment.prod.ts file:export const environment = { production: true, baseUrl: '', //<-- no 'API/' prefix needed};

Fazit

Angular CLI ist ohne Zweifel ein sehr leistungsfähiges und robustes Werkzeug. Es erleichtert unser Leben als Front-End-Entwickler in vielerlei Hinsicht. Sie müssen jedoch auch eine architektonische Entscheidung über die Verbindung zum API-Server treffen. Daher benötigen Sie ein klares Verständnis der verschiedenen Möglichkeiten, wie eine Client-Server-Kommunikation hergestellt werden kann.

In diesem Artikel werden zwei Ansätze zur Behandlung dieses Problems in der Entwicklerumgebung sowie eine Empfehlung zur Produktionsarchitektur aufgeführt.

Versuchen Sie, mit verschiedenen Zusammenstellungen zu spielen und herauszufinden, welche für Sie und Ihr Team bequemer ist.

Viel Spaß und lass mich wissen, wie es geht!