Написать свой мессенджер. Пишем свой мессенджер P2P

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

Используемые технологии и инструменты

  1. Стек MEAN (Mongo, Express, Angular, Node).
  2. Сокеты для прямого обмена сообщениями.
  3. AJAX для регистрации и входа.

Подготовка

Структура будущего приложения выглядит примерно так:

Схема должна получиться примерно следующего вида:

{ "_id" : ObjectId("5809171b71e640556be904ef"), "name" : "Monkey proger", "handle" : "mkproger", "password" : "proger228", "phone" : "8888888888", "email" : "[email protected]", "friends" : [ { "name" : "habrick", "status" : "Friend" }, { "name" : "javaman", "status" : "Friend" } ], "__v" : 0 }

Собеседникам могут быть присвоены следующие статусы:

  • Friend - собеседник является другом.
  • Pending - собеседник пока не принял запрос.
  • Blocked - собеседник заблокирован.

Предположим, что собеседник отклонил запрос на приватную беседу. В таком случае отправитель должен иметь возможность снова направить запрос.

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

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

Разработка мессенджера для смартфонов или сайта может стать успешным стартапом . Уже сейчас мессенджеры занимают первое место по количеству скачиваний в мире.

Стоит ли создавать еще одно приложение messenger?


У каждого пользователя на телефоне установлены два-пять мессенджеров. Все они используются в той или иной степени.

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

Рейтинг популярности мессенджеров

Источник vc.ru

Статистика роста количества пользователей мессенджеров показывает: потенциал у приложений для обмена сообщениями есть. Но при запуске стартапа нужно быть готовым к конкуренции. Разработка мессенджера для iOs или на Andriod начинается с правильной постановки задачи и подбора инструментов. Так мы получим приложение, которое удовлетворит потребности пользователей.


Как создать мессенджер, востребованный пользователями

Изначально мессенджеры создавались или как чаты, например WhatsApp, или как приложение для звонков - Skype, Viber. Позже в мессенджеры стали добавлять функции, которых изначально не было. Так, в WhatsApp добавились функции аудиозвонков, потом видео. Дальше появились открытые API, боты, маски, статусы, приемы платежей, публичные каналы. Однако внедрить новый функционал или изменить структуру, когда у мессенджера миллионы пользователей, сложно. В том же WhatsApp до сих пор нет API и ботов.

Основная сложность при создании приложения для отправки сообщений на Android или iOS - разработка архитектуры. Структуру приложения нужно разработать таким образом, чтобы в нее можно было безболезненно добавлять новые возможности.

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

Наш подход к разработке архитектуры мессенджера

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

В мы проектируем и разрабатываем архитектуру по принципам Clean architecture.

Чистая архитектура , описанная Робертом Мартином, позволяет спроектировать гибкую и масштабируемую систему.

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


Гибкость, масштабируемость и тестируемость

В процессе работы мы делаем так, чтобы архитектура делилась на автономные слои. Тогда бизнес-логика, представление и объекты данных разделены и могут меняться независимо друг от друга. Вне зависимости от размеров системы такой подход сохраняет ее гибкость, масштабируемость (масштабирование количества функций) и тестируемость.

Масштабируемым делаем не только код, но и саму инфраструктуру системы.

Производительность приложения

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

В процессе работы думаем о задаче клиента и с этим подходим к выбору инструментов.

Как правило, программируем на PHP. Этот язык программирования используется в Whatsapp, Facebook, Stackoverflow. PHP не уступает остальным языкам по производительности и способен выдержать высокие нагрузки. Плюс этого языка в том, что после выполнения задачи ресурсы сервера высвобождаются, а правильно построенная архитектура и хороший стек технологий перекрывают недостатки языка.

Стоимость разработки проекта на PHP в разы дешевле, чем на языках типа Java, Python. В то же время приложение не уступает по производительности.

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

Работа с большим количеством пользователей и большими нагрузками

В работе используем платформу NodeJS. Как показывает наш опыт, эта платформа подходит для создания чатов и мобильных приложений. NodeJS хорошо устроена и позволяет строить высоконагруженные системы. С коробки чат на NodeJS способен выдержать нагрузку в 10 000 подключений.

Разработка мессенджера для Android или iOS под данную платформу требует использовать Java Script. Этот язык популярен, поэтому найти разработчиков не проблема.

Rethink - используем эту NoSQL DB, так как она производительнее конкурентов. У RethinkDB транслятор языка запросов, так называемого ReQL, реализован не на уровне сервера, а встраивается в качестве предметно-ориентированного языка в язык, на котором пишется клиентское приложение.

