Найкращі способи підключення до сервера за допомогою Angular CLI

Кожен, хто використовував Angular CLI, знає, що це потужний інструмент, який може вивести роботу з інтерфейсної розробки на зовсім інший рівень. У ньому є всі загальні завдання, такі як перезавантаження в реальному часі, транслірування машинопису, мініфікація тощо. І все це попередньо налаштовано та готово до використання за допомогою однієї простої команди:

ng build, ng serve, ng test.

Але є одне (і дуже важливе) завдання, яке потрібно налаштувати, як тільки додаток буде готовий до запуску показу деяких даних із сервера ...

Так, якою б великою не була структура Angular та наскільки швидко та швидко працювали її компоненти - зрештою, мета SPA (односторінковий додаток) полягає у взаємодії з сервером через HTTP-запити.

І ось перша перешкода, яка виникає перед кожним початківцем Angular CLI: проект Angular працює на власному сервері (який за замовчуванням працює на // localhost: 4200). Отже, запити до сервера API є міждоменними , і, як вам може знати, безпека веб-браузера забороняє робити міждоменні запити.

Підхід №1: проксі

Звичайно, люди в Angular CLI передбачили цю проблему і навіть створили спеціальну опцію для запуску проекту Angular з використанням конфігурації проксі:

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

Ви можете запитати, що таке проксі? Ну, браузери не дозволяють робити міждоменні запити, але сервери дозволяють. Використання параметра proxy означає, що ви говорите серверу Angular CLI обробляти запит, надісланий з Angular, і повторно відправляти його із сервера розробки. Таким чином, той, хто “розмовляє” із сервером API, є сервером Angular CLI.

Для конфігурації проксі потрібен файл proxy.conf.jsonфайл, який потрібно додати до проекту. Це файл JSON з деякими основними налаштуваннями. Ось приклад вмісту proxy.conf :

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

Цей код означає, що всі запити, що починаються з api /, будуть повторно надіслані // localhost: 3000(що є адресою сервера API)

Підхід №2: CORS

Захист браузера не дозволяє робити міждоменні запити, якщо Control-Allow-Originзаголовок не існує у відповіді сервера. Після того, як ви налаштували свій сервер API на відповідь цим заголовком, ви можете отримувати та публікувати дані з іншого домену.

Цей прийом називається Cross Origin Resource Sharing (CORS). Більшість поширених серверів та серверних фреймворків, таких як Node.js 'Express або Java Spring Boot, можна легко налаштувати, щоб зробити доступними CORS.

Ось приклад коду, який встановлює сервер Node.js Express на використання 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!

Зауважте, що при використанні CORS перед тим, як відправляти кожен із HTTP-запитів, після запиту OPTIONS (за тією самою URL-адресою) він перевіряє, чи зрозумілий протокол CORS . Цей "подвійний запит" може вплинути на вашу ефективність.

Виробничий підхід

Гаразд, ваш Angular-проект безперешкодно «розмовляє» із сервером, отримує та надсилає дані у середовищі розробника. Але час розгортання нарешті настав, і вам потрібно, щоб ваш красивий і продуктивний додаток Angular був десь розміщений (далеко від Papa Angular CLI). Отже, ви знову стикаєтесь з тією ж проблемою: як зробити так, щоб він підключився до сервера.

Тільки зараз є велика різниця: у виробничому середовищі (після запуску ng buildкоманди) програма Angular містить не більше ніж HTML-файли та файли JavaScript.

Насправді рішення про розміщення програми на виробничому сервері є архітектурним рішенням, і архітектура далеко не виходить за рамки цієї статті. Але є один варіант, який я рекомендую вам розглянути.

Обслуговувати статичні файли з сервера API

Так, ви можете розмістити свій проект Angular (коли він має лише файли HTML та JavaScript) на тому самому сервері, звідки подаються дані (API).

Однією з переваг цієї стратегії є те, що тепер ви не стикаєтесь з проблемами «міждоменного», оскільки клієнт та API фактично знаходяться на одному сервері!

Звичайно, такий підхід вимагає належного налаштування сервера API.

Ось код, який відкриває “загальнодоступний” каталог, де можуть розміщуватися файли Angular при використанні сервера Node Express:

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

Зверніть увагу, що в цьому випадку спосіб доступу вашого додатка до API у середовищі розробки буде відрізнятися від способу доступу API до нього під час виробництва. Таким чином, вам може знадобитися використовувати різні HTTP-URL-адреси в різних середовищах (наприклад, api / users / 1 на dev та users / 1 на виробництві). Для цього можна скористатися опцією середовища Angular CLI:

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

Висновок

Безсумнівно, Angular CLI - це дуже потужний та надійний інструмент. Це полегшує наше життя розробників інтерфейсів у багатьох відношеннях. Але це також вимагає від вас прийняття архітектурного рішення щодо підключення до сервера API. Тому вам потрібно чітко розуміти різні способи встановлення зв'язку клієнт-сервер.

У цій статті перелічено два підходи до вирішення цієї проблеми в середовищі розробника, а також одну рекомендацію щодо виробничої архітектури.

Спробуйте пограти з різними компіляціями і подивіться, яка з них почувається зручнішою для вас і вашої команди.

Розважайтесь і повідомте мені, як це відбувається!