b8q построен на проверенных технологиях с упором на производительность, простоту деплоя и предсказуемое поведение. Здесь нет модных фреймворков ради моды -- каждая зависимость решает конкретную задачу.
Четыре слоя, каждый из которых можно понять, отладить и заменить независимо от остальных.
Node.js + Express 5. REST API для CRUD-операций, WebSocket для real-time событий. Один процесс, один порт.
Vanilla JS SPA. 32 модуля, ноль фреймворков. CSS-переменные для тем. Работает без сборки.
WebSocket для сообщений и событий. Yjs для CRDT-синхронизации документов. Конфликтов при совместном редактировании нет.
SQLite в WAL mode. Один файл, встроен в процесс, нулевая латентность на чтение. Бэкап -- копия файла.
Серверная часть b8q -- это один Node.js процесс на Express 5. Выбор Express 5 (а не 4) обусловлен нативной поддержкой async/await в обработчиках маршрутов. Ошибки в async-хендлерах автоматически ловятся middleware, не нужны обёртки вроде express-async-errors. Это упрощает код и убирает целый класс багов с unhandled promise rejection.
API построен по REST-принципам: каждый ресурс (пользователи, чаты, сообщения, документы, файлы, доски) имеет стандартные CRUD-эндпоинты. Для real-time событий параллельно работает WebSocket-сервер на том же порту. Клиент получает данные через REST при загрузке страницы и подписывается на WebSocket для получения обновлений в реальном времени.
Весь сервер запускается одной командой: node server.js. Нет Docker-зависимостей, нет внешних сервисов (кроме опционального TURN-сервера для звонков). Это упрощает self-hosted деплой до минимума: скопировал файлы, установил зависимости через npm, запустил. Для production рекомендуется PM2 или systemd, но и без них сервер работает стабильно.
Middleware-цепочка минимальна: CORS, JSON body parser, JWT-проверка, rate limiter. Каждый middleware делает одну вещь и не трогает остальное. Логирование -- через console с timestamp, без тяжёлых logging-фреймворков. В production логи перенаправляются в файл или syslog через стандартный pipe.
Фронтенд b8q -- это SPA на чистом JavaScript. Без React, без Vue, без Angular. 32 модуля, каждый из которых отвечает за конкретный кусок интерфейса: ChatModule, CallModule, DocumentEditor, KanbanBoard, FileManager и так далее. Модули загружаются через ES-модули и регистрируются в центральном роутере.
Такой подход выбран осознанно. Без фреймворка размер бандла на порядок меньше: весь JavaScript-код приложения -- это десятки килобайт, а не мегабайты. Страница загружается мгновенно. Нет виртуального DOM, нет реактивной системы, нет diffing-алгоритма -- работа с DOM прямая, через querySelector и createElement. Для 90% задач этого достаточно.
Стилизация построена на CSS-переменных. Шесть предустановленных тем переключаются сменой набора переменных на :root. Пользователь может настроить акцентный цвет, и вся цветовая схема пересчитается автоматически. Никакого CSS-in-JS, никакого Tailwind -- обычные CSS-файлы с понятной структурой.
Сборка не нужна. Код работает напрямую в браузере через <script type="module">. На production файлы можно минифицировать через terser, но это опционально. Отладка -- через DevTools браузера, без source maps, без webpack. Каждый файл -- это модуль, и его можно открыть, прочитать и понять.
В b8q два канала real-time коммуникации. Первый -- WebSocket для системных событий: новые сообщения, typing indicators, статусы прочтения, обновления канбан-досок, уведомления о файлах. Клиент открывает одно WebSocket-соединение при авторизации и держит его открытым на протяжении всей сессии. При разрыве -- автоматический реконнект с экспоненциальным backoff.
Второй канал -- Yjs для совместного редактирования документов. Yjs -- это CRDT-библиотека (Conflict-free Replicated Data Type). Она гарантирует, что при одновременном редактировании одного документа несколькими пользователями все правки корректно сольются без конфликтов. Нет "победил последний, кто сохранил" -- каждая операция коммутативна и идемпотентна.
Синхронизация Yjs работает поверх WebSocket. Когда пользователь открывает документ, клиент запрашивает текущее состояние и подписывается на обновления. Каждое нажатие клавиши транслируется как операция -- вставка символа в позицию N. Другие клиенты применяют эту операцию к своей копии документа. Результат идентичен на всех устройствах, даже если оба пользователя печатали в одно и то же место.
Производительность Yjs масштабируется линейно с количеством операций. Документ с тысячами правок открывается за десятки миллисекунд. Для крупных документов Yjs использует компактное бинарное представление -- история изменений сжимается и занимает минимум памяти.
Звонки в b8q реализованы через WebRTC -- стандарт W3C для peer-to-peer аудио/видео в браузере. Медиапотоки идут напрямую между участниками, серверу передаётся только сигнализация (offer/answer/ICE candidates) через WebSocket. Это минимальная задержка и отсутствие нагрузки на сервер при передаче медиа.
Для установки соединения используется ICE framework. Сначала клиенты пытаются установить прямое соединение через STUN-серверы (определение публичного IP и порта). Если прямое соединение невозможно (симметричный NAT, корпоративный файрвол), трафик идёт через TURN-relay. b8q поддерживает настройку кастомных STUN/TURN серверов в конфигурации.
Видео передаётся с адаптивным качеством. Клиент мониторит пропускную способность соединения через RTCPeerConnection.getStats() и динамически переключает разрешение: 720p при нормальном канале, 480p при слабом, 1080p при хорошем. Переключение происходит без разрыва звонка -- просто меняется constraint на видеодорожке.
Групповые звонки на 2-5 участников работают через mesh-топологию: каждый участник устанавливает P2P-соединение с каждым. Для 5 участников это 10 соединений. Mesh-архитектура не требует медиасервера (SFU/MCU), что упрощает деплой, но ограничивает масштаб. Для большинства рабочих созвонов 5 человек -- достаточный потолок.
Почему SQLite, а не PostgreSQL или MySQL? Потому что для self-hosted мессенджера на одном сервере SQLite -- оптимальный выбор. Нет отдельного процесса БД, нет сетевых вызовов, нет конфигурации пулов соединений. SQLite встроен в процесс Node.js через better-sqlite3 и работает как библиотека. Запрос к базе -- это вызов функции, а не сетевой roundtrip.
WAL mode (Write-Ahead Logging) -- ключевая настройка. В этом режиме читатели и писатели не блокируют друг друга. Пока один запрос записывает данные, другие продолжают читать без ожидания. Для мессенджера это критично: сотни SELECT-запросов на чтение истории чатов выполняются параллельно, не мешая записи новых сообщений.
Производительность SQLite в WAL mode на типичных нагрузках мессенджера -- десятки тысяч операций в секунду. Для команды до нескольких сотен человек это с большим запасом. Вся база данных -- один файл на диске. Бэкап -- cp database.db database.db.backup. Миграции -- SQL-файлы, которые выполняются при запуске сервера.
Схема базы нормализована: users, chats, messages, documents, files, boards, cards. Индексы на часто запрашиваемых полях (chat_id, created_at, user_id). FTS5-расширение используется для полнотекстового поиска по сообщениям. Всё это работает из коробки, без установки расширений -- FTS5 встроен в стандартную сборку SQLite.
AI-ассистент в b8q подключается к Google Gemini через REST API. Клиент отправляет сообщение в чат, сервер формирует prompt с контекстом (история диалога, системная инструкция) и отправляет запрос к Gemini. Ответ модели возвращается пользователю как обычное сообщение в чате.
Архитектура AI-модуля предусматривает отказоустойчивость. Если API Gemini недоступен (таймаут, ошибка квоты, сетевые проблемы), срабатывает rule-based fallback. Это набор предопределённых паттернов и ответов для типовых запросов: помощь по интерфейсу, базовые команды, FAQ. Не полноценная замена LLM, но достаточно, чтобы ассистент не "молчал" при проблемах с внешним API.
Промпт-инжиниринг реализован на сервере. Клиент отправляет только текст пользователя, сервер добавляет системную инструкцию и историю последних сообщений. Это позволяет контролировать поведение модели централизованно -- администратор может изменить системный prompt без обновления клиентского кода.
Для организаций с жёсткими требованиями к данным AI-модуль можно полностью отключить в конфигурации сервера. Ни один запрос не уйдёт во внешний сервис. Это критично для компаний, которые работают с персональными данными, финансовой информацией или коммерческой тайной.
Авторизация в b8q построена на JWT (JSON Web Tokens). При логине сервер проверяет пароль, генерирует JWT с payload (user_id, role) и подписывает его секретным ключом. Токен передаётся клиенту и используется во всех последующих запросах в заголовке Authorization. Срок жизни токена настраивается в конфигурации.
Пароли хранятся в базе как bcrypt-хеши. bcrypt специально разработан для хеширования паролей: он медленный (cost factor настраивается), устойчив к rainbow tables (salt встроен в хеш) и давно проверен индустрией. Даже при утечке базы данных восстановить пароли из bcrypt-хешей практически невозможно при адекватном cost factor.
Rate limiting защищает от brute-force атак на авторизацию и от DoS на API. Ограничения настраиваются per-endpoint: для логина -- жёстче, для чтения сообщений -- мягче. При превышении лимита сервер возвращает 429 Too Many Requests. Для self-hosted установок администратор может настроить пороги под свою нагрузку.
WebSocket-соединения проверяются при установке: клиент передаёт JWT при handshake, сервер верифицирует подпись и извлекает user_id. Неавторизованные соединения отклоняются до передачи данных. Вся коммуникация идёт через HTTPS/WSS в production -- TLS обеспечивается reverse proxy (nginx, Caddy).
Ключевые этапы разработки b8q -- от первого прототипа до полноценной платформы.
Первая версия: чат на WebSocket, авторизация по JWT, SQLite в качестве хранилища. Базовый UI на Vanilla JS. Проверка гипотезы: можно ли собрать рабочий мессенджер без фреймворков.
Интеграция WebRTC для P2P-звонков. Три типа редакторов документов: Markdown, Rich Text (Quill), таблицы (jspreadsheet). Добавлен Yjs для совместного редактирования в реальном времени.
Канбан-доски с drag & drop. Облачное хранилище с превью файлов. AI-ассистент на базе Gemini. Групповые звонки до 5 участников. PWA-поддержка для мобильных устройств.
Шесть цветовых тем. Настройка акцентных цветов. White-label режим для корпоративного брендинга. Импорт файлов .docx, .xlsx, .csv. Голосовые сообщения.
Документация для self-hosted деплоя. Picture-in-Picture для звонков. Скриншеринг. Оптимизация производительности SQLite и WebSocket. Закрытая бета-версия.
Открытая регистрация. Облачная версия наряду с self-hosted. Расширение API для интеграций. Планы по E2E-шифрованию и федерации между серверами.
Лучший способ оценить архитектуру — развернуть и посмотреть. 5 минут от git clone до первого сообщения.