Таблицы базы данных хранят JSON-документы, допускающие любой уровень вложенности. У каждого документа прописан уникальный для таблицы-родителя первичный ключ «id». Ссылаясь на ключ, получаем документ. Каждая функция ReQL-запроса работает с данными, полученными из предыдущей функции цепочки. Это позволяет строить более гибкую архитектуру высоконагруженных проектов и не думать о сложности структур данных.

Конкурент NoSQL СУБД - MongoDB. Эта платформа популярна на рынке, но популярность не всегда залог успеха. У MongoDB ряд проблем: при удалении документов не чистится место на диске поэтому приложение должно быть построено так, чтобы документы (файлы объектов) не удалялись часто. Также MongoDB плохо работает с многочисленными массовыми операциями над документами, что противоречит правилам построения высоконагруженной системы.

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


Разработка интерфейса мессенджера

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

При разработке дизайна важно:

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

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

    Все возможные ошибки, например, если пропал интернет, пользователь должен понять, что что-то пошло не так.

    Для верификации номера телефона поставить ограничение по времени на повторную отправку sms с кодом верификации, так как сообщение может еще не дойти, а пользователь успеет шесть раз нажать на повторную отправку кода.

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




Удобство внутри чата и предотвращение нелепых ошибок

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

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

Приватность

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

Здесь есть нюансы. Скажем для полного анонимного чата собеседники без привязки к конкретным признакам — номеру телефона, имени, локации — должны понимать кто есть кто. Для этого нужно использовать одноразовый шифр, которым могут пользоваться все, но он не будет повторятся дважды. Приглашение людей в такую беседу, также происходит при помощи “ключа”, который работает только раз, и задается только самим человеком.

Защита от скриншотов. Шифрование приходящих уведомлений. Возможность быстро удалять сообщения, без лишних подтверждений.


Сколько стоит создать свой мессенджер

Цена разработки мессенджера зависит от того, сколько времени займет работа над приложением. Чем сложнее функционал, тем выше стоимость разработки. Окончательную цену на разработку мессенджера для iOS, андроид или сайта мы сможем назвать только после того, как поймем, какие задачи надо решить.

Стоимость продвижения и поддержки

Разработка мессенджера для Андроид или для iOS - первый этап. Если это не корпоративный чат, то мессенджер надо продвигать. Для этого надо в маркетинговый бюджет заложить определенную сумму. Сюда входит:

    ASO-продвижение (App Store Optimization) - комплекс работ для оптимизации мобильного приложения. А именно правильное составление title (название), keywords (ключевые слова), descriptions (описание), в целях максимального увеличения видимости вашего приложения в поиске

    Оплата за размещение в магазинах Google Play и App Store.

После запуска приложение необходимо развивать и обновлять:

    Устранить ошибки и реагировать на поступившие жалобы пользователей

    Добавить новые функции.

С чего начать создание приложения для отправки сообщений на Android или iPhone

Разработка мессенджера под заказ начинается с постановки задачи.

Напишите или позвоните нам, мы договоримся о встрече, обсудим задачу и поможем найти оптимальное решение как создать востребованный мессенджер для Android и iOS.

Нам понадобится:
- один сервер с белым статическим IP адресом;
- 2 компьютера за NAT с типом соединения Full Cone NAT (либо 1 компьютер с 2-мя виртуальными машинами);
- STUN-сервер.

Full Cone NAT - это такой тип преобразования сетевых адресов, при котором существует однозначная трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт».

Вот, что мы можем прочесть о STUN-сервере на Wiki :

«Существуют протоколы, использующие пакеты UDP для передачи голоса, изображения или текста по IP-сетям. К сожалению, если обе общающиеся стороны находятся за NAT’ом, соединение не может быть установлено обычным способом. Именно здесь STUN и оказывается полезным. Он позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта.»

При решении задачи использовались следующие питоновские модули: socket, twisted, stun, sqlite3, os, sys.

Для обмена данными, как между Сервером и Клиентом, так и между Сервером, Клиентом и Сигнальным Сервером - используется UDP протокол.

В общих чертах механизм функционирования выглядит так:

Сервер <-> STUN сервер
Клиент <-> STUN сервер

Сервер <-> Сигнальный Сервер
Клиент <-> Сигнальный Сервер

Клиент -> Сервер

1. Клиент, находясь за NAT с типом соединения Full Cone NAT, отправляет сообщение на STUN сервер, получает ответ в виде своего внешнего IP и открытого PORT;

2. Сервер, находясь за NAT с типом соединения Full Cone NAT, отправляет сообщение на STUN сервер, получает ответ в виде своего внешнего IP и открытого PORT;

