#node.js #api #express #nginx #architecture
#node.js #API #экспресс #nginx #архитектура
Вопрос:
Я создаю приложение с короткой ссылкой, такое как bit.ly с использованием стека MERN. Я хочу, чтобы статические страницы приложения размещались на отдельном сервере от API. Моя архитектура должна быть:
API:
ОПУБЛИКОВАТЬ — example.com/link — создать короткую ссылку.
ПОСТАВИТЬ example.com/link:slug — обновить короткую ссылку.
ПОЛУЧИТЬ example.com/:slug — получить / перенаправить короткую ссылку на длинную ссылку.
Статический сайт:
ПОЛУЧИТЬ — example.com — Домашнюю страницу.
ПОЛУЧИТЬ — example.com/:slug-that-doesnt-exist — 404 страница.
ПОЛУЧИТЬ — example.com/blog, example.com/docs, example.com/support etc. — Различные статические страницы
Проблема, с которой я сталкиваюсь, заключается в том, что сервер разграничивает два типа запросов к одному и тому же домену, часто по одному и тому же пути.
example.com/abc123 является ли API example.com/blog статическим сайтом, даже если экспресс-маршрутизатор example.com/:slug соответствует обоим. Чтобы усложнить, он example.com/zxy987 попадает в API, но не существует, поэтому необходимо перенаправить запрос на статический сервер. Я также не могу понять, как перенаправить сам запрос без изменения URL на другой сервер. Я рассматривал возможность использования NGINX, но, похоже, он не может обрабатывать example.com/:slug-that-doesnt-exist запросы типа, поскольку он не будет знать, существуют ли они во время его запуска.
Каков «лучший» способ подойти к этому?
Комментарии:
1. Есть ли причина, по которой они должны размещаться на отдельном сервере? Похоже, вы могли бы просто определить все в одном экземпляре, а затем определить все ваши статические маршруты до вашего slug.
2. @JasonRoman Основная причина в том, что я могу изменять свою домашнюю страницу, публиковать новые сообщения в блогах / документы и т. Д. без необходимости отправлять новую сборку на мой сервер API, что может привести к простою. Кроме того, это позволило бы мне масштабировать серверы независимо, поскольку с помощью приложения с короткой ссылкой оно, вероятно, получит больше вызовов перенаправления API, чем, скажем, сообщение в блоге.
3. Если это так, почему бы просто не определить свой API как
api.example.comи иметь отдельную конфигурацию nginx? Затем вы можете сделать все, что я сказал выше, на своем основном сайте, а затем перенаправить любые фактические запросы slug на ваш сервер API, чтобы получить ответ перенаправления и перенаправить пользователя.