Как мы выбирали чат для студентов и менторов

Illustration of a busy person multitasking with various communication devices and a paper airplane, surrounded by empty speech bubbles. Illustration of a busy person multitasking with various communication devices and a paper airplane, surrounded by empty speech bubbles.

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

Почему мы решились делать свой чат?

1. Качество предоставляемых услуг не зависит от стороннего сервиса.

Как и многие сервисы, mkdev однажды пострадал от попыток Роскомнадзора заблокировать Телеграм. Со своей стороны мы довольно быстро нашли решение и возобновили работу сервиса в России. А вот студентам, которые общались с ментором через Телеграм, повезло не так сильно. Попытки РКН местами увенчались успехом, и у многих наших клиентов пропала возможность общаться со своим наставником. Каждый такой случай приводил к просто ужасному опыту для людей, которые отдали деньги за личное общение с наставником, не говоря уже о дополнительной работе для нашей команды поддержки.

Аналогичные проблемы могут произойти с любой неподконтрольной mkdev системе. Gitter.im может попасть под блокировки РКН, бесплатная версия Slack удаляет старые сообщения (с важной для клиента перепиской, файлами, ссылками), а Google может спонтанно решить прикончить Hangouts.

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

2. Предоставить единый, бесшовный опыт для клиентов

Что происходило раньше:

  1. клиент платит деньги и получает письмо с предложением зарегистрироваться в Gitter;
  2. ссылка на сайте ведёт на профиль ментора в Gitter;
  3. связавшись в Gitter с ментором, ученик и ментор решают, где они будут общаться;
  4. общение переносится в ещё один сервис.

В результате клиент уходил на другую платформу и терял эмоциональную привязку к mkdev. Что происходит теперь:

  1. клиент платит деньги и сразу попадает в личный чат с ментором, где дружелюбный бот Гэбриель уже написал что нужно делать дальше, а ментор сразу же доступен для общения.

Нулевая потребность делать какие-либо лишние шаги для клиента и, как следствие, минимум ситуаций, когда клиент не знает, где искать ментора, а ментор не знает, как связаться с учеником. Всё происходит в пределах экосистемы mkdev.

3. Получить возможность интегрировать обучение с чатом

Раньше все специфичные для обучения вещи (управление подпиской, программа обучения, доступ к квестам) происходили внутри mkdev.me и никак не проявляли себя в общении ментора с учеником. Забрав контроль над чатом к себе, мы получили возможность тесно интегрировать чат с основной платформой mkdev. Речь не только о простейших оповещениях в чате, но и о более сложных вещах, над которыми ведётся работа.

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

4. Собрать наконец-то всех учеников вместе

Помимо отдельного пространства для ментора и всех его студентов мы запустили Клуб mkdev — сообщество для всех студентов, менторов и стажёров проекта. Мы могли сделать это и раньше, создав бесплатную команду в Slack, но мириться с ограничением числа хранимых сообщений и рисковать возможностью лишиться клуба по решению стороннего сервиса мы не могли.

Любое подобное крупное изменение обязательно несёт в себе и недостатки. Например, часть менторов-ветеранов далеко не с восторгом отнеслись к необходимости перенести всё общение из привычных им мест в новую систему. Плюс, конечно, mkdev берёт на себя большой риск убить всё общение путём неосторожного обращения с системой, работоспособность и надёжность которой теперь в нашей полной ответственности.

Как мы выбирали технологии для чата

Для будущей чат-платформы у нас была куча требований. Вот некоторые:

  • возможность интеграции через API с чем угодно;
  • поддержка markdown, загрузки файлов, подсветки кода;
  • наличие удобных клиентов под мобильные устройства;
  • простота в обслуживании;
  • невысокая цена.

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

Вариант 1: SaaS продукт

Проще всего было бы взять готовый продукт и работать с ним. К сожалению, это не то, что мы могли себе позволить. Slack стоит минимум 6.25 евро за пользователя, и аналогичная цена прослеживается у других SaaS продуктов. При нашем количестве студентов и менторов любое SaaS решение просто не выгодно финансово.

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

Вариант 2: написать свой чат с нуля

Какое-то время мы играли с мыслью написать свой чат полностью самостоятельно. Базовая функциональность могла быть сделана в кратчайшие сроки — Ruby on Rails позволяет делать чатики за вечер. Но базовая функциональность — это не то, что нам нужно. Сразу после реализации основных фич чата (отправки друг другу сообщений) нам бы понадобилась поддержка форматирования и загрузки файлов. Затем нам были бы нужны оповещения и вывод числа непрочитанных сообщений. Нужна возможность упоминать людей в чате и, конечно же, использовать emoji. Нужны мобильные приложения и мобильная браузерная версия чата — идеально работающая на всех устройствах и браузерах.

Не успели бы мы и оглянуться, как 100% нашего времени разработки стало бы уходить на допиливание своего чата и исправление его багов. А это не то, на что команда mkdev хочет направить свои ресурсы.

Вариант 3: взять Chat API as a Service

