A szerverhez való csatlakozás legjobb módjai az Angular CLI használatával

Mindenki, aki használta az Angular CLI-t, tudja, hogy ez egy hatékony eszköz, amely egy front-end fejlesztői munkát egészen más szintre emelhet. Minden olyan általános feladata van, mint az élő újratöltés, a gépírási transzponálás, a tömörítés és még sok más. És mindez előre konfigurált és használatra kész egy egyszerű paranccsal:

ng build, ng serve, ng test.

De van egy (és egy nagyon fontos) feladat, amelyet konfigurálni kell, amint az alkalmazás készen áll arra, hogy elkezdjen mutatni néhány adatot a szerverről ...

Igen, függetlenül attól, hogy az Angular keretrendszer milyen nagyszerű, és milyen gyorsan és hatékonyan működnek az összetevői - a végén az SPA (egyoldalas alkalmazás) célja a szerverrel való kapcsolattartás HTTP-kérelmeken keresztül.

És itt van az első akadály, amely minden Angular CLI újonc előtt megjelenik: az Angular projekt a saját szerverén fut (amely alapértelmezés szerint a // localhost: 4200 címen fut). Ezért az API-kiszolgálóhoz intézett kérések tartományokon átívelőek , és, mint azt Ön is tudja, a webböngésző biztonsága tiltja a tartományok közötti kérelmek benyújtását.

1. megközelítés: proxy

Természetesen az Angular CLI munkatársai előre látták ezt a problémát, és még egy speciális lehetőséget is létrehoztak egy Angular projekt futtatásához proxy konfiguráció segítségével:

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

Mi lehet a proxy, megkérdezheti? Nos, a böngészők nem engedélyezik domainek közötti kérelmek benyújtását, de a szerverek igen. A proxy opció használata azt jelenti, hogy azt mondja az Angular CLI szerverének, hogy kezelje az Angular által küldött kérést, és küldje el újra a fejlesztői kiszolgálóról. Így az API szerverével „beszélő” az Angular CLI szervere.

A proxy konfigurálásához a proxy.conf.json szükségesfájl hozzáadása a projekthez. Ez egy JSON fájl néhány alapvető beállítással. Íme egy példa a proxy.conf tartalmára :

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

Ez a kód azt jelenti, hogy az api / betűvel kezdődő összes kérést a // localhost: 3000 címre küldjük(amely az API szerver címe)

2. megközelítés: CORS

A böngésző biztonsága nem teszi lehetővé tartományok közötti kérelmek benyújtását, hacsak a Control-Allow-Originfejléc nem szerepel a szerver válaszában. Miután konfigurálta az API-kiszolgálót erre a fejlécre, hogy válaszoljon, lekérheti és közzéteheti az adatokat egy másik tartományból.

Ezt a technikát Cross Origin Resource Sharing (CORS) néven hívják. A legtöbb általános szerver és szerver keretrendszer, például a Node.js 'Express vagy a Java Spring Boot könnyen konfigurálható a CORS elérhetővé tétele érdekében.

Íme néhány példa kód, amely beállítja a Node.js Express kiszolgálót a CORS használatára:

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!

Ne feledje, hogy a CORS használatakor az egyes HTTP-kérelmek elküldése előtt az OPTIONS kérés után (ugyanazon az URL-en) következik, hogy ellenőrizze-e a CORS protokoll megértését. Ez a „kettős kérés” befolyásolhatja teljesítményét.

Termelési megközelítés

Ok, az Ön Angular projektje simán „beszél” a szerverrel, adatokat kap és küld a fejlesztői környezetben. De végre eljött a telepítés ideje, és szüksége van a gyönyörű és előformázott Angular alkalmazásra, amelyet valahol (a Papa Angular CLI-től távol) tárolhat. Tehát ismét ugyanazzal a problémával kell szembenéznie: hogyan lehet csatlakozni a szerverhez.

Csak most van egy nagy különbség: a termelési környezetben (a ng buildparancs futtatása után ) az Angular alkalmazás nem több, mint egy csomó HTML és JavaScript fájl.

Valójában az alkalmazás gyártási kiszolgálón történő tárolásának módja építészeti döntés, és az architektúra messze meghaladja a cikk kereteit. De van egy lehetőség, amelyet ajánlom megfontolni.

Statikus fájlok kiszolgálása az API szerveréről

Igen, az Angular projektet (ha csak HTML- és JavaScript-fájljai vannak) ugyanazon a kiszolgálón tárolhatja, ahonnan az adatokat (API-k) szolgáltatják.

Ennek a stratégiának az egyik előnye, hogy most nem merül fel „domainek közötti” probléma, mivel az ügyfél és az API valójában ugyanazon a szerveren vannak!

Természetesen ehhez a megközelítéshez az API szerverének megfelelő konfigurálása szükséges.

Ez a kód a „nyilvános” könyvtárat tárja fel, ahol a szögletes fájlok tárolhatók a Node Express kiszolgáló használatakor:

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

Vegye figyelembe, hogy ebben az esetben az alkalmazás hozzáférési módja az API-hoz a fejlesztői környezetben különbözik attól, ahogyan az API a gyártás során elérte azt. Ezért előfordulhat, hogy különböző HTTP URL-eket kell használnia különböző környezetekben (például az api / users / 1 a dev-nél és a users / 1 a termelésnél). Ennek eléréséhez használhatja az Angular CLI környezeti opcióját:

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

Következtetés

A szögletes CLI kétségkívül nagyon hatékony és robusztus eszköz. Ez sok szempontból megkönnyíti az életünket a front end fejlesztőként. De ez építészeti döntést is megkövetel az API szerveréhez való kapcsolódásról. Ezért tisztában kell lennie az ügyfél-szerver kommunikáció különböző módjaival.

Ez a cikk két megközelítést sorol fel a probléma kezeléséhez a fejlesztői környezetben, valamint egy ajánlást a gyártási architektúrára vonatkozóan.

Próbálj meg különféle összeállításokkal játszani, és nézd meg, melyik érzi magát kényelmesebbnek az Ön és csapata számára.

Jó szórakozást, és tudassa velem, hogy megy!