Как реализовать свою чат-платформу?

Рано или поздно вы решите написать чат. Да, свой чат. И, возможно, вспомните про эту статью.

Изложу свое понимание, видение на построение системы любого чата, будь то чат между 2 пользователями, групповой чат (открыто и закрытого типа), чат с контактом в другом мессенджере, канал, общение с посетителями сайта или пользователями приложения.

Все изложенное субъективно. Искал разные источники, анализировал другие чат-платформы. Надеюсь, будет полезно.

И так.

Что такое чат? Мы каждый день общаемся в чатах, чаты в разных приложениях похожи и не похожи одновременно.

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

- Чат - это хронологическая лента сообщений.

- Сообщение - некая единица контента (текст, файл, картинка, аудио, видео, стикер, оповещение, ...)

- также у сообщения есть дата-время создания сообщения.

- У сообщения всегда есть отправитель.

- В чат сообщения могут добавлять разные отправители (пользователи, боты, система).

- В чате есть участники. По сути - это подписчики, которые подписаны на получение новых сообщений в чате.

Пожалуй, это база. Далее все просто немного расширяется и дополняется под каждый конкретный случай.

Таким образом, есть вопрос: а можно ли на этой базе построить какой-то относительно универсальный движок чата, который можно использовать для разработки любых систем чатов?

Попробуем.

Т.е. у нас в системе появляются такие сущности как Чат, Сообщение, Участник.

Также нам потребуются статусы сообщений - это ответ подписчика на полученное сообщение. Например, получил сообщение, прочитал сообщение.

Есть еще такой момент - системы разные и мы не знаем, какое поведение нам придется реализовать в каждом случае заранее.

Поэтому нам нужна гибкая система, где мы сможем навешать какие-то данные на наши сущности, и с ними в дальнейшем взаимодействовать.

Поэтому мы добавим мета теги - мета данные, которыми мы дополняем наш скелет системы чатов.

Далее поясню на примерах.

Для начала групповой чат - чат, в котором состоит несколько участников. Как обычно, если вы решили создать групповой чат - вы создали чат, как-то назвали его, добавили аватарку чата, добавили кого надо, отправили сообщение. Название чата и аватарка чата - это мета данные.

Например, вы строите систему чатов, где вам надо разделить видимость чатов и соответственно работу с ними - вводите мета данные - тип чата.

И у вас может быть групповой чат открытого типа - т.е. его можно найти в поиске и вступить, и у вас может быть чат закрытого типа -

не найти в общем поиске и добавление например только участником чата.

Как частный случай группового чата - чат p2p - это чат между двумя собеседниками. Но в этом случае мы не хотим какое-то название чата, типа "чат между Иваном и Сергеем".

Мы хотим название чата для Сергея - "Иван", а для Ивана - "Сергей". По сути в мета данных нам можно сохранить оба названия и при построении системы чатов использовать этот нюанс.

При этом процессы, которые нам необходимы для построения чата хоть на 100 подписчиков, хоть на 2-х - по сути одинаковы.

Например, мы решили в своей системе сделать чат типа "канал" - это когда в него могут писать только администраторы, а другие участники чата только читать.

Пожалуйста, навешивайте на участника чата мета тег role=administrator, и реализуйте, что с такой ролью могут писать, а без этой роли только читать.

Не знаю, получилось ли мне донести суть мета тегов? Напишите в комментариях.

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

MMS3 - meta message server https://github.com/chottodev/mms3

В видео больше информации и примеров https://youtu.be/WmmEGqDUiRA, (там на 1,5 часа, выделены таймслоты примеров p2p, групповых чатов)

Поясню - это не готовая платформа чатов. Это основа для вашей платформы чатов. И это пока больше концепция, которую я проверяю.

На схеме отображено как это может быть реализовано. Т.е. вы берете mms3. А затем добавляете свой бекенд и фронтенд, где реализуете свои задумки по чату.

(По аналогии для node.js или python разработчиков, вы берете bullmq или celery, а не реализуете свое решение на базе redis или rabbitmq)

Под капотом используется mongodb для хранения данных сообщений и чатов, и rabbitmq для организации получения updates.

В MMS3 есть админка для просмотра данных, как если бы их получали по API.

Пару слов про updates.

Когда один из участников чата делает действие (отправляет сообщение, присылает статус, добавляет еще участника), т.е. происходит событие - то информацию об этом событии должны получить все остальные участники. Для этого есть update. MMS3 отправляет все updates в указанный exchange rabbitmq, и ваше приложение может создать очередь и забирать все необходимые updates (например, для websocket-сервера, который уже будет пушить update каждому пользователю онлайн)

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

• MMS3 - meta message server https://github.com/chottodev/mms3

• видео https://youtu.be/WmmEGqDUiRA

• пример приложения (из видео), использующее MMS3 https://github.com/antirek/chatapp

• группа в тг chottodev https://t.me/chottodev

• анализ от ИИ архитектур open-source проектов чатов https://github.com/antirek/chats-architecture

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