Общие правила валидации для веб и мобильных клиентов

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

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

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

Именно поэтому общие правила валидации важны. Без них каждый клиент становится своей версией истины.

Как выглядит рассинхронизация на практике

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

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

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

Само правило редко является настоящей проблемой. Проблема в том, что одно и то же правило живёт в слишком многих местах.

Что должно оставаться одинаковым везде

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

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

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

Бизнес-правила важны не меньше. Если пользователь должен быть старше определённого возраста, принадлежать к поддерживаемому региону или иметь определённый статус аккаунта, эти проверки должны работать одинаково на каждом экране.

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

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

Пусть backend принимает окончательное решение

Быстрая обратная связь на фронтенде полезна, но она не должна быть последним словом. Окончательное решение о валидности данных должен принимать backend.

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

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

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

Пара примеров достаточно:

• required для отсутствующих полей
• invalid_format для плохого шаблона email или телефона
• out_of_range для значений выше или ниже лимитов
• not_allowed для проверок по правам или статусу
• already_exists для дублирующихся email, логинов или ID

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

Хороший тест для backend прост: если кто‑то пропускает UI и отправляет запрос прямо в API, те же некорректные данные должны быть отклонены по той же причине.

Создайте единый источник правды

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

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

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

Это делает изменения безопаснее. Если бизнес решает, что номер телефона стал необязательным, вы обновляете одно общее определение вместо того, чтобы искать iPhone, Android, веб и админские экраны.

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

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

Если вы строите с AppMaster, такой подход естественен: backend-логика, веб‑приложения и нативные мобильные приложения можно управлять в одной no-code платформе. Идея остаётся той же: пишите правило один раз, держите его центральным и позвольте всем клиентам следовать ему.

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

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

Сначала перечислите каждое поле и опишите его простым языком. Укажите, какое значение оно принимает, обязательно ли оно, в каком формате должно быть и какие бизнес‑условия к нему применимы. «Email обязателен» недостаточно, если одно приложение принимает плохой формат, а другое блокирует его.

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

Простой порядок действий работает хорошо:

1. Напишите список правил по каждому полю.
2. Поместите правила сначала в backend-валидацию.
3. Добавьте те же проверки на фронтенде в вебе.
4. Добавьте такие же проверки в мобильном приложении.
5. Протестируйте одни и те же примеры ввода везде.

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

Пример: форма регистрации клиента

Форма регистрации хорошо демонстрирует это. Представьте, что форма содержит три поля: email, пароль и дата рождения.

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

Правило по паролю должно совпадать точно. Если минимально требуется 8 символов, то это правило должно действовать везде — не 6 в вебе и 10 в мобильном. Небольшие несовпадения быстро вводят пользователей в заблуждение, особенно при переключении устройств.

Дата рождения — это то место, где бизнес-логика часто расходится. Если продукт разрешает регистрацию только пользователям старше 18 лет, оба клиента должны использовать одно и то же правило отсечения и одно и то же определение «сегодня». Иначе один пользователь одобрён в вебе, а в приложении — отклонён.

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

Сообщения тоже должны оставаться понятными и согласованными. Хорошие примеры: «Введите адрес электронной почты», «Введите корректный адрес электронной почты», «Пароль должен содержать не менее 8 символов» и «Аккаунт с таким email уже существует». Когда пользователи видят одинаковые формулировки везде, поддержке проще работать, и доверие растёт.

Ошибки, которые вызывают рассинхронизацию

Большинство проблем с валидацией не возникают из‑за одного явного сломанного правила. Они накапливаются из‑за мелких несовпадений.

Одна распространённая ошибка — спрятанное правило в одном клиенте. iPhone-приложение может требовать номер телефона, а веб — считать его необязательным. Ещё одна ошибка — использовать разные шаблоны для одного и того же поля. Веб-форма может позволять пробелы в почтовом индексе, а Android-библиотека блокировать их, или одно приложение допускает знак «+» в телефонном номере, а другое его удаляет.

Более серьёзная проблема — чрезмерное доверие UI. Клиентская валидация помогает пользователю исправить ошибки быстрее, но её недостаточно. Старые приложения, особенности браузера и прямые запросы к API могут отправить плохие данные, если backend не применяет те же бизнес-ограничения.

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

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

Проверки перед релизом, которые ловят проблемы

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

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

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

Проверка на backend важнее всего. Если кто‑то обходил UI, использует старое приложение или отправляет данные прямо в API, результат должен оставаться безопасным и предсказуемым.

Также полезно сравнить тексты ошибок рядом. Если веб пишет «Введите корректный email», а мобильный — «Неизвестная ошибка», люди подумают, что приложения ведут себя по‑разному, даже если правило одно и то же.

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

Чистые следующие шаги

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

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

Пишите правила простым языком. Вместо «validate customer status» пишите «Бизнес-клиенты должны указать ИНН» или «Номер телефона необязателен, если не включены SMS‑уведомления». Чёткие формулировки помогают дизайнерам, разработчикам, тестировщикам и поддержке заметить разрывы до релиза.

Если хотите сократить дублирование работы, AppMaster может помочь: платформа позволяет командам строить backend, веб и нативные мобильные приложения из одной системы. Это упрощает согласование бизнес-логики и при этом даёт пользователям быстрый фидбек на каждом клиенте.

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