Как мы сделали коробочное решение для запуска мессенджера
Последнее время мы в Bright Mobile видим рост обращений на разработку приложений, где в основе лежит общение между пользователями.
Решили сделать собственный модуль c функционалом общения, где ключевой фишкой будет возможность добавить дополнительную логику к этому мессенджеру. Например, сделать агрегатом новостных лент с обсуждением, сервис заказа услуг, приложение для консалтингового агентства и т.д.
Идея создания
В этой статье я расскажу вам об идее создания мессенджера. В одно время, мы увидели большой спрос на реализацию мессенджера, но не чат ботов как, допустим, в Telegram, а приложения, в основе которого лежит переписка между людьми, т.е. в базисе лежит собственный мессенджер. Допустим, вы хотите сделать приложение а-ля Авито, где люди выкладывают объявления по продаже б/у товаров. Покупатель листает ленту или находит нужный ему товар, ему не нужно ждать отклика на заявку, он сразу же напрямую ведет диалог с продавцом и договаривается о встрече. Быстро, удобно, без кучи созвонов и поиска контакта в WhatsApp или Telegram.
У нас возникла идея о том, что можно сделать счастливыми намного больше людей, запустив коробочное решение, но, не загоняя в жёсткие рамки мессенджера, а с возможностью добавлять различные функции. Плюсы такой модели в том, что её стоимость на порядок меньше, чем во многих студиях. В основном, гуглятся статьи, где предлагается разработка с нуля и за аналог WhatsApp в среднем называется стоимость от 45000$ до 55000$. Это огромная сумма, и вряд ли она обоснована на этапе тестирования идеи приложения. Решили, что можно сделать готовое (коробочное) решение по адекватной цене. Наша платформа мессенджера – это, в первую очередь, MVP для стартапов, во-вторую возможность создать добавочную стоимость бизнесу.
Что уже есть?
- Регистрация и авторизация по номеру телефона
- Профиль пользователя, он может заполнить ФИО и поставить свое фото
- Список пользователей, контакты
- Список диалогов
- Окно Чата
- Статус сообщения
Самый важный момент состоит в том, что – это не «жёсткое» коробочное решение, а платформа для развития. Мы даем основу, к которой можно добавить, к примеру, ленту новостей, группы, просмотр видео, фото и т.д. То есть, в дальнейшем, можно добавлять туда что угодно, в зависимости от целей и бизнес-процессов.
Архитектура приложения выглядит следующим образом:
Objective-C и Java для iOS и Android приложения
Node.js - держим сокет-соединения для получения сообщений в режиме реального времени
· Redis -храним стек сообщений для отправки
APN/FCM push-сервер используем для отправки push-уведомлений, если приложение свёрнуто
Bitrix.Framework для генерации экранов мобильного приложения и гибкого развития приложения
MySQL - для хранения пользователей, ролей доступа, историй сообщений и кастомизированных данных приложения
1С-Битрикс - для административного управления мессенджером
Модернизация под конкретные задачи
Недавно к нам обратился мой знакомый - Павел. У него собственное консалтинговое агентство, которое специализируется на повышении продаж оптовиков и производств. У него была проблема. Когда основной консалтинг завершён, то на поддержку клиент переходит к его подчинённому, а это серьёзно сказывалось на качестве оказываемых услуг. Павел рассказал, что ежемесячно недополучает 50 - 100 тысяч просто из-за того, что кто-то из помощников косячит. Мы с ним пришли к модели, что при внедрении месседжера он сможет получить вот такие ценности:
- Удалённо оказывать консультационные услуги лично, без потери качества
- Сделать видео-ответы на 40 самых популярных вопросов клиентов и, в случае возникновения очередного вопроса из этого стека, отправлять ссылку на видео клиенту без дополнительных трудозатрат
- Сэкономить на зарплатах помощников
- Увеличить пропускную способность услуги
- Использовать консультации в приложении, как вау-эффект для новых продаж основного продукта
Пообщавшись, мы пришли к выводу, что к базовому функционалу потребуется несколько дополнительных экранов:
- Групповой чат (чтобы клиенты "заряжали" друг друга)
- Экран с тарифами услуг компании
Плюсом добавился брендированный под фирменный стиль компании дизайн. С учётом наших цен приложение вышло чуть дороже 100 тыс. Причём, без привязки к нам. Любой php-разработчик, знакомый с Bitrix.Framework смог бы сделать эти доработки под Павла. На данный момент приложение дорабатывается, но можно посмотреть линкованные мокапы будущего приложения.
Обновления
В первую очередь наш проект мессенджера - это стартап. Поэтому мы его развиваем в формате Customer Development. На данный момент, за полторы недели, мы продали 9 лицензий. Купившие клиенты проголосовали за развитие в следующем направлении:
- Возможность добавлять в окне чата фото, видео, файлы, делать активные ссылки
- "Причесать" дизайн
- Сделать групповые чаты
Как вы видите развитие этого проекта? Стоит ли активно добавлять функционал или лучше оставить гибкость платформы, при которой любой программист сможет доработать приложение под клиента?
Objective-C и Битрикс? Серьёзно? 😞
Я тоже так подумал.
Почему не swift или даже react-native?
Зачем там Битрикс? Почему Redis?
Как это все масштабируется?
Вопросов много
Swift это или Objective-C в оболочке гибридного мобильного приложения не столь важно, это всего лишь WKWebView.
React-Native разработчиков достаточно сложно найти, а вот вебщиков на php/js/html полно.
Битрикс тут как раз с точки зрения генерации веб странички для гибрида, которую очень легко править и адаптировать под свой проект.
Redis, ну тут не знаю что вас смущает, производительная NoSQL база для хранения очереди сообщений.
По масштабированию: битрикс генерит странички интерфейса, поэтому оставляем на php/html, чтобы было просто вебщикам править. А вот загрузку сообщений на NodeJS через socket для нормальных нагрузок.
Я его слепила из того, что было (с)
Да. Я ещё добавлю сюда страшное слово гибрид :) чтоб совсем страшно стало.
Всем, кто решит писать свой чат, настоятельно рекомендую рассмотреть Tinode.
OpenSource, GPL3.
Я бы порекомендовал пользоваться Firebase, а не пилить свой велик.
Отвечая на вопрос - модульность никто не отменял, делаете базовую версию, ядро и возможность прикручивать дополнительные модули - если и двигаться раньше, то в этом направлении.
На FireBase сложно делать и развивать гибридное приложение. А про модульность - да, так и делаем
Это худший стек и архитектура для чата какие только можно было придумать. Почему битрикс? Для чего поверх битрикс ещё и nodejs?
Почему поверх то? Рядом тогда уж. Конструктивно по поводу битрикса написал Евгений Малаховский выше