Моше Вильнер

Все пользовавшиеся Angular CLI знают, что это мощный инструмент, который может вывести работу по интерфейсной разработке на совсем другой уровень. В нем есть все типовые задачи, такие как живая перезагрузка, транспиляция машинописного текста, минификация и т.д. И все это предварительно настроено и готово к использованию с помощью одной простой команды:

ng build, ng serve, ng test.

Но есть одна (и очень важная) задача, которую нужно настроить, когда приложение будет готово начать отображать некоторые данные с сервера…

Так, независимо от того, насколько замечателен фреймворк Angular и насколько быстры и продуктивны его компоненты — в конечном счете, цель SPA (одностраничной программы) — взаимодействовать с сервером через HTTP-запросы.

И вот первое препятствие, которое возникает перед каждым новичком Angular CLI: проект Angular работает на собственном сервере (который по умолчанию работает на том, запросы к серверу API междоменныеи, как вы, вероятно, знаете, безопасность браузера запрещает посылать междоменные запросы.

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

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

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

Вы можете спросить, что такое прокси? Что ж, браузеры не разрешают делать междоменные запросы, но серверы разрешают. Использование опции прокси означает, что вы сообщаете серверу Angular CLI обработать запрос, отправленный из Angular, и повторно отправить его с сервера разработки. Таким образом, «говорящий» с сервером API является сервером Angular CLI.

Конфигурация прокси требует proxy.conf.json файл, который необходимо добавить в проект. Это файл JSON с некоторыми базовыми настройками. Вот пример содержимого proxy.conf:

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

Этот код означает, что все запросы, которые начинаются с api/ будет повторно отправлено (это адрес сервера 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 получал доступ к ней во время производства. Поэтому может потребоваться использовать различные URL-адреса HTTP в различных средах (например API/пользователи/1 в dev и пользователей/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. Поэтому вам необходимо четко понимать разные способы установления связи клиент-сервер.

В этой статье приведены два подхода к решению этой проблемы в среде разработчика, а также одна рекомендация по производственной архитектуре.
Попытайтесь поиграть с разными компиляциями и посмотрите, какая из них будет удобнее для вас и вашей команды.

Получайте удовольствие и дайте мне знать, как это происходит!