Зачем нужен обратный прокси (Reverse Proxy)?

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

- использовать HTTPS;
- раздавать статические файлы;
- применять ограничение частоты запросов (Rate Limiting);
- масштабировать приложение.

Часть этих задач можно решить прямо в API. Но проблема в том, что тогда ему приходится выполнять две разные роли:
реализовывать бизнес-логику (пользователи, платежи, заказы и т. д.);
решать инфраструктурные задачи (HTTPS, раздача статики, Rate Limiting и т. д.).

По мере появления новых инфраструктурных задач становится логично отделить их от бизнес-логики.
Для этого между интернетом и вашим API добавляют дополнительный слой.
Этот слой называется обратным прокси (Reverse Proxy).

Он принимает входящие запросы и решает, что с ними делать: обработать их самостоятельно или перенаправить в API.
Интернет → Reverse Proxy → Ваш API

Одним из самых популярных решений для реализации обратного прокси является NGINX.
Главное преимущество такого подхода в том, что API может полностью сосредоточиться на бизнес-логике, а обратный прокси берёт на себя управление входящим трафиком до того, как он попадёт в приложение.

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

Однако по мере роста приложения такое разделение ответственности обычно значительно упрощает масштабирование и сопровождение системы.

👉 Java Portal