При этом, Клиенту и Серверу известен внешний (белый) IP и PORT Сигнального Сервера;

3. Сервер отправляет на Сигнальный Сервер данные о своих внешних IP и PORT, Сигнальный Сервер их сохраняет;

4. Клиент отправляет на Сигнальный Сервер данные о своих внешних IP и PORT и id_destination искомого Сервера, для которого ожидает его внешний IP, PORT.

Сигнальный Сервер их сохраняет, осуществляет поиск по базе, используя id_destination и, в ответ, отдает найденную информацию в виде строки: "id_host, name_host, ip_host, port_host";

5. Клиент принимает найденную информацию, разбивает по разделителю и, используя (ip_host, port_host), отправляет сообщение Серверу.

Приложения написаны на Python версии 2.7, протестированы под Debian 7.7.

Создадим файл server.py с содержимым:

server.py

# -*- coding: utf-8 -*- #SERVER from socket import * import sys import stun def sigserver_exch(): # СЕРВЕР <-> СИГНАЛЬНЫЙ СЕРВЕР # СЕРВЕР <- КЛИЕНТ # СЕРВЕР - отправляет запрос на СИГНАЛЬНЫЙ СЕРВЕР с белым статическим IP со своими данными о текущих значениях IP и PORT. Принимает запрос от КЛИЕНТА. #Внешний IP и PORT СИГНАЛЬНОГО СЕРВЕРА: v_sig_host = "XX.XX.XX.XX" v_sig_port = XXXX #id этого КЛИЕНТА, имя этого КЛИЕНТА, id искомого СЕРВЕРА v_id_client = "id_server_1002" v_name_client = "name_server_2" v_id_server = "none" #IP и PORT этого КЛИЕНТА v_ip_localhost = "XX.XX.XX.XX" v_port_localhost = XXXX udp_socket = "" try: #Получаем текущий внешний IP и PORT при помощи утилиты STUN nat_type, external_ip, external_port = stun.get_ip_info() #Присваиваем переменным белый IP и PORT сигнального сервера для отправки запроса host_sigserver = v_sig_host port_sigserver = v_sig_port addr_sigserv = (host_sigserver,port_sigserver) #Заполняем словарь данными для отправки на СИГНАЛЬНЫЙ СЕРВЕР: #текущий id + имя + текущий внешний IP и PORT, #и id_dest - укажем "none" #В качестве id можно использовать хеш случайного числа + соль data_out = v_id_client + "," + v_name_client + "," + external_ip + "," + str(external_port) + "," + v_id_server #Создадим сокет с атрибутами: #использовать пространство интернет адресов (AF_INET), #передавать данные в виде отдельных сообщений udp_socket = socket(AF_INET, SOCK_DGRAM) #Присвоим переменным свой локальный IP и свободный PORT для получения информации host = v_ip_localhost port = v_port_localhost addr = (host,port) #Свяжем сокет с локальными IP и PORT udp_socket.bind(addr) print("socket binding") #Отправим сообщение на СИГНАЛЬНЫЙ СЕРВЕР udp_socket.sendto(data_out,addr_sigserv) while True: #Если первый элемент списка - "sigserv" (сообщение от СИГНАЛЬНОГО СЕРВЕРА), #печатаем сообщение с полученными данными #Иначе - печатаем сообщение "Message from CLIENT!" data_in = udp_socket.recvfrom(1024) if data_in == "sigserv": print("signal server data: ", data_in) else: print("Message from CLIENT!") #Закрываем сокет udp_socket.close() except: print("exit!") sys.exit(1) finally: if udp_socket <>


Создадим файл client.py с содержимым:

client.py

