Backend-разработка и API: невидимая часть системы

В большинстве компаний вопрос о backend возникает не как технический, а как бытовой. Файл Excel разделился на два, и никто точно не знает, какой из них правильный. Заказы собираются в группе Telegram, кто-то переносит их в таблицу руками. Чтобы узнать остаток на складе, приходится звонить продавцу. Или наоборот: интерфейс готов, но за ним нет сервера — данные негде хранить, отчёта не существует. В обоих случаях нужная работа называется одинаково: описать бизнес-процесс кодом и хранить его в одном месте.

Что делает backend — на языке бизнеса

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

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

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

Когда подход API-first оправдывает себя

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

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

• Одни и те же данные видны в нескольких местах: сайт, мобильное приложение, админ-панель, отчёт.
• Frontend и backend обновляются в разное время, иногда разными людьми.
• В планах обмен с внешней системой — склад, учёт, доставка или система партнёра.
• Сейчас делается только сайт, но мобильное приложение стоит в планах на будущее.

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

Безопасность данных и права доступа

Безопасность в backend не отдельный блок, она внутри структуры. На практике всё сводится к двум вопросам: кому данные видны и кто может их изменить. В большинстве систем проблема возникает не из-за атаки, а из-за слишком широких прав — например, уволенный сотрудник со старым паролем может выгрузить базу клиентов.

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

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

Интеграция систем: работа с тем, что уже есть

Интеграция систем редко идёт гладко. Обычно на двух сторонах данные названы по-разному: где-то клиент, где-то контрагент; где-то телефон в одном столбце, где-то в двух. Поэтому интеграция начинается не с подключения кода, а со сверки данных на обеих сторонах.

Три вещи, которые нужно определить до интеграции

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

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

Как появляется система, которую нельзя передать другой команде

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

1. Код лежит в репозитории на вашем аккаунте, а не на личном аккаунте исполнителя.
2. Структура базы и её изменения хранятся вместе с кодом, а не в виде команд, выполненных руками.
3. Есть инструкция по запуску проекта с нуля, и её проверили на другом компьютере.
4. Настройки окружения и ключи отделены от кода, а их перечень записан в документации.
5. Документация API существует, даже если API используется только вашим сайтом.

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

С чем прийти на первый разговор

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

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

Как мы ведём backend-разработку

FAZO — студия цифровых продуктов в Ташкенте. По backend у нас три опоры: API-ориентированная архитектура, оптимизация и безопасность базы данных, интеграция со сторонними системами — это постоянная часть работы, а не дополнение к ней. Список технологий намеренно короткий: Node.js, TypeScript, PostgreSQL, REST API, Docker, Firebase. В команде есть разработчик, который на Django строит backend-архитектуру, REST API, схему базы и аутентификацию, и специалист по кибербезопасности. Код мы пишем так, чтобы его можно было читать и продолжать: чистый код, модульная структура, безопасность.

Из сделанного: CRM Savdo Pro — CRM для склада и продаж, движение товара, аналитика продаж, база клиентов и отчёты; в результате записано, что процесс продаж ускорился в 3 раза. Shashlik House — онлайн-меню ресторана, оформление заказа и админ-панель; в результате записано, что онлайн-заказы выросли на 200%. Bug Bounty Platform — веб-система для исследователей безопасности.

1. Анализ. Изучаем бизнес-цели, определяем архитектуру и составляем дорожную карту проекта.
2. Дизайн. Экраны и пользовательские потоки строятся как система — каждый экран с намерением.
3. Разработка. Чистый код, модульная структура, безопасность. Долгосрочная поддерживаемость — обязательное требование.
4. Запуск. Развёртывание, мониторинг производительности и постоянная поддержка. Мы не исчезаем после запуска.

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