Из чего состоит приложение: интерфейс, бэкенд, база данных

В командах постоянно звучит: «это на фронте», «это на бэке», «это в базе». Так говорят о слоях приложения, и каждая такая фраза сразу сужает поиск. Кто не различает слои, задаёт вопросы всем подряд или не тому человеку. Разберём, из чего состоит приложение, на примере «Узелка» и научимся по жалобе понимать, в каком слое искать причину.

Кейс: четыре жалобы за неделю

За первую неделю после запуска онлайн-заказов «Узелок» получил четыре жалобы. Кнопка «Оформить заказ» не реагирует на нажатие. Заказ создался, но остаток товара на сайте не уменьшился. После обновления сайта пропали вчерашние заказы из личного кабинета. Покупатель оплатил картой, а заказ остаётся неоплаченным. Все четыре жалобы «про заказ», но искать причину в одном и том же месте нельзя.

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

Что делает каждый слой

Интерфейс (его ещё называют клиентской частью) это то, с чем работает человек: страницы в браузере или экраны мобильного приложения. Он принимает ввод и показывает результат. Бэкенд это программа на сервере, то есть на компьютере, где работает сайт: она применяет правила (можно ли заказать больше, чем есть на складе), считает суммы и обращается к остальным слоям. База данных хранит то, что должно пережить любой запрос и перезапуск: заказы, остатки, покупателей. Устройство баз разбирает раздел 4, начиная со статьи 04-01. Внешняя система принадлежит не магазину, а другой организации, как платёжный сервис банка: бэкенд обращается к ней, когда сам что-то сделать не может.

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

Слово «бэкенд» здесь означает слой, а не должность. О роли бэкенд-разработчика рассказывала статья 01-03.

Как слои общаются между собой

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

Правила такого разговора (какие бывают запросы, какие поля в них передают, как выглядит ошибка) описывает API, то есть договорённость о том, как одна программа обращается к другой. Что такое API, объясняет статья 05-03, а подробно про запросы и ответы рассказывает статья 05-07. Пока достаточно помнить: у каждой стрелки между слоями есть запрос, ответ и правила, и именно на этих стыках чаще всего находят ошибки.

Где проверять данные: на странице или на сервере

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

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

Как по симптому найти слой

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

Жалоба	Что говорит симптом	Куда смотреть первым
Кнопка «Оформить заказ» не реагирует	Возможно, запрос даже не ушёл	Интерфейс: был ли запрос при нажатии
Заказ создался, остаток на сайте не изменился	Запрос дошёл, заказ записан, а остаток не обновился	Бэкенд: вызывает ли он обновление остатка вместе с созданием заказа
После обновления пропали вчерашние заказы в кабинете	Данные могли остаться в базе, а страница их не показывает	База и бэкенд: есть ли заказы в базе и какой запрос выдаёт список
Оплатили картой, заказ неоплаченный	Деньги ушли, но сообщение об оплате не дошло или не обработалось	Внешняя система и бэкенд: что ответил банк и что сделал с ответом бэкенд

Это первая гипотеза, а не вывод. В четвёртом случае причиной может оказаться и ошибка в самой базе, и сбой на стороне банка. Но даже грубое разделение по слоям экономит время: вопрос задан тому, кто отвечает за нужный слой, а не всей команде сразу. Как довести такой разбор от жалобы до причины шаг за шагом, показывает статья 05-31.

Где это встречается в работе

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

Итог

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

Что дальше

• 05-03. Что такое API: как одна программа договаривается с другой
• 05-07. Запрос и ответ: из чего они состоят и как читать ошибку
• 04-01. Что такое база данных: что в ней хранится и как к ней обращаются
• 06-05. Внешние системы и зависимости: как приложение работает с чужими сервисами
• 05-31. Как разбирать ошибку: от жалобы пользователя до причины