Есть множество разных сторонних сервисов, предоставляющих чат через API. Работает это так: сторонняя компания предоставляет все примитивы чата через API и набор SDK для работы с ними. Всё, что вам остаётся — это написать весь клиентский код (то есть, например, мобильные приложения) для работы с этими API.

Этот путь казался очень заманчивым. Весь сложный бакенд уже реализован, цены на Chat API несравнимо более низкие, чем у SaaS сервисов и при этом у нас остаётся максимальный контроль над тем, как итоговый чат будет выглядеть и работать.

Вот два из полудюжины опробованных нами сервисов:

Twilio Programmable Chat

Twilio — это такой огромный провайдер инфраструктуры для сообщений и телефонии. Вы этого может и не знаете, но скорее всего вы пользуетесь их услугами каждый день. Например, если вы используете Twitch, то вы используете Twilio.

У Twilio множество разных XaaS для самых разных сложных нужд, включая не так давно появившийся Programmable Chat.

Но у Twilio есть одна проблема: отсутствие заготовок для клиентов. Фокус компании — на предоставлении бакенда, а весь фронтенд нужно писать самому. А это значит, что нам всё равно пришлось бы разрабатывать свои мобильные и веб-приложения, форматирование и всё остальное.

Pusher Chatkit

Pusher тоже предоставляет разные API и используется безумным количеством компаний. В 2018 году Chatkit вышел из беты, и мы его попробовали. К сожалению, мы получили ровно тот же результат, что и с Twilio — набор удобных, классных API, стабильный бакенд и отсутствие готовых клиентских приложений.

Одно важное отличие Pusher Chatkit в том, что для их API есть примеры использования, очень сильно похожие на настоящий чат. Посмотрите, например, на Pusher Slack Clone React Demo — это уже то, чем почти можно пользоваться, если бы не ещё десяток нужных фич.

Однозначный плюс Pusher за наличие такого примера использования их API. Увы, мы используем VueJS и у нас по-прежнему нет возможности реализовывать все фичи самим.

Аналогично выглядят конкуренты Twilio и Pusher — удобные API и необходимость самим писать фронтенд. Выбирайте такой сервис, если вам действительно нужно полностью своё уникальное решение для чата (если вы пишите свой Телеграм, например). Нам такое не подошло.

Вариант 4: взять готовое Open Source решение

И, наконец, мы подходим к варианту, который мы рассматривали как основной, и на котором в итоге и остановились. В 2019 году любому крупному SaaS продукту есть отличная Open Source альтернатива, и чат тому не исключение. Но есть нюансы, и нам пришлось опробовать несколько разных проектов.

Zulip

Выброшенный в Open Source чат от Dropbox. Выглядел как очень привлекательная опция, но оттолкнул нас своим подходом к организации сообщений, каналов, чатов.

Rocket.Chat

Модный, свежий, с десятками самых разных фич и очень близкий к идеалу Rocket.Chat мы отмели по одной единственной сугубо технической причине. Будучи приверженцами простых и надёжных решений, мы не смогли пересилить себя и согласиться на хранение всей переписки в MongoDB, с эксплуатацией которой у нас нет особого опыта, как и нет желания разворачивать сразу несколько серверов только для БД.

Не считая этого, мы бы пожалуй и выбрали Rocket.Chat. Он отличный на вид и по ощущениями. Но его ближайший конкурент Mattermost покорил нас своей простотой и удобство не только внешне, но и внутренне.

Mattermost Team Edition

Разработчики Mattermost не сильно скрывают то, что делают клон Slack. А Open Source Slack — это ровно то, что нужно было mkdev, так как Slack содержит в себе полный набор нужных именно нам фич.

Помимо полного набора нужных фич, у Mattermost сразу же есть готовые мобильные приложения, которые можно просто взять и использовать со своим сервером Mattermost.

Нас также подкупила простота эксплуатации Mattermost — само приложение представляет собой единственный бинарный файл, а в качестве базы используется родной нам PostgreSQL, который мы крутим на AWS RDS. Возможность в два клика подключить хранение файлов на AWS S3 и отправку писем с AWS SES также сильно облегчает жизнь в вопросах поддержки сервиса.

Mattermost написан на знакомом команде mkdev Golang, а значит мы легко сможем при необходимости расширить сам продукт. Многообещающе выглядит поддержка плагинов, пока что находящаяся в бете.

Ну и то, до каких масштабов и кастомизации смогли довести Mattermost в Uber вселяет нам надежду, что и мы сможем построить с этим продуктом всё, что запланировали.

Довольны ли мы?

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

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

P.S. Доступ mkdev-клуб

Попасть в клуб mkdev можно несколькими способами:

  1. хоть раз оплатить обучение с нашими менторами;

  2. быть нашим ментором;

  3. быть стажёром mkdev;

  4. быть рекрутёром, который хочет доступ к большому числу качественно обученных кадров.

Если вы попадает под четвёртую категорию, то смело пишите нам на team@mkdev.me — пока что мы пускаем рекрутёров совершенно бесплатно.