Разработка приложения на базе сайта

Денис Гордиенко, генеральный директор Bright Mobile, о разработке приложения на базе сайта

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

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

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

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

Классический подход программистов к разработке выглядит так:

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

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

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

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

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

Мы выбрали ситуацию, когда со стороны сайта дописывается блок необходимых модулей, и вся эта штука общается с приложением через REST API. С 1С приложение мы не цепляем, используя то, что уже сделали штатные разработчики клиента: мы изменяем текущую систему по минимуму, чтобы они и дальше могли адекватно поддерживать собственную инфраструктуру. Что-то для работы приложения всё равно нужно будет переписать, но не больше 5% от всего объёма инфраструктуры.

Серверная часть будет заключаться только в том, что мы дописываем отдельным модулем REST API к их текущей инфраструктуре и необходимые дополнения, которых на сафте нет. Таким образом мы убиваем сразу двух зайцев:

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

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

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

Описанный случай – яркий пример того, как можно разработать рабочую схему не «по учебнику», потратить меньше денег, времени и нервов и при аналогичном по качеству результате. Такой подход выгоден экономически, удобен с точки зрения бизнес-процесса и проще для самих разработчиков.