# -*- coding: utf-8 -*- # CLIENT from socket import * import sys import stun def sigserver_exch(): # КЛИЕНТ <-> СИГНАЛЬНЫЙ СЕРВЕР # КЛИЕНТ -> СЕРВЕР # КЛИЕНТ - отправляет запрос на СИГНАЛЬНЫЙ СЕРВЕР с белым IP # для получения текущих значений IP и PORT СЕРВЕРА за NAT для подключения к нему. #Внешний IP и PORT СИГНАЛЬНОГО СЕРВЕРА: v_sig_host = "XX.XX.XX.XX" v_sig_port = XXXX #id этого КЛИЕНТА, имя этого КЛИЕНТА, id искомого СЕРВЕРА v_id_client = "id_client_1001" v_name_client = "name_client_1" v_id_server = "id_server_1002" #IP и PORT этого КЛИЕНТА v_ip_localhost = "XX.XX.XX.XX" v_port_localhost = XXXX udp_socket = "" try: #Получаем текущий внешний IP и PORT при помощи утилиты STUN nat_type, external_ip, external_port = stun.get_ip_info() #Присваиваем переменным белый IP и PORT сигнального сервера для отправки запроса host_sigserver = v_sig_host port_sigserver = v_sig_port addr_sigserv = (host_sigserver,port_sigserver) #Заполняем словарь данными для отправки на СИГНАЛЬНЫЙ СЕРВЕР: #текущий id + имя + текущий внешний IP и PORT, #и id_dest - id известного сервера с которым хотим связаться. #В качестве id можно использовать хеш случайного числа + соль data_out = v_id_client + "," + v_name_client + "," + external_ip + "," + str(external_port) + "," + v_id_server #Создадим сокет с атрибутами: #использовать пространство интернет адресов (AF_INET), #передавать данные в виде отдельных сообщений udp_socket = socket(AF_INET, SOCK_DGRAM) #Присвоим переменным свой локальный IP и свободный PORT для получения информации host = v_ip_localhost port = v_port_localhost addr = (host,port) #Свяжем сокет с локальными IP и PORT udp_socket.bind(addr) #Отправим сообщение на СИГНАЛЬНЫЙ СЕРВЕР udp_socket.sendto(data_out, addr_sigserv) while True: #Если первый элемент списка - "sigserv" (сообщение от СИГНАЛЬНОГО СЕРВЕРА), #печатаем сообщение с полученными данными и отправляем сообщение #"Hello, SERVER!" на сервер по указанному в сообщении адресу. data_in = udp_socket.recvfrom(1024) data_0 = data_in data_p = data_0.split(",") if data_p == "sigserv": print("signal server data: ", data_p) udp_socket.sendto("Hello, SERVER!",(data_p,int(data_p))) else: print("No, it is not Rio de Janeiro!") udp_socket.close() except: print ("Exit!") sys.exit(1) finally: if udp_socket <> "" udp_socket.close() sigserver_exch()


Заполним соответствующие поля разделов: «Внешний IP и PORT СИГНАЛЬНОГО СЕРВЕРА» и «IP и PORT этого КЛИЕНТА».

Создадим файл signal_server.py с содержимым:

signal_server.py

# -*- coding: utf-8 -*- # SIGNAL SERVER #Twisted - управляемая событиями(event) структура #Событиями управляют функции – event handler #Цикл обработки событий отслеживает события и запускает соответствующие event handler #Работа цикла лежит на объекте reactor из модуля twisted.internet from twisted.internet import reactor from twisted.internet.protocol import DatagramProtocol import sys, os import sqlite3 class Query_processing_server(DatagramProtocol): # СИГНАЛЬНЫЙ СЕРВЕР <-> КЛИЕНТ # КЛИЕНТ -> СЕРВЕР # либо # СИГНАЛЬНЫЙ СЕРВЕР <-> СЕРВЕР # СИГНАЛЬНЫЙ СЕРВЕР - принимает запросы от КЛИЕНТА и СЕРВЕРА # сохраняет их текущие значения IP и PORT # (если отсутствуют - создает новые + имя и идентификатор) # и выдает IP и PORT СЕРВЕРА запрошенного КЛИЕНТОМ. def datagramReceived(self, data, addr_out): conn = "" try: #Разбиваем полученные данные по разделителю (,) #id_dest - искомый id сервера data = data.split(",") #Запрос на указание пути к файлу БД sqlite3, при отсутствии будет создана новая БД по указанному пути: path_to_db = raw_input("Enter name db. For example: "/home/user/new_db.db": ") path_to_db = os.path.join(path_to_db) #Создать соединение с БД conn = sqlite3.connect(path_to_db) #Преобразовывать байтстроку в юникод conn.text_factory = str #Создаем объект курсора c = conn.cursor() #Создаем таблицу соответствия для хостов c.execute("""CREATE TABLE IF NOT EXISTS compliance_table ("id_host" text UNIQUE, "name_host" text, "ip_host" text, \ "port_host" text)""") #Добавляем новый хост, если еще не создан #Обновляем данные ip, port для существующего хоста c.execute("INSERT OR IGNORE INTO compliance_table VALUES (?, ?, ?, ?);", data) #Сохраняем изменения conn.commit() c.execute("SELECT * FROM compliance_table") #Поиск данных о сервере по его id c.execute("""SELECT id_host, name_host, ip_host, port_host from compliance_table WHERE id_host=?""", (data,)) cf = c.fetchone() if cf == None: print ("Server_id not found!") else: #transport.write - отправка сообщения с данными: id_host, name_host, ip_host, port_host и меткой sigserver lst = "sigserv" + "," + cf + "," + cf + "," + cf + "," + cf self.transport.write(str(lst), addr_out) #Закрываем соединение conn.close() except: print ("Exit!") sys.exit(1) finally: if conn <> "" conn.close() reactor.listenUDP(9102, Query_processing_server()) print("reactor run!") reactor.run()

