Один бэкенд для веб‑ и мобильных приложений: практический план

Почему два приложения расходятся во взглядах

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

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

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

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

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

Именно поэтому важен общий бэкенд. Когда админ‑веб и полевое мобильное приложение делят записи, но не правила, система медленно распадается на две части.

Начните с одного общего процесса

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

Распространённая ошибка — проектировать админ‑веб и полевое мобильное приложение как два отдельных продукта. Это обычно создаёт две версии одного и того же процесса, два значения для одного статуса и дополнительные ручные правки позже. Рабочий процесс должен идти первым.

Используйте простой язык. Например: запрос создан, назначено, принято, в работе, приостановлено, завершено, проверено. Затем пройдитесь по каждому шагу и спросите, кто с ним работает. Некоторые шаги относятся к обеим ролям. Офисный сотрудник может назначить работу, а полевой сотрудник принять её на мобильном. Это — одна последовательность, а не две разные.

Сначала отметьте общие шаги

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

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

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

Рано определите единый источник правды для смены статусов. Если задача может перейти в состояние "Завершено" только после фото и подписи клиента, это правило должно жить в бэкенде. Оно не должно существовать только на мобильном экране или только в админ‑панели.

Простой тест: если одно и то же действие выполняется из любого приложения, должен ли результат быть идентичным? Если да — процесс общий. Если нет — бизнес‑правила, вероятно, спрятаны в интерфейсе.

Определите базовую модель данных

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

Полезный тест: могут ли два приложения расходиться во мнении о том, что истинно? Если да — модель разделена не в том месте. Бэкенд должен хранить единственный источник правды.

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

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

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

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

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

Держите бизнес‑правила вне экранов

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

Исправление простое: храните бизнес‑правила в бэкенде, и пусть оба приложения вызывают одну и ту же логику.

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

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

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

Как это выглядит на практике

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

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

Как планировать шаг за шагом

Начните с людей, а не с экранов. Опишите, кто использует систему, что они делают и какие у них есть права.

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

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

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

Простой порядок планирования

1. Перечислите основные действия для каждой роли пользователя.
2. Отметьте, какие данные каждое действие читает и изменяет.
3. Чётко определите правила статусов.
4. Сопоставьте каждый экран с точными данными, которые ему нужны.
5. Протестируйте модель на нескольких реальных задачах от начала до конца.

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

Чем должны отличаться приложения

Бэкенд остаётся общим, но опыт использования должен различаться. Админ‑веб и полевое мобильное приложение решают разные задачи, поэтому они должны показывать одни и те же записи по‑разному.

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

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

Одни и те же данные — разное представление

Ключевая идея проста: сохраняйте записи одинаковыми, меняйте раскладку под них. Если оба приложения используют одни и те же объекты задания, клиента, статуса и заметки, бизнес‑правила останутся в одном месте.

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

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

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

Простой практический сценарий

Представьте сервисную компанию по ремонту оборудования. Офис работает на ноутбуках, техники весь день в разъездах.

Диспетчер создаёт новое задание через админ‑веб: указывает имя клиента, адрес, детали проблемы, приоритет, время и назначенного техника. Это создаёт одну общую запись, а не отдельную веб‑версию задачи.

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

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

В офисе менеджер открывает админ‑веб и видит обновлённое задание. Он может принять работу, отправить на биллинг или назначить доработки. Никто не сравнивает две версии истины.

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

Частые ошибки, которых стоит избегать

Главная ошибка — дублировать одно и то же правило в двух местах. Если админ‑веб позволяет перейти от "Запланировано" к "В работе", а мобильное приложение делает такую же проверку отдельно, эти правила рано или поздно разойдутся. Держите смены статусов, права и обязательные проверки в бэкенде, чтобы оба приложения следовали одной логике.

Ещё одна ошибка — создавать отдельные записи для одной и той же работы. Так делают, когда хотят, чтобы офисный вид отличался от полевого. Потом админ‑приложение имеет "appointment", мобильное — "visit", и кто‑то поддерживает синхронизацию между ними. Это обычно приводит к разрозненным заметкам, дублирующимся обновлениям и путанице в том, какая запись — реальная.

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

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

Имена могут разрушить общую систему. Если одна команда называет шаг "Назначено", другая — "Отправлено", а третья — "Готово", люди начинают трактовать их как разные состояния. Согласуйте общий словарь как можно раньше и используйте его везде.

Хорошая эмпирическая проверка: одна задача — один источник правды, одно правило — одно место, один статус — одно понятное имя.

Быстрые проверки перед строительством

Перед началом постройте план на бумаге. Если модель можно объяснить за пару минут — обычно её достаточно просто поддерживать по мере роста обоих приложений.

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

Короткий чек‑лист:

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

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

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

Следующие шаги

Если вы хотите один бэкенд для веба и мобильных приложений, не начинайте с построения каждого экрана или сбора всех запросов команд. Начните с одного рабочего процесса, который важен ежедневно: создание задания, назначение, обновление статуса и закрытие. Маленький процесс легче тестировать, и он быстро покажет, где модель ясна, а где есть пробелы.

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

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

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

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

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

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