Проектируем админку для биржи услуг

Раньше я рассказывал, как пишу ТЗ для сайта с идеей биржи услуг, на основе готового приложения, и анализировал раскрученные площадки, чтобы понять что имеет смысл брать в "коробку". А сейчас решил написать размышления про админку и показать что уже сделали.

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

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

Как это работает сейчас: есть облачный сервер на firebase, есть мобильные приложения iOS и Android. Приложения подключаются к серверу на firebase, где реализована вся серверная инфраструктура.

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

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

При этом, всю построенную архитектуру проекта нужно администрировать. Админка Firebase показалась клиентам слишком сложной. Кроме того она должна быть дешёвой в поддержке, ведь доработки в проекте требуют и постоянных доработок админки. Платить в этом случае по ставке Angular-разработчика было бы слишком накладно.

Здесь мы вспомнили про 1С-Битрикс, которым пользовались больше трех лет в предыдущем коробочном решении и решили его использовать, как серверную часть и админку для данных не требующих реального времени. В Битриксе у нас хранятся все три сущности: заявки, мастера, заказчики. Просто три инфоблока, которые можно менять через панель администратора. А переписки мы оставляем на firebase.

Что делаем на Битриксе:

• Управление заявками
• Управление мастерами
• Управление категориями
• Отправка Пользовательского соглашения в html
• Отправка О сервисе в html

Списочные разделы делаются инфоблоками, а контент - это просто редактируемые страницы. Обмен данных с приложением сделан по REST API из 10 методов

Что оставляем на Firebase:

• Авторизация по СМС (бесплатные 10 000 СМС в месяц)
• Push-уведомления через FCM
• Мессенджер (тут срочность важна)
• Обработка откликов на задания (тут тоже желательно сохранить скорость)

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

Модерация. Теперь есть возможность удаления спама и некорректных мастеров.

Уточнение заявки. Часто бывает, что идея проекта не просто в сведении заказчика с исполнителем, а ещё и в уточнении задачи на стороне сервиса. То есть в панели администратора будет сидеть менеджер, который дополняет заявку и мастер получает более развёрнутое задание.

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

Удешевление поддержки. Большинство работ по доработкам как раз связаны с той частью, которую мы вынесли в Битрикс. Разница стоимости часа Ангуларовца и Битриксиста примерно 30%. Это значит, что серверные функции можно будет заказать дешевле.

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