Технологии b8q под капотом

Backend: Node.js + Express 5

Сервер b8q — один процесс Node.js на Express 5. Пятая версия выбрана из-за нативной поддержки async/await: ошибки в асинхронных обработчиках ловит middleware, обёртки вроде express-async-errors не нужны, и уходит целый класс багов с unhandled promise rejection.

API устроен по REST: у каждого ресурса (пользователи, чаты, сообщения, документы, файлы, доски) стандартные CRUD-эндпоинты. На том же порту работает WebSocket-сервер: при загрузке клиент получает данные через REST и подписывается на обновления по WebSocket.

Сервер запускается одной командой node server.js, без Docker и внешних сервисов, кроме необязательного TURN-сервера для звонков. Установка сводится к трём действиям: скопировать файлы, поставить зависимости через npm, запустить. Для production рекомендуем PM2 или systemd, но и без них сервер работает стабильно.

Цепочка middleware минимальна: CORS, разбор JSON, проверка JWT, rate limiter. Логи пишутся через console с отметкой времени, в production они перенаправляются в файл или syslog.

Real-time: WebSocket + Yjs

В b8q два канала реального времени. Первый — WebSocket для системных событий: новые сообщения, индикатор набора, статусы прочтения, изменения на канбан-досках, уведомления о файлах. Соединение открывается при входе и живёт всю сессию, при разрыве клиент переподключается с экспоненциальной задержкой.

Второй канал — Yjs для совместного редактирования документов. Это CRDT-библиотека (Conflict-free Replicated Data Type): каждая операция коммутативна и идемпотентна, поэтому одновременные правки сливаются без конфликтов, а правила «побеждает последний сохранивший» нет.

Yjs синхронизируется поверх WebSocket: открывая документ, клиент запрашивает текущее состояние и подписывается на обновления. Каждое нажатие клавиши уходит как операция, и результат одинаков на всех устройствах, даже если двое печатали в одном месте.

Производительность Yjs масштабируется линейно по числу операций: документ с тысячами правок открывается за десятки миллисекунд. История изменений хранится в компактном бинарном виде.

• WebSocket для всех событий в реальном времени
• Автоматическое переподключение с backoff
• Yjs CRDT: совместное редактирование без конфликтов
• Линейная масштабируемость по числу операций

База данных: SQLite + WAL

Для self-hosted мессенджера на одном сервере SQLite удобнее PostgreSQL или MySQL: нет отдельного процесса БД, сетевых вызовов и настройки пулов соединений. SQLite встроен в процесс Node.js через better-sqlite3, и запрос к базе — это вызов функции, а не сетевой roundtrip.

Ключевая настройка — WAL (Write-Ahead Logging): чтение и запись не блокируют друг друга. Сотни запросов к истории чатов выполняются параллельно и не мешают записи новых сообщений.

На типичной нагрузке мессенджера SQLite в режиме WAL выдерживает десятки тысяч операций в секунду, этого с запасом хватает команде до нескольких сотен человек. База — один файл: бэкап делается командой cp database.db database.db.backup, миграции — SQL-файлы, которые выполняются при запуске сервера.

Схема нормализована (users, chats, messages, documents, files, boards, cards), на частых полях chat_id, created_at и user_id стоят индексы. Полнотекстовый поиск по сообщениям работает на FTS5, который входит в стандартную сборку SQLite.

Безопасность: JWT + bcrypt + Rate Limiting

Авторизация построена на JWT (JSON Web Tokens). При входе сервер проверяет пароль, формирует токен с user_id и ролью и подписывает его секретным ключом, а клиент передаёт токен в заголовке Authorization в каждом запросе. Срок жизни токена задаётся в конфигурации.

Пароли хранятся как bcrypt-хеши. Алгоритм намеренно медленный (cost factor настраивается), соль встроена в хеш, поэтому rainbow tables бесполезны. Даже при утечке базы восстановить пароли при адекватном cost factor практически невозможно.

Rate limiting защищает вход от перебора паролей, а API от DoS. Лимиты задаются для каждого эндпоинта: на вход жёстче, на чтение сообщений мягче, при превышении сервер отвечает 429 Too Many Requests. В self-hosted пороги настраивает администратор.

WebSocket-соединение проверяется при установке: клиент передаёт JWT, сервер проверяет подпись, и неавторизованные соединения отклоняются до передачи данных. В production трафик идёт по HTTPS/WSS, TLS обеспечивает reverse proxy (nginx, Caddy).