De bedste måder at oprette forbindelse til serveren ved hjælp af Angular CLI

Alle, der har brugt Angular CLI, ved, at det er et kraftfuldt værktøj, der kan tage et front-end-udviklingsjob til et helt andet niveau. Det har alle de almindelige opgaver som live genindlæsning, typeskrift transpiling, minificering og mere. Og det hele er forudkonfigureret og klar til brug med en enkelt kommando:

ng build, ng serve, ng test.

Men der er en (og en meget vigtig) opgave, der skal konfigureres, når applikationen er klar til at vise nogle data fra serveren ...

Ja, uanset hvor stor Angular-rammen er, og hvor hurtigt og effektiv dens komponenter er - i slutningen er formålet med SPA (enkeltsidesapplikation) at interagere med serveren via HTTP-anmodninger.

Og her er den første hindring, der vises før hver Angular CLI-nybegynder: Angular-projektet kører på sin egen server (som kører som standard på // localhost: 4200). Derfor er anmodningerne til API-serveren på tværs af domæner , og som du måske ved, er sikkerheden i webbrowseren ikke tilladt at foretage anmodninger på tværs af domæner.

Tilgang # 1: proxy

Naturligvis forudså folk på Angular CLI dette problem og byggede endda en særlig mulighed for at køre et Angular-projekt ved hjælp af en proxy-konfiguration:

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

Hvad er en proxy, kan du spørge? Nå, browsere tillader dig ikke at stille anmodninger på tværs af domæner, men servere gør det. Brug af proxy-indstillingen betyder, at du beder Angular CLI's server om at håndtere den anmodning, der sendes fra Angular, og sende den igen fra udviklingsserveren. På denne måde er den, der “taler” med API-serveren Angular CLI's server.

Proxy-konfigurationen kræver proxy.conf.jsonfil, der skal føjes til projektet. Dette er en JSON-fil med nogle grundlæggende indstillinger. Her er et eksempel på indholdet af proxy.conf :

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

Denne kode betyder, at alle anmodninger, der starter med api / , sendes igen til // localhost: 3000(som er API-serverens adresse)

Tilgang # 2: CORS

Browsersikkerhed giver dig ikke mulighed for at foretage anmodninger på tværs af domæner, medmindre Control-Allow-Originoverskriften findes på serverens svar. Når du har konfigureret din API-server til at '' svare '' med denne overskrift, kan du hente og sende data fra et andet domæne.

Denne teknik kaldes Cross Origin Resource Sharing eller CORS. De fleste af de almindelige servere og serverrammer som Node.js 'Express eller Java Spring Boot kan let konfigureres til at gøre CORS tilgængelig.

Her er nogle eksempler på kode, der indstiller Node.js Express-serveren til at bruge CORS:

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!

Bemærk, at når du bruger CORS, før hver af HTTP-anmodningerne sendes, vil det følge efter OPTIONS-anmodningen (på samme URL), der kontrollerer, om CORS- protokollen forstås. Denne "dobbelte anmodning" kan påvirke din præstation.

Produktionsmetode

Ok, dit Angular-projekt "taler" problemfrit med serveren, får og sender data i udviklermiljøet. Men implementeringstidspunktet er endelig kommet, og du har brug for din smukke og præformante Angular-app, der skal hostes et eller andet sted (langt væk fra Papa Angular CLI). Så igen står du over for det samme problem: hvordan man får det til at oprette forbindelse til serveren.

Først nu er der en stor forskel: i produktionsmiljøet (efter ng buildkommandokørsel) er Angular-appen ikke mere end en masse HTML- og JavaScript-filer.

Faktisk er beslutningen om, hvordan applikationen skal hostes på produktionsserveren, en arkitektonisk beslutning, og arkitektur ligger langt uden for denne artikels anvendelsesområde. Men der er en mulighed, jeg anbefaler, at du overvejer.

Server statiske filer fra API's server

Ja, du kan være vært for dit Angular-projekt (når det kun har HTML- og JavaScript-filer) på den samme server, hvor data (API'er) serveres fra.

En af fordelene ved denne strategi er, at du nu ikke står over for problemer på tværs af domæner, da klienten og API faktisk er på samme server!

Selvfølgelig kræver denne tilgang, at API-serveren skal konfigureres korrekt.

Her er koden, der udsætter den "offentlige" mappe, hvor kantede filer kan hostes, når du bruger Node Express-serveren:

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

Bemærk, at i dette tilfælde vil den måde, din app har adgang til API'et på i udviklingsmiljøet, være forskellig fra den måde, API'en fik adgang til ved produktion. Således er du muligvis nødt til at bruge forskellige HTTP-URL'er i forskellige miljøer (som api / brugere / 1 hos dev og brugere / 1 ved produktion). Du kan bruge Angular CLIs miljømulighed for at opnå dette:

// 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};

Konklusion

Vinklet CLI er uden tvivl et meget kraftfuldt og robust værktøj. Det gør vores liv som frontend-udviklere lettere på mange måder. Men det kræver også, at du træffer en arkitektonisk beslutning om forbindelsen til API's server. Derfor har du brug for en klar forståelse af de forskellige måder, klient-server kommunikation kan etableres på.

Denne artikel viser to tilgange til håndtering af dette problem i udviklermiljøet og også en anbefaling om produktionsarkitektur.

Prøv at lege med forskellige samlinger og se, hvilken der føles mere praktisk for dig og dit team.

Hav det sjovt og lad mig vide, hvordan det går!