Svatko tko je koristio Angular CLI zna da je to moćan alat koji napredni razvojni posao može podići na potpuno drugu razinu. Ima sve uobičajene zadatke poput ponovnog učitavanja uživo, prevođenja strojopisa, minifikacije i još mnogo toga. I sve je to unaprijed konfigurirano i spremno za upotrebu pomoću jedne jednostavne naredbe:
ng build, ng serve, ng test.No, postoji jedan (i vrlo važan) zadatak koji treba konfigurirati kada aplikacija bude spremna za početak prikazivanja nekih podataka s poslužitelja ...
Da, bez obzira na to koliko je Angular framework sjajan i koliko su brze i efikasne njegove komponente - na kraju je svrha SPA-a (aplikacija na jednoj stranici) interakcija s poslužiteljem putem HTTP zahtjeva.
I ovdje je prva prepreka koja se pojavljuje pred svakim početnikom Angular CLI-a: projekt Angular izvodi se na vlastitom poslužitelju (koji se prema zadanim postavkama izvodi na // localhost: 4200). Stoga su zahtjevi za API poslužitelj više domena i, kao što možda znate, sigurnost web preglednika onemogućava izradu zahtjeva za više domena.
Pristup br. 1: proxy
Naravno, ljudi iz Angular CLI-a predvidjeli su ovaj problem i čak su izgradili posebnu opciju za pokretanje Angular projekta koristeći proxy konfiguraciju:
ng serve —-proxy-config proxy.conf.jsonŠto je proxy, možete pitati? Pa, preglednici ne dopuštaju upućivanje zahtjeva za više domena, ali poslužitelji to dopuštaju. Upotreba opcije proxy znači da poručujete poslužitelju Angular CLI-a da obrađuje zahtjev poslan od Angular-a i pošalje ga s razvojnog poslužitelja. Na taj je način onaj koji "razgovara" s API-jevim poslužiteljem poslužitelj Angular CLI-a.
Konfiguracija proxyja zahtijeva proxy.conf.jsondatoteka koja se dodaje projektu. Ovo je JSON datoteka s nekim osnovnim postavkama. Evo primjera sadržaja proxy.conf :
{ "/api/*": { "target": "//localhost:3000", "secure": false, "pathRewrite": {"^/api" : ""} }}Ovaj kôd znači da će svi zahtjevi koji započinju s api / biti ponovno poslani // localhost: 3000(koja je adresa API poslužitelja)
Pristup br. 2: CORS
Sigurnost preglednika ne dopušta vam slanje zahtjeva za više domena, osim ako Control-Allow-Originzaglavlje ne postoji na odgovor poslužitelja. Nakon što konfigurirate svoj API poslužitelj da '' odgovara '' s ovim zaglavljem, možete dohvaćati i objavljivati podatke s druge domene.
Ova se tehnika naziva Cross Origin Resource Sharing (CORS). Većina uobičajenih poslužitelja i poslužiteljskih okvira poput Node.js 'Express ili Java Spring Boot mogu se lako konfigurirati tako da CORS budu dostupni.
Evo nekoliko primjera koda koji postavlja poslužitelj Node.js Express da koristi 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!Imajte na umu da će prilikom korištenja CORS-a prije slanja svakog HTTP zahtjeva slijediti nakon zahtjeva OPTIONS (na istom URL-u) koji provjerava razumije li se CORS protokol. Ovaj "dvostruki zahtjev" može utjecati na vašu izvedbu.
Proizvodni pristup
Ok, vaš Angular projekt glatko "razgovara" sa poslužiteljem, prima i šalje podatke u razvojnom okruženju. No, vrijeme uvođenja napokon je došlo i trebate da vaša lijepa i preformantna Angular aplikacija bude negdje hostirana (daleko od Papa Angular CLI). Dakle, opet se suočavate s istim problemom: kako napraviti vezu za poslužitelj.
Tek sada postoji velika razlika: u proizvodnom okruženju (nakon pokretanja ng buildnaredbe) aplikacija Angular nije više od hrpe HTML i JavaScript datoteka.
Zapravo je odluka o načinu hostiranja aplikacije na produkcijskom poslužitelju arhitektonska odluka, a arhitektura je daleko izvan dosega ovog članka. Ali postoji jedna opcija koju preporučujem da uzmete u obzir.
Poslužite statične datoteke s API-jevog poslužitelja
Da, svoj Angular projekt možete smjestiti (kada ima samo HTML i JavaScript datoteke) na istom poslužitelju odakle se poslužuju podaci (API-ji).
Jedna od prednosti ove strategije je što se sada ne suočavate s problemima s "više domena", jer su klijent i API zapravo na istom poslužitelju!
Naravno, ovaj pristup zahtijeva da API poslužitelj bude pravilno konfiguriran.
Evo koda koji izlaže "javni" direktorij u kojem se mogu hostirati Angular datoteke kada se koristi Node Express poslužitelj:
app.use(express.static('public')); //<-- public directory that contains all angular filesImajte na umu da će se u ovom slučaju način na koji vaša aplikacija pristupa API-ju u razvojnom okruženju razlikovati od načina na koji je API pristupio njemu u proizvodnji. Stoga ćete možda trebati koristiti različite HTTP URL-ove u različitim okruženjima (poput api / users / 1 na dev-u i users / 1 na produkciji). Da biste to postigli, možete koristiti opciju okruženja Angular CLI:
// users.service.tsconst 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};Zaključak
Kutni CLI bez sumnje je vrlo moćan i robustan alat. To nam na mnogo načina olakšava život razvojnih programera. Ali također zahtijeva da donesete arhitektonsku odluku o povezanosti s API poslužiteljem. Stoga vam je potrebno jasno razumijevanje različitih načina na koje se komunikacija klijent-poslužitelj može uspostaviti.
U ovom su članku navedena dva pristupa rješavanju ovog problema u razvojnom okruženju i jedna preporuka o proizvodnoj arhitekturi.
Pokušajte se igrati s raznim kompilacijama i pogledajte koja se vama više sviđa i vama i vašem timu.
Zabavite se i javite mi kako to ide!