Мобильное приложение к существующей платформе: как не переписывать бэкенд

«Чтобы сделать мобильное приложение, придётся переписать бэкенд» — эту фразу слышит почти каждый, у кого платформа уже работает: образовательная, медицинская, торговая, учётная. Иногда она верна. Гораздо чаще она означает другое: система годами отдавала данные одному потребителю — собственному сайту, — а теперь у неё появляется второй, с другими привычками.

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

Договоримся о словах сразу, иначе разговор с подрядчиком пойдёт мимо. «Переписать» — значит заменить ядро системы и перенести на него всё, что в нём живёт. «Достроить» — значит оставить ядро нетронутым и добавить к нему слои, которых в нём не было, потому что ими некому было пользоваться. Разница между двумя работами не в процентах: в первом случае развитие основного продукта останавливается на месяцы, во втором продолжается параллельно.

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

Приложению страница не нужна. Ему нужны данные и правила: список занятий, остаток на складе, статус заказа, роль вошедшего. Интерфейса, который отдаёт именно это, может просто не оказаться — и ревизия на старте заканчивается выводом «у нас нет API». Вывод верный, но он не означает «надо переписать»: он означает, что у системы не было второго потребителя.

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

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

Масштаб, до которого это доходит, виден по кейсу GrandeBoutique.ru: в карточке проекта записано «более 30 интеграций» при каталоге свыше 35 000 товарных позиций. Приложению столько не нужно, но и в скромном проекте потоков обычно набирается семь-восемь там, где рассчитывали на один: это наша рабочая прикидка, а не замер по кейсам.

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

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

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

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

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

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

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

Обратное направление дороже. Фотография из камеры — это не «загрузить файл»: это ориентация кадра, вес, сжатие на устройстве, очередь на отправку и повтор после обрыва. В кейсе EdPro задача звучала прямо — сделать решение, работающее даже при нестабильном интернете; и это была часть исходной постановки, а не улучшение по ходу. Полный офлайн — отдельное решение: локальная копия данных означает конфликты при синхронизации, а их разбор — это проектирование, а не строчка в задании.

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

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

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

Академия дополнительного профессионального образования EDPRO входит в Топ-3 компаний сегмента: более 10 000 выпускников, общая аудитория продуктов свыше 150 000 человек. Её платформа уже работала в настольном формате, на основе веб-клиента.

Задача в кейсе сформулирована так: не «упаковать сайт в приложение», а переосмыслить опыт на мобильных устройствах — расписание, оценки, материалы курсов, связь с преподавателями в одном интерфейсе, с работой при нестабильном интернете.

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

Результат в кейсе зафиксирован сдержанно: более тысячи установок в первые месяцы, оценка 4,4 в App Store, приложением ежедневно пользуются студенты. И строка из отзыва заказчика, которая здесь важнее цифр: продукт без проблем взяли к себе и продолжают развивать. Ядро платформы при этом не переписывалось, а вся работа по карточке проекта заняла менее двенадцати месяцев.

Второй порядок — когда сначала запускают сайт, а приложение приходит следующим шагом. Московский концепт-стор SHI TRENDY в 2020 году ушёл от продаж через соцсети и собрал собственный интернет-магазин; приложение стало следующим этапом.

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

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

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

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

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

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

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

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

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

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