Порядок запуска приложения следующий:
- signal_server.py
- server.py
- client.py

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

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

Как мы пришли к этой идее?

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

Допустим, вы хотите сделать приложение а-ля Авито, где люди выкладывают объявления по продаже б/у товаров. Покупатель листает ленту или находит нужный ему товар, ему не нужно ждать отклика на заявку, он сразу же напрямую ведет диалог с продавцом и договаривается о встрече. Быстро, удобно, без кучи созвонов и поиска контакта в WhatsApp или Telegram.

Осознав все плюсы мессенджеров, основанных на общении между людьми, мы решили зайти дальше. Мы подумали: «Что получится, если мессенджер не будет загоняться в жесткие рамки, а будет иметь возможность включать в себя различные функции?» Получится новое коробочное решение а-ля "поставить аналог вотсапа себе на сервер с возможностью доработок". Несомненный плюс данного решения в том, что стоить оно будет явно меньше, чем в других студиях при разработке с нуля (за аналог WhatsApp в среднем называется стоимость от 45000$ до 55000$). Это позволит вам протестировать вашу идею по адекватной цене и решить, взлетает проект или нет.

Что уже включает коробочное решение?

  • Регистрация и авторизация по номеру телефона
  • Профиль пользователя, он может заполнить ФИО и поставить свое фото
  • Список пользователей, контакты
  • Список диалогов
  • Окно Чата
  • Статус сообщения

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

Архитектура приложения выглядит следующим образом:

  • Objective-C и Java для iOS и Android приложения
  • Node.js - держим сокет-соединения для получения сообщений в режиме реального времени
  • Redis -храним стек сообщений для отправки
  • APN/FCM push-сервер используем для отправки push-уведомлений, если приложение свёрнуто
  • Bitrix.Framework для генерации экранов мобильного приложения и гибкого развития приложения
  • MySQL - для хранения пользователей, ролей доступа, историй сообщений и кастомизированных данных приложения
  • 1С-Битрикс - для административного управления мессенджером

Работа с конкретными задачами

Мой знакомый, Павел, не так давно обратился к нам за помощью. Он владеет консалтинговым агентством, специализирующимся на повышении продаж оптовиков и производств. Его проблема заключалась в том, что после завершения консалтинга, клиент переходил на консультации его помощников. Это, в конечном счете, отражалось на качестве оказываемых услуг, а также на прибыли: из-за ошибок помощников Павел недополучал по 50-100 тысяч рублей в месяц.

Мы с ним пришли к модели, что при внедрении месседжера он сможет получить вот такие ценности:

  • Удалённо оказывать консультационные услуги лично, без потери качества
  • Сделать видео-ответы на 40 самых популярных вопросов клиентов и, в случае возникновения очередного вопроса из этого стека, отправлять ссылку на видео клиенту без дополнительных трудозатрат
  • Сэкономить на зарплатах помощников
  • Увеличить пропускную способность услуги
  • Использовать консультации в приложении, как вау-эффект для новых продаж основного продукта

Пообщавшись, мы пришли к выводу, что к базовому функционалу потребуется несколько дополнительных экранов:

  1. Групповой чат (чтобы клиенты "заряжали" друг друга)
  2. Экран с тарифами услуг компании

Плюсом добавился брендированный под фирменный стиль компании дизайн. С учётом наших цен приложение вышло чуть дороже 100 тыс. Причём, без привязки к нам. Любой php-разработчик, знакомый с Bitrix.Framework смог бы сделать эти доработки под Павла. На данный момент приложение дорабатывается, но можно посмотреть линкованные мокапы будущего приложения.

Перспективы развития

Ввиду того, что проект нашего мессенджера в первую очередь является стартапом, мы развиваем его в формате Customer Development. За полторы недели, прошедших с момента запуска проекта, уже продано 9 лицензий. Попробовавшие наше коробочное решение клиенты предложили развиваться в следующих направлениях:

  1. разработка функции добавления в окна чата различных мультимедиа (фото, видео, файлы), активных ссылок;
  2. работа над улучшением дизайна;
  3. создание групповых чатов.

Что думаете по поводу развития данного проекта? Стоит ли активно добавлять функционал или лучше оставить гибкость платформы, при которой любой программист сможет доработать приложение под клиента?

Если вас заинтересовало наше новое коробочное предложение, то пишите мне на почту . Буду рад ответить вам на любые вопросы.