Как структурировать приложение React с несколькими функциональными областями на разных портах?

Question

Веб-приложение, которое мы создаем, должно иметь 3 разных «области», доступных на 3 разных портах, например:

• localhost: 9001 - для администраторов
• localhost: 9002- для клиентов
• localhost: 9003 - для незарегистрированных пользователей

Серверная часть построена на Hapi / Node и предоставляет множество конечных точек API для использования пользовательским интерфейсом.Теперь интерфейс должен быть встроен в React - три области должны иметь общие элементы пользовательского интерфейса, но, находясь на разных портах, каждый из них может иметь уникальные функции пользовательского интерфейса.

Как бы вы решили структурировать интерфейсный код (React) приложения в этом сценарии?

До сих пор я использовал бы create-реакции-приложение и создать приложение, которое на практике имеет только 1 порт - и использовать аутентификацию / авторизацию для ограничения определенных функций.Теперь, с тремя различными функциональными областями, должно ли быть 3 отдельных приложения create-реагировать, по одному для каждой области, живущих в одном корневом проекте?Будут ли общие элементы пользовательского интерфейса находиться внутри отдельного «общего» модуля, и тогда 3 разных приложения будут импортировать компоненты оттуда?

Все советы о том, как структурировать приложение React для работы (как минимум) с 3 различнымипорты / районы очень ценятся.

Answer 1

Для того, чтобы ваша структура приложения была в состоянии прослушивания:

• localhost: 9001 - для администраторов
• localhost: 9002 - для клиентов
• localhost: 9003 - для незарегистрированных пользователей

Возможно реализовать, и Node.js, react.js полностью поддерживают такое структурирование.Но я сначала напишу свои возможные проблемы как предварительное примечание , а затем посоветую решение на вопрос:

Предварительное примечание:

Случай, упомянутый в вопросе, вероятно, не идеален для каждого, но только для некоторых особых случаев (когда вы знаете, ПОЧЕМУ и ЧТО вы хотите сделать).

В производственной среде вы будете прослушивать только порт 80 (для HTTP ) или 443 (для HTTPS ) для посетителей, участников,и для администратора .Остальные вещи будут обрабатываться вашим приложением самостоятельно.

В бэкэнде вы можете распределить трафик по количеству машин (IP), на каждом из которых работает один и тот же пакет приложений и версия.Таким образом, нет причин использовать несколько портов для одного URL.
(Давайте заключим это здесь, в противном случае оно пойдет шире и шире.)

Решение вопроса:

Теперь, есливы хотите структурировать свое приложение как на 3 разных порта (каждый для отдельной роли или типа пользователя), что может помочь вам настроить дополнительные разрешения доступа для каждого port;тогда вам понадобится файл Node.js server.js для прослушивания нескольких портов.Это также возможно, как упомянуто здесь: работает http-сервер node.js на нескольких портах

Или у вас могут быть разные server1.js, server2.js, server3.js, каждый слушающий на своем порте,Затем вы выбросите или отобразите соответствующие файлы react.js application bundle.Вам нужно будет разработать отдельное приложение react.js для каждого раздела (всего 3).Таким образом, вы можете легко масштабировать и управлять каждым разделом, не смешивая слишком много сложности каждого раздела (web, member, admin).

Конечно, у вас будет один node_modules/, который будет использоваться вашим NodeJs приложение.И вы можете запустить все 3 серверных файла из одного package.json.

Answer 2

Мне известно, что ответ может быть слишком запоздалым для вопроса на данный момент.

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

Answer 3

Если вы настаиваете на запуске каждого компонента на отдельном порту, одним из решений является создание 3 отдельных приложений для их запуска на разных портах.Если есть какие-то сходства в функциональности для каждого интерфейса, вы должны не дублировать код.Вместо этого настройте сборки в файле package.json, чтобы упростить повторное использование используемых компонентов и другого кода, общего для каждого приложения.

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