Разработка

Веб-приложение или сайт: где проходит граница

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

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

Разница в глаголе

Простое различение: сайт показывает, приложение делает.

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

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

Отсюда практическое следствие: у сайта посетитель анонимен и одинаков, у приложения он — конкретный человек с историей. Это и есть граница.

Три вещи, которые появляются вместе с приложением

Как только в проекте возникает работа пользователя, появляются три сущности, которых на сайте не было вовсе.

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

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

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

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

«Давайте добавим кабинет к сайту»

Эта фраза звучит как небольшое расширение, а означает смену класса задачи. Разберём, что за ней стоит.

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

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

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

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

Промежуточные случаи

Граница не всегда очевидна. Несколько типичных ситуаций и где они на самом деле находятся.

  • Интернет-магазин. Формально это приложение: корзина, заказы, статусы, оплата. Но у него есть большая витринная часть, которую видят все и которая должна индексироваться поиском. Поэтому магазин почти всегда гибрид: публичные страницы работают по правилам сайта, всё после корзины — по правилам приложения.
  • Калькулятор на сайте. Считает в браузере, ничего не сохраняет, результат ни на что не влияет — это всё ещё сайт. Как только расчёт сохраняется в личной истории пользователя, это уже приложение.
  • Блог с комментариями. Пользователи что-то создают, но ядро продукта — публикация контента. Это сайт с ограниченной интерактивностью, а не приложение.
  • Панель управления для сотрудников. Индексация не нужна, публичного трафика нет, зато есть роли, состояния и много таблиц. Приложение в чистом виде, даже если экранов немного.

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

Что меняется в процессе разработки

Различие в классе задачи меняет и то, как проект ведётся.

  1. Проектирование вместо дизайна. У сайта работа начинается со структуры страниц и прототипов. У приложения — со сценариев, ролей и модели данных. Красивые макеты, нарисованные до того, как описаны состояния, придётся переделывать.
  2. Другой состав работ. У приложения значительная часть усилий не видна на экране: бэкенд, база данных, права доступа, интеграции, обработка ошибок.
  3. Запуск — не финиш. Сайт после сдачи может месяцами не меняться. Приложение после запуска начинает жить: пользователи находят неудобства, появляются новые сценарии, нужен канал обратной связи и регулярные обновления.
  4. Поддержка обязательна. У приложения есть дежурство: если оно упало, люди не могут работать. Это отдельная договорённость, а не жест доброй воли.
  5. Стоимость владения выше. Сервер, резервные копии, мониторинг, обновления зависимостей, разбор инцидентов. Это регулярная статья расходов, и её нужно закладывать сразу.

Как понять, что вам нужно приложение

Проверьте себя по вопросам. Достаточно двух-трёх утвердительных ответов, чтобы перестать называть задачу сайтом.

  1. Должен ли пользователь входить под собой, чтобы увидеть своё?
  2. Сохраняется ли результат его действий и влияет ли на то, что он увидит завтра?
  3. Есть ли несколько типов пользователей с разными правами?
  4. Есть ли у объектов статусы, которые меняются по правилам?
  5. Нужно ли обмениваться данными с другой системой — учётной, платёжной, складской?
  6. Будет ли неверный расчёт или потеря записи стоить денег?

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

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