HTTP-запросы от React не достигают экспресс-бэкенда на рабочем сервере - PullRequest
Новая
       11

HTTP-запросы от React не достигают экспресс-бэкенда на рабочем сервере

0 голосов
/ 26 октября 2019

У меня есть интерфейс React (созданный с помощью create-реагировать-приложение) и экспресс-сервер, с удаленной базой данных MySQL. Все работает нормально, когда я работаю как локально, обслуживая интерфейс на localhost:3000 и передавая запросы HTTP на localhost:3306, который также является портом, который прослушивает приложение Express. Запросы отправляются на localhost:3000/api/endpoint, и снова это работает.

Я сейчас пытаюсь перенести эту настройку в рабочий режим на моем сервере. Я использую общий сервер и Node настроен через Cpanel (хотя у меня есть доступ по SSH). Я не "запускаю" сторону React на сервере так, как в процессе разработки, а скорее создаю файлы сборки и помещаю их в каталог, соответствующий домашней странице моего домена.

Допустим, мой домен foo.com. Моя хостинговая компания посоветовала мне запустить Node на порту 50000 (например, когда я попробовал 3306, он сказал, что он уже используется). В настоящее время каждый запрос к моему API, похоже, приводит к 404: он пытается запросить foo.com/api/endpoint и терпит неудачу. У меня вопрос: как правильно направить эти запросы в мой бэкэнд? Я знаю, что опция proxy в React package.json на самом деле не предназначена для использования в производстве, так что я должен использовать вместо этого, и что это должно быть установлено? Есть ли что-то еще, что я должен ожидать настроить на сервере?

Обновление

Хорошо, сейчас я пытаюсь обойти менеджер узлов Cpanel изапустить вещи вручную. Моя структура документов на сервере выглядит следующим образом: 

/home/user
|--- /project
|   |--- /backend
|       |--- (Node server.js, etc.)
|   |--- /client
|       |--- (React src, components, etc.)
|--- /public_html
    |--- (React build files)
    |--- .htaccess

Я считаю, что файлы сборки React должны быть в public_html, чтобы сервер отображал их на моей домашней странице. Следовательно, в настоящее время я НЕ обслуживаю файлы сборки из моего бэкэнда (хотя @MattCarlotta предложил мне сделать это ниже; я готов сделать это, если это будет необходимо. Само приложение React, кажется, работает нормальножить на 3ecologies-seedbank.com, но, возможно, мне также нужно сообщить серверу Node о расположении public_html?).

Другие ресурсы привели меня к мысли, что часть ответа лежит в файле .htaccess. Мой в настоящее время выглядит следующим образом (включая некоторый код, сгенерированный Cpanel): 

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php56” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php56 .php .php5 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

RewriteEngine On
RewriteRule ^/public_html$ http://127.0.0.1:50000/ [P,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/public_html/(.*)$ http://127.0.0.1:50000/$1 [P,L]

Я не совсем понимаю, что нужно сделать, это перенаправить запросы со страниц на public_html в мое приложение Node, которое прослушиваетпорт 50000. Это имеет смысл для меня, потому что, когда я запускаю задний и передний локально, мне нужно прокси-запросы от localhost:3000 (передний) до localhost:3306 (задний).

Я запустил приложение Node поверх SSH с простым node server.js. Он может подтвердить, что прослушивает порт 50000 и подключается к базе данных. Тем не менее, каждый запрос к API от внешнего интерфейса все равно приводит к 404. Кажется, он все еще не достигает серверной части.

Если это поможет, я нахожусь на общем сервере с Apache 2.4.41 и Cpanel 82.0 (сборка 17).

TL; DR Каков производственный эквивалент установки proxy в React для отправки запросов на серверную часть узла?

1 Ответ

1 голос
/ 27 октября 2019

Хорошо, у вас есть несколько проблем, которые вас сдерживали:

  • Вы используете прокси package.json, который будет работать только в разработке. Вместо этого используйте axios конфигурацию на стороне клиента и cors конфигурацию на стороне API, чтобы позволить обоим общаться в процессе разработки / производства.

  • Ваш server.js не обслуживает вашего клиента build производственных активов, поэтому я включил пример того, как это сделать. Кроме того, я добавил сценарий production в package.json в архиве anarchive, чтобы создать работающий пример локального производства. Просто введите npm run production или yarn production, чтобы запустить пример. В этом простом примере перейдите на localhost: 5000, и клиент немедленно попытается проверить поддельный токен JWT, вызвав IFFE found here . API получит токен, аутентифицирует его, а затем ответит предупреждением «Недопустимый токен».

  • Я не смог настроить конфигурацию маршрута API, поэтому я рекомендуюболее стандартный подход.

Например: 

const authRoutes = require("./routes/api/auth");

app.use("/api/auth", authRoutes);

или 

app.use("/api/auth", require("./routes/api/auth"));

Выполнение вышеперечисленных действий поможет вам начать работу.

Вот рабочий репозиторий : https://github.com/mattcarlotta/seedbank-example

Некоторые другие заметки ...

Вы можете значительно упростить свой контроллер APIкод с использованием блоков async/await и try/catch. Например, this - который в настоящее время вызывает сбой в вашем приложении, если заголовок не содержит авторизации) - можно упростить до this (к сожалению, JWT использует обратные вызовы вместо обещаний, поэтомуЯ обернул его обещанием на чистоту, но главное, что контроллер verify гораздо легче читать, он отлавливает любые ошибки и отправляет их обратно клиенту, а не вылетает из приложения).

...