Удобное решение для междоменной разработки

задняя часть внешний интерфейс сервер React.js
Удобное решение для междоменной разработки

В настоящее время все больше и больше веб-проектов используют метод разработки с разделением внешнего и внутреннего интерфейса, то есть внешний проект запускается на сервере узла в процессе разработки, а внутренний проект, предоставляющий REST API, запускается. на другом сервере как независимый сервис. , чтобы фронтенд и бэкенд столкнулись с междоменными проблемами при общении через HTTP-запросы.Каждый должен знать, что такое кроссдоменный, поэтому я не буду здесь вдаваться в подробности. Раньше более распространенным методом решения междоменных проблем была настройка CORS на сервере, но этот метод принесет некоторые неудобства:

  1. Для изменения внутреннего кода, если внутренний проект работает на своей собственной машине, это нормально.Если он работает на других серверах или даже поддерживается другими командами, будет более проблематично изменить часть кода. код, и необходимо убедиться, что эти коды не будут выпущены в производственную среду.
  2. При каждом запуске браузера необходимо вводить длинную строку кода, чтобы отключить политику безопасности браузера.Например, команда для браузера Chrome выглядит следующим образом:open -a /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dirЭто не только хлопотно, но и если вы случайно получите доступ к некоторым конфиденциальным данным в этом режиме, это также создаст угрозу безопасности.
  3. В режиме разработки внешний интерфейс отладки должен отображать URL-адрес тестового внутреннего сервера, поэтому его следует удалить перед публикацией в рабочей среде.

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

Во-первых, используйтеcreate-react-appСоздайте внешний проект, если ваш внешний проект выполняется по адресуhttp://localhost:3000, в то же время адрес, по которому работает серверный проект, предоставляющий API,http://localhost:4000, все, что вам нужно сделать, это добавить эту строку конфигурации в файл package.json внешнего проекта:

"proxy": "http://localhost:4000"

Затем вы волшебным образом обнаружите, что хотя HTTP-запрос, отправленный с внешней страницы, по-прежнему доступен через порт 3000, он будет автоматически переадресован на внутренний сервер через порт 4000 и получит правильный ответ. запрос на доступ к странице не будет перенаправлен и все еще может быть перехвачен интерфейсной маршрутизацией, поэтому нам вообще не нужно думать о том, как решать междоменные проблемы. Проблема решена, но в голове остаются еще 2 вопроса:

  1. в пакете.jsonproxyДля чего используются параметры?
  2. Как отделить запрос на доступ к странице от запроса на доступ к REST API?

Имея в виду этот вопрос, давайте посмотримcreate-react-appИсточник - это то, что написано, первый Package.json Фронтные концевые проекты, где мы можем видеть, сценарий начинает выполнение проектаreact-script start, поэтому мы открываем файлcreate-react-app/packages/react-scripts/scripts/start.js(Почему этот файл может быть расположен напрямую и как зарегистрирована команда react-script, относятся к другим точкам знаний, эта статья не расширяет объяснение, сомнительная детская обувь может перейти кздесьвыучить один), мы видим, что есть следующий код:

// Load proxy config
const proxySetting = require(paths.appPackageJson).proxy;
const proxyConfig = prepareProxy(proxySetting, paths.appPublic);
// Serve webpack assets generated by the compiler over a web sever.
const serverConfig = createDevServerConfig(
    proxyConfig,
    urls.lanUrlForConfig
);
const devServer = new WebpackDevServer(compiler, serverConfig);

здесьpaths.appPackageJsonзаявление вcreate-react-app/packages/react-scripts/config/paths.jsсередина:

module.exports = {
  appPackageJson: resolveApp('package.json'),
};

Итак, мы знаем, что здесьproxySettingЭто то, что мы определили в package.json внешнего проекта доproxy, то мы видим,proxySettingбыл использован для созданияserverConfig, наконецserverConfigсоздан как параметр конфигурацииWebpackDevServerпример.webpack-dev-serverявляется тестовым сервером для запуска webpack и предоставляет такие функции, как HMR для облегчения разработки, поэтому мы приходим к первому выводу:Определяется в package.json внешнего проекта.proxyЗначение, которое действует на WebpackDevServer и, наконец, пересылается через WebpackDevServer..

Перейдем к попытке ответить на второй вопрос — как можно отделить запрос на доступ к странице от запроса на доступ к REST API? Мы виделиproxySettingсначала передается вprepareProxyспособ получитьproxyConfig, затем вcreateDevServerConfigМетод возвращает объект, и объектproxyЗначение поляproxyConfig, и, наконец, объект является элементом конфигурации webpack-dev-server, вдокументация webpack-dev-сервераИз вышеизложенного видно, что роль прокси заключается в том, чтобы действовать как слой прокси и пересылать запрос со страницы на другой адрес, поэтому ключ лежит вproxyConfigКакая конфигурация уprepareProxyметод,prepareProxyМетод определен вcreate-react-app/packages/react-dev-utils/WebpackDevServerUtils.js, здесь мы видим, что верно первоеproxyВыполняются проверки типа и формата, затем, еслиproxyявляется правильно сформированной строкой, она возвращает массив только с одним элементом объекта, в которомcontextВ поле появляются следующие суждения:

context: function(pathname, req) {
    return (
        req.method !== 'GET' ||
        (mayProxy(pathname) &&
         req.headers.accept &&
         req.headers.accept.indexOf('text/html') === -1)
    );
}

Здесь мы видим, что естьreq.headers.acceptсудить,req.headers.acceptОн используется для указания типа контента, который браузер ожидает получить через этот HTTP-запрос, поэтому, если accept содержитtext/htmlЭто означает, что этот запрос получает документ, поэтому его не следует пересылать на бэкэнд.Эта нагромождение логики суждений представлено картинкой следующим образом:

Значение контекста здесь отсутствует в документации webpack-dev-server, его описание содержится вhttp-proxy-middleware, контекст поддерживает передачу функции для пользовательской логики переадресации и перенаправляет запрос только в том случае, если возвращаемое значение равно true,Таким образом, прокси будет пересылать только HTTP-запросы, сделанные ajax или fetch.

В дополнение к простейшей конфигурации, упомянутой в статье, прокси-сервер webpack-dev-server также поддерживает несколько методов настройки для одновременного выполнения нескольких правил прокси.Заинтересованные студенты могут обратиться к документации для получения более подробной информации.