Маршрутизация доменов и поддоменов в NodeJS или ReactJs

Я думаю, что это не относится к реакции. React — это библиотека браузера, и она не может обрабатывать доменную часть.

Я не рекомендую обрабатывать эту часть с помощью Express, так как для этого необходимо использовать обратный прокси-сервер, вам лучше использовать Nginx, Apache, какой-либо другой серверный движок для обработки поддоменов.

То, что вы запланировали, может быть размещено так,

Домен

1. создать домен.com
2. добавить псевдоним к shopping.domain.com

Сервер

1. создать сервер администратора, клиентский сервер
2. обратный прокси этих серверов

Клиент

1. создать 2 реактивных проекта.
2. domain.com обслуживает файл сборки реакции администратора.
3. shop.domain.com обслуживает файл сборки магазина.

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

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

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

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

В. Но можно ли таким образом визуализировать приложение React?

(Что я понял: может ли приложение реагировать на размещение SSR)

A. Вы можете обслуживать реагирующее приложение с SSR, используя разделение кода и рендеринг на стороне сервера, вам лучше использовать рендеринг на стороне сервера. для некоторых метатегов и страниц, необходимых для SEO, если вам не требуется полное приложение SSR. Если вам нужен полный ssr, для него также есть модный фреймворк Next.js. Возможно, вы уже знаете об этом, судя по тому, что вы упомянули Vercel.

В. Что, если я размещу приложение React на другом сервере, может быть, Vercel, NGINX или что-то еще, и получу доступ к серверной службе в героку с помощью REST API?

(Что я понял: может ли приложение реагировать на другой сервер? NGINX = использование экземпляра сервера, Vercel: использование бессерверной архитектуры )

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

В. Итак, допустим, я использую серверную часть Heroku для Express, значит ли это, что мне нужно создать 2 приложения по отдельности, а не объединять их вместе?

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

В. Экспресс-обработчик поддоменов против vhost

А. Нет фиксированного ответа. вы можете добиться того, чего хотите, используя vhost или экспресс-поддомен-обработчик. Или оба.

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

Что я рекомендую:

Список приложений.

1. реагировать хост - приложение nodejs
2. клиентский хост API - приложение nodejs
3. хост реакции администратора - приложение nodejs
4. клиентский хост API - приложение nodejs

Я использовал AWS S3 для размещения приложений React и EC2 для приложений API.

Концепция структуры.

( NS / DNS ) : domain.com points your-ip
    |
    ( Server instance )
        |
        ( Nginx ) - virtual hosting
            |
            ( www.domain.com ) --- > client react host : ( node app for server side rendering ) : React rendered file for each route. 
                                                       Or you can just respond with index.html for all route for skipping SSR
            |
            ( api.domain.com ) --- > clinet api host : api.domain.com/what, api.domain.com/what/ever?you=want
            |
            ( admin.domain.com ) ---> admin react host : admin.domain.com/* : sending index.html  //static hosting and let all route point for index.html
            |
            ( admin-api.domain.com ) ---> admin react host : Only if you want to seperate. Or you can combine this with api.domain.com using subrouter

Как построить Структуру.

Шаг 1. Размещение сервера.

I don't know much about Heroku but I guess there are aws ec2-like service(cloud computing) and s3-like service(static file service),
This can be single or multiple depending your choice. let's say you wanna go with single server and use virtual host for multiple service end point.

Шаг 2. Настройка сетевого уровня

let's say name-server and DNS server part is network layer. I used AWS Route 53 for this.

    2.1 Buy an domain
    www.your-service.com 
    
    2.2 Add some CNAME to point your web-server host
    - your-service.com,
    - www.your-service.com
    - api.your-service.com,
    - admin.your-service.com    
.
.
.

Шаг 3. Создайте приложение nodejs (прикладной уровень)

I'm assuming that you had one already judging by code in your question.

ubuntu@ip-your-ip:~/project$ ls
api  cli   admin   admin-api   config   libraries  middlewares  models  node_modules   package.json 

ubuntu@ip-your-ip:~/project$ cd api

ubuntu@ip-your-ip:~/project/api$ ls
README.md  app.js  bin  config.json  pm2.config.js  node_modules  package.json  routes

ubuntu@ip-your-ip:~/project/api$ pm2 start pm2.config

PM2 — это деамонизатор приложений узла, вы можете использовать для этого любой демон.

ссылка на ПМ2. https://pm2.keymetrics.io/docs/usage/application-declaration/

Шаг 3. Точки Nginx для приложения nodejs

nano /etc/nginx/nginx.conf

listen 80;
server_name client.domain.com;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:3000;
}

listen 80;
server_name api.domain.com;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:3001;
}

listen 80;
server_name admin.domain.com;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4000;
}

listen 80;
server_name admin-api.domain.com;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4001;
}

Я надеюсь, что это решение будет полезным для вас :)

1. О субдомене

api/ и api/subdomain могут быть реализованы с помощью виртуального хоста NGINX, но поскольку вы запланировали виртуальный хостинг для поддомена, api.domain.com.

перейти с api.domain.com/foo, sub.domain.com/bar кажется более разумным!

Бывший.

listen 80;
server_name api.domain.com/api;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4000;
}

listen 80;
server_name api.domain.com/api/subdomain;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4000;
             #notice that api application is one and you are seperating namespace in it.
             #you can do the same thing in Node.js with subrouter. ( check out Router API in Nodejs official Site )
}

api.domain.com/foo, sub.domain.com/bar
listen 80;
server_name api.domain.com;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4000;#this one is node application listening port 4000
}

listen 80;
server_name sub.domain.com/;
location / {
             proxy_http_version 1.1;
             proxy_pass  http://localhost:4001;#and this is node application listening port 4001
}

Доступ в первом случае.

    GET    api.domain.com/api/foo
    GET    api.domain.com/api/subdomain/bar

Доступ во втором случае.

    GET    api.domain.com/foo
    GET    sub.domatin.com/bar

2. Так верно. Пусть каждый CNAME указывает на ваш EC2 (или любое веб-приложение на любом экземпляре сервера) в качестве источника

3. Вам не нужно настраивать серверный движок для вашего экземпляра S3.

S3 находится не в экземпляре EC2, а где-то в центре обработки данных AWS. Таким образом, виртуальный хост не является решением для ведра маршрута S3. Вместо этого вы можете использовать Route53 для маршрутизации корзины S3 для вашего домена.

Если у вас уже есть домен. Вы можете настроить сервер имен так, чтобы он указывал на сервер имен AWS. Вы можете получить NS/DNS из консоли Route 53 после регистрации домена.

Между тем, есть проблема со статическим хостингом, реагирующим на приложение (S3-подобный хостинг), вам нужно отказаться от SSR. Поскольку S3 является статическим хостом, он не может работать так, как Lambda или экземпляр сервера.

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

Сделать SSR с экспрессом

Пусть ваш корневой домен (www.domain.com) указывает на клиентский сервер nodejs в EC2. И вложите файл сборки реакции для сервера. Приложение React SSR через Express довольно сложно объяснить, но есть множество примеров, так что вы можете погуглить.

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