De beste manieren om verbinding te maken met de server via Angular CLI

Iedereen die Angular CLI heeft gebruikt, weet dat het een krachtig hulpmiddel is dat een front-end ontwikkelingstaak naar een heel ander niveau kan tillen. Het heeft alle gebruikelijke taken zoals live herladen, typografische transpilering, minificatie en meer. En het is allemaal vooraf geconfigureerd en klaar voor gebruik met één eenvoudig commando:

ng build, ng serve, ng test.

Maar er is een (en zeer belangrijke) taak die moet worden geconfigureerd zodra de applicatie klaar is om te beginnen met het weergeven van enkele gegevens van de server ...

Ja, het maakt niet uit hoe geweldig het Angular-framework is en hoe snel en performant de componenten ervan zijn - uiteindelijk is het doel van SPA (applicatie met één pagina) om via HTTP-aanvragen met de server te communiceren.

En hier is het eerste obstakel dat voor elke Angular CLI-newbie verschijnt: het Angular-project draait op zijn eigen server (die standaard wordt uitgevoerd op http: // localhost: 4200). Daarom zijn de aanvragen voor de API-server domeinoverschrijdend en, zoals u wellicht weet, is het niet toegestaan ​​om domeinoverschrijdende aanvragen in te dienen.

Benadering # 1: proxy

Natuurlijk hebben de mensen bij Angular CLI dit probleem voorzien en zelfs een speciale optie gebouwd voor het uitvoeren van een Angular-project met een proxyconfiguratie:

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

Wat is een proxy, vraagt ​​u zich misschien af? Welnu, met browsers kunt u geen domeinoverschrijdende aanvragen doen, maar servers wel. Het gebruik van de proxy-optie betekent dat u de server van Angular CLI vertelt om het verzoek van Angular te verwerken en opnieuw te verzenden vanaf de ontwikkelingsserver. Op deze manier is degene die "praat" met de server van de API de server van Angular CLI.

Voor de proxyconfiguratie moet het bestand proxy.conf.json aan het project worden toegevoegd. Dit is een JSON-bestand met enkele basisinstellingen. Hier is een voorbeeld van de inhoud van proxy.conf:

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

Deze code betekent dat alle verzoeken die beginnen met api / opnieuw worden verzonden naar http: // localhost: 3000 (het adres van de API-server)

Benadering # 2: CORS

Met browserbeveiliging kunt u geen domeinoverschrijdende aanvragen indienen, tenzij de header Control-Allow-Origin bestaat op antwoord van de server. Nadat u uw API-server hebt geconfigureerd om met deze kop ‘‘ antwoord ’te maken, kunt u gegevens uit een ander domein ophalen en plaatsen.

Deze techniek wordt Cross Origin Resource Sharing of CORS genoemd. De meeste gangbare servers en serverframeworks zoals Node.js Express of Java Spring Boot kunnen eenvoudig worden geconfigureerd om CORS beschikbaar te maken.

Hier is een voorbeeldcode waarmee de Node.js Express-server CORS gebruikt:

const cors = vereisen ('cors'); // <- vereist installatie van 'cors' (npm i cors --save)
const express = vereisen ('express');
const app = express ();
app.use (cors ()); // <- Dat is alles, geen code meer nodig!

Merk op dat bij het gebruik van CORS, voordat elk van de HTTP-aanvragen wordt verzonden, deze volgt na het OPTIONS-verzoek (op dezelfde URL) dat controleert of het CORS-protocol wordt begrepen. Dit 'dubbele verzoek' kan uw prestaties beïnvloeden.

Productiebenadering

Oké, uw Angular-project “praat” soepel met de server, krijgt en verzendt gegevens in de ontwikkelaaromgeving. Maar de tijd van implementatie is eindelijk gekomen, en je moet je mooie en preformante Angular-app ergens hosten (ver weg van Papa Angular CLI). Dus opnieuw staat u voor hetzelfde probleem: hoe u verbinding kunt maken met de server.

Alleen nu is er een groot verschil: in de productieomgeving (na het uitvoeren van de opdracht ng build) is de Angular-app niet meer dan een stel HTML- en JavaScript-bestanden.

De beslissing om de applicatie op de productieserver te hosten is eigenlijk een architecturale beslissing, en architectuur valt ver buiten het bestek van dit artikel. Maar er is een optie die ik u aanraad.

Serveer statische bestanden van de API-server

Ja, u kunt uw Angular-project (zodra het alleen HTML- en JavaScript-bestanden heeft) op dezelfde server hosten van waaruit gegevens (API's) worden geleverd.

Een van de voordelen van deze strategie is dat u nu geen "domeinoverschrijdende" problemen ondervindt, aangezien de client en API zich op dezelfde server bevinden!

Natuurlijk vereist deze aanpak dat de server van de API correct wordt geconfigureerd.

Hier is de code die de "openbare" map blootstelt waar Angular-bestanden kunnen worden gehost bij gebruik van de Node Express-server:

app.use (express.static ( 'public')); // <- openbare map die alle hoekbestanden bevat

Houd er rekening mee dat in dit geval de manier waarop uw app toegang krijgt tot de API in de ontwikkelomgeving, anders is dan de manier waarop de API er tijdens de productie toegang toe heeft gekregen. Daarom moet u mogelijk verschillende HTTP-URL's in verschillende omgevingen gebruiken (zoals api / gebruikers / 1 bij dev en gebruikers / 1 bij productie). U kunt de omgevingoptie van Angular CLI gebruiken om dit te bereiken:

// users.service.ts
const URL = 'gebruikers';
retourneer this.http.get (`$ $ environment.baseUrl} / $ {URL}`);
...
// voorbeeld van environment.ts-bestand:
export const environment = {
  productie: vals,
  baseUrl: 'api', // <- 'API /' prefix nodig voor proxyconfiguratie
};
// voorbeeld van het bestand environment.prod.ts:
export const environment = {
  productie: waar,
  baseUrl: '', // <- geen voorvoegsel 'API /' nodig
};

Gevolgtrekking

Angular CLI is zonder twijfel een zeer krachtig en robuust hulpmiddel. Het maakt ons leven als front-end ontwikkelaars op veel manieren eenvoudiger. Maar het vereist ook dat u een architecturale beslissing neemt over de verbinding met de server van de API. Daarom moet u een goed begrip hebben van de verschillende manieren waarop client-servercommunicatie tot stand kan worden gebracht.

Dit artikel bevat twee manieren om dit probleem in de ontwikkelaaromgeving aan te pakken en ook een aanbeveling over productiearchitectuur.
Probeer met verschillende compilaties te spelen en kijk welke het handigst is voor jou en je team.

Veel plezier en laat me weten hoe het gaat!