Зачем нужен прокси вместо запуска Node.js как целевого процесса?

Зачем нужен прокси вместо запуска Node.js как целевого процесса?

Это вопрос о backend разработке (Node.js сервер), но я объясню в контексте Frontend разработки, так как Frontend разработчики часто работают с локальным dev-сервером через прокси.

Контекст: Frontend разработчик и API

При разработке Frontend приложения нужно:

1. Запустить dev-сервер (Next.js, Vite, Webpack Dev Server)
2. Обращаться к API (на другом порту или домене)

Проблема CORS (Cross-Origin Request Sharing)

Если фронтенд на http://localhost:3000, а API на http://localhost:8000, браузер блокирует запрос:

// Фронтенд на localhost:3000
fetch('http://localhost:8000/api/users')
  .catch(err => console.log(err))
  // CORS Error: Access to XMLHttpRequest blocked

Браузер говорит: "Странице не разрешено запрашивать другой origin".

Решение 1: Включить CORS на API (неправильно)

// Node.js / Express API
app.use(cors({
  origin: 'http://localhost:3000'
}));

Проблемы:

• Нарушает безопасность при продакшене
• Требует разных настроек для разработки и продакшена
• Усложняет конфигурацию API

Решение 2: Использовать прокси в dev-сервере (правильно)

Next.js: Встроенный rewrites

// next.config.js
module.exports = {
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/api/:path*',
          destination: 'http://localhost:8000/api/:path*'
        }
      ]
    };
  }
};

Теперь фронтенд может обращаться к /api/users и он автоматически перенаправляется на http://localhost:8000/api/users:

// Фронтенд на localhost:3000
fetch('/api/users')
  .then(r => r.json())
  // Работает! Прокси перенаправляет на localhost:8000

Как это работает:

Browser (localhost:3000) 
  -> запрашивает /api/users
  -> Next.js dev-сервер (localhost:3000)
  -> перенаправляет на localhost:8000/api/users
  -> получает ответ
  -> отправляет браузеру

Браузер видит, что запрос идёт на тот же origin (localhost:3000), поэтому CORS не блокирует.

Vite / Webpack: Встроенный proxy

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
};

// webpack.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true
      }
    }
  }
};

Почему прокси лучше CORS-заголовков

1. Нет CORS ошибок

// С прокси
fetch('/api/users')  // success

// Без прокси, с CORS
fetch('http://localhost:8000/api/users')  // error, если API не разрешил

2. Разработка близка к продакшену

В продакшене фронтенд и API на одном домене (example.com с путями / и /api). Разработка через прокси симулирует это.

Продакшен:
https://example.com/       <- фронтенд
https://example.com/api/   <- API

Разработка с прокси:
http://localhost:3000/       <- фронтенд
http://localhost:3000/api/   <- прокси -> http://localhost:8000/api/

3. Нет лишних заголовков в коде

// С CORS — в коде API нужно добавлять заголовки
res.setHeader('Access-Control-Allow-Origin', '*');

// С прокси — нечего добавлять, всё в конфиге dev-сервера

4. Работает для всех типов запросов

CORS требует предварительных запросов (preflight) для некоторых методов. Прокси это обходит.

Когда нужны CORS заголовки?

CORS нужны для публичных API, которые должны быть доступны с разных доменов:

// Публичный API
app.use(cors());

// Теперь https://example.com может обращаться
// И https://other-site.com тоже может

Архитектура: Прокси как фасад

Прокси на dev-сервере — это фасад, который скрывает сложность:

Браузер видит простой интерфейс:
fetch('/api/users')  <- путь, как в продакшене

Dev-сервер скрывает детали:
/api/users -> localhost:8000/api/users

Это абстракция — разработчик не думает про разные порты.

Производительность

Без прокси: браузер напрямую говорит с API С прокси: браузер -> dev-сервер -> API (одно дополнительное перенаправление)

Разница микроскопична для локальной разработки, но важна архитектурно.

Заключение

Прокси в dev-сервере нужен для:

1. Обхода CORS при разработке
2. Симуляции продакшена (один домен/origin)
3. Простоты (фронтенд не знает про разные порты)
4. Чистоты (API конфиг не усложняется для разработки)

Это стандартный подход в modern Frontend разработке.