Знаете ли вы, как можно использовать reverse proxy для быстрого autosave между фронтовыми модулями без единой базы, через WebSocket-соединения?
В распределённых модульных фронтендах часто требуется без задержек синхронизировать пользовательские настройки или черновики между разными частями SPA, не прибегая к общей базе данных. Такой обмен можно реализовать, если объединять WebSocket-сессии модулями сквозь reverse proxy, чтобы получать центральную точку обмена и упростить маршрутизацию трафика между отдельными сервисами или микрофронтендами. Это позволяет каждому модулю слушать и отправлять изменения состояния мгновенно, без лишнего кустарного взаимодействия.
Зачем здесь reverse proxy — и чем он помогает с WebSocket
Прямое соединение каждого фронта с autosave-сервисом может быстро привести к избытку открытых WebSocket-каналов и хаосу в настройках CORS, балансировке и безопасности. Reverse proxy превращает все WebSocket-запросы в управляемый поток: получает их на одном порту, потом аккуратно раскидывает на нужные микросервисы, централизует контроль соединений и позволяет быстро масштабировать инфраструктуру. Архитектурно это убирает необходимость в отдельном сервисе шины данных или синхронизации между фронтами.
Пример reverse proxy для WebSocket autosave на Node.js
В этом фрагменте сервер принимает входящие WebSocket-подключения на единый порт (через proxy), а затем проксирует дальше к нужному сервису. Каждый входящий autosave-запрос обрабатывается на целевом сервере – так, чтобы фронты не взаимодействовали друг с другом напрямую и не пересекались на уровне логики:
const http = require('http');
const WebSocket = require('ws');
const httpProxy = require('http-proxy');
const proxy = httpProxy.createProxyServer({});
const server = http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Reverse Proxy for Autosave');
});
const wss = new WebSocket. Server({ noServer: true });
server.on('upgrade', (req, socket, head) => {
proxy.ws(req, socket, head, { target: 'ws://localhost:5000' });
});
wss.on('connection', (ws) => {
ws.on('message', (message) => {
// Обрабатываем autosave – сохраняем данные во временное хранилище, если нужно
ws.send('Autosave performed');
});
});
server.listen(3000, () => {
console.log('Proxy server is running on port 3000');
});
В этом примере autosave-логика реализуется на целевом сервере (localhost:5000) – reverse proxy лишь пересылает WebSocket-сессии, не привязываясь к конкретной реализации хранения. Это значит, можно гибко менять схему хранения: временно записывать в память, сбрасывать в redis или даже на диск, не меняя прокси.
Что интересно учесть для production-сценариев
– С помощью такого reverse proxy можно организовать маршрутизацию на разные группы сервисов или разные версии серверов, проставлять нужные заголовки и прокидывать авторизацию.
– Для фронтов, построенных как модульные микросервисы, это снимает многие ограничения по количеству соединений и позволяет держать WebSocket-пул небольшим и управляемым.
– Если нужно централизовано контролировать autosave-сессии или временные данные, достаточно добавить простую прослойку на target-сервере на redis или file-based storage. Прокси остается “глупым”, быстро реагируя на события и не лезет в детали логики хранения.
Такой подход не только упрощает архитектуру временного обмена состоянием между фрагментами SPA, но и отлично работает при большом числе одновременных подключений, избавляя от лишней синхронизации и межмодульных зависимостей.
