Как сделать сайт-мессенджер: план MVP с авторизацией и чатом

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

Какой результат должен работать в первой версии

Исходная ситуация проста: два тестовых пользователя открывают сайт в разных браузерах. Ожидаемый результат: каждый входит в свой аккаунт, видит только разрешённый диалог, отправляет текст, получает ответ без обновления страницы и после повторного входа видит историю. Проверка строится вокруг этого маршрута, а не вокруг количества экранов.

• Обязательные сущности: пользователь, комната, участник комнаты и сообщение.
• Обязательные поля сообщения: идентификатор, комната, автор, текст, время создания.
• Основные экраны: вход, список диалогов и открытая переписка.
• Безопасный выход: ошибка отправки видна, текст не пропадает, действие можно повторить.
• Граница MVP: только текст и один тип диалога, вложения добавляются после проверки доступа.

Правило архитектуры: база хранит историю, realtime только сообщает об изменении. Если сообщение существует лишь в событии соединения, оно исчезнет после сбоя или повторного входа.

Из каких слоёв состоит веб-мессенджер

Для первой версии удобно взять один управляемый backend, например Supabase, чтобы не собирать отдельно вход, базу, realtime и файлы. В официальном обзоре Supabase эти части описаны как связанные сервисы. Это не отменяет проектирование доступа: готовая платформа даёт инструменты, но правила видимости комнат задаёте вы.

1. Авторизация подтверждает личность и выдаёт сессию.
2. Таблицы хранят комнаты, участников и сообщения.
3. Политики доступа проверяют, состоит ли текущий пользователь в комнате.
4. Realtime доставляет событие о новой записи подключённым участникам.
5. Хранилище принимает вложение только от участника и выдаёт его только разрешённым людям.
6. Интерфейс показывает отправку, доставку, ошибку и повтор.

WebSocket создаёт и поддерживает двустороннее соединение браузера с сервером; события open, message, error и close позволяют отслеживать его состояние. Это подтверждает справка MDN по WebSocket. Для боевого сайта страница должна работать по HTTPS, а соединение использовать wss, как указывает руководство MDN для клиента WebSocket.

Как спроектировать данные и доступ

Минимальная схема содержит profiles, rooms, room_members и messages. У сообщения есть внешний ключ на комнату и автора. Проверка доступа не должна зависеть от скрытой кнопки в интерфейсе: сервер разрешает чтение сообщения только участнику соответствующей комнаты, а вставку только от имени вошедшего пользователя.

Supabase Auth выдаёт JWT и интегрируется с Row Level Security, поэтому права можно применять к каждой строке. Это описано в документации Auth. Для Realtime частные каналы также защищаются политиками, а при Postgres Changes записи передаются только тем клиентам, которым RLS разрешает чтение. Правила приведены в документации Realtime Authorization.

Практический проверочный тест: войдите как пользователь А и попробуйте получить комнату пользователя Б напрямую по идентификатору через инструменты разработчика. Правильный результат: пустой набор или отказ. Если сообщение вернулось, интерфейс может выглядеть закрытым, но данные уже открыты.

По теме: Как создать свой конструктор сайтов: план MVP в 2026

Как собрать маршрут по шагам

1. Создайте вход по ссылке или паролю и экран выхода из аккаунта.
2. Добавьте таблицы и связи, затем включите RLS до подключения интерфейса.
3. Создайте тестовую комнату и две записи участников.
4. Сделайте загрузку истории с сортировкой по времени и устойчивым идентификатором.
5. Отправляйте сообщение сначала в базу, показывайте статус ожидания и подтверждайте после успешной записи.
6. Подпишитесь на изменения комнаты и добавляйте только ещё не показанные сообщения.
7. Обработайте потерю сети: покажите состояние соединения, сохраните неотправленный текст и разрешите повтор.
8. Только после теста текста добавляйте файлы и задавайте ограничения по типу, размеру и владельцу.

Если вам нужен обычный чат поддержки, а не отдельный продукт, сравните задачу со статьёй о чате на сайте. Для более широкого продукта полезен план сайта-сервиса, а основы публикации интерфейса есть в гайде по сайту на HTML.

Файлы и секреты без опасных сокращений

У файлов должен быть собственный контур прав. Supabase Storage по умолчанию не разрешает загрузку без RLS-политик, а доступ можно ограничивать владельцем и бакетом. Это указано в официальном руководстве Storage Access Control. Сначала сохраняйте объект под случайным именем, затем записывайте ссылку в сообщение после успешной загрузки.

Никогда не помещайте секретный или service role ключ во фронтенд. Такой ключ обходит RLS и предназначен только для доверенного backend. Предупреждение прямо дано в руководстве по защите данных Supabase. В браузере используется публикуемый ключ вместе с корректными политиками и минимальными правами.

По теме: Как сделать сайт-сервис: MVP, данные и проверка в 2026

Проверка двумя пользователями и диагностика

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

• Сообщение видно только после обновления: подписка не подключилась или слушает не ту комнату.
• Сообщение появляется дважды: интерфейс добавил локальную копию и то же событие без проверки идентификатора.
• После повтора создаются дубли: операция не имеет устойчивого клиентского идентификатора.
• Чужая комната открывается по URL: серверная политика допускает чтение, скрытие ссылки проблему не решает.
• Файл загрузился, но не открывается автору: политика объекта не совпадает с политикой сообщения.
• На слабой сети интерфейс зависает: нет тайм-аута, состояния ошибки и безопасного повтора.

Когда такой способ не подходит

Не начинайте с этого MVP, если обязательны сквозное шифрование, юридически значимый архив, звонки, очень большие публичные комнаты, сложная антиспам-модерация или гарантированная доставка при длительном офлайне. Здесь прототип на готовом backend полезен только для проверки интерфейса, а архитектуру и модель угроз нужно проектировать отдельно.

Частые вопросы

Можно ли сделать мессенджер только на HTML и CSS?

Можно нарисовать интерфейс, но вход, хранение истории и доставка сообщений требуют backend и базы данных.

Нужен ли отдельный WebSocket-сервер?

Не обязательно. Управляемый realtime-сервис снимает часть инфраструктурной работы. Собственный сервер нужен, когда требования к протоколу, масштабу или размещению не покрывает платформа.

Можно ли хранить сообщения только в realtime-канале?

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

Стоит ли сразу добавлять файлы и голосовые сообщения?

Нет. Сначала подтвердите доступ, историю и повтор отправки на тексте. Каждый новый тип вложения добавляет ограничения хранения, проверки содержимого и интерфейса ошибок.