Типичный путь онлайн-бизнеса выглядит так: компания запускает сайт, через полгода добавляет Telegram-бота для заказов и поддержки, ещё через год выпускает мобильное приложение. Проблема в том, что в большинстве случаев каждое из этих решений строится на собственном «мини-бэкенде» — со своей базой, своей логикой и своими интеграциями. В итоге данные расходятся, разработка дорожает, а добавить четвёртый канал почти невозможно без масштабного рефакторинга. Решение известно давно: единый API-слой, через который работают все точки контакта с клиентом. В этой статье разберём, как спроектировать такой бэкенд с первого дня, чтобы продукт масштабировался без переписывания с нуля.
Что значит «один бэкенд» на практике
API — это контракт между сервером и интерфейсами: сайт, бот и приложение не хранят данные и не считают логику самостоятельно, а запрашивают всё у центрального сервиса. Например, функция «оформить заказ» написана один раз: сайт вызывает её из корзины, бот — по нажатию кнопки, приложение — с экрана оформления. Клиенты остаются «тонкими»: они отвечают только за отображение и удобство, вся бизнес-логика живёт в ядре. Такой подход называется API-first: сначала проектируется контракт, затем под него строятся интерфейсы — а не наоборот.Что это даёт в деньгах и сроках
Выгода единой архитектуры измеряется конкретными цифрами:- Логика пишется один раз, а не три. Правила расчёта скидок, валидация форм, интеграция с оплатой и CRM не дублируются в трёх кодовых базах.
- Новый канал запускается поверх готового API. В нашей практике подключение Telegram-бота к существующей платформе занимает 3–5 недель против 2–3 месяцев на разработку с нуля.
- Ошибки исправляются в одном месте. Правка в ядре мгновенно применяется ко всем каналам — не нужно обновлять три приложения одновременно.
- Данные живут в одной базе. Клиент, сделавший заказ на сайте, видит его историю и в боте, и в приложении — без ручной синхронизации.
Принцип 1: REST и JSON как общий язык
Для универсального API подходит классический REST с форматом JSON: его понимают браузеры, iOS, Android, серверные части ботов и любые внешние системы — от 1С до платёжных шлюзов. Достаточно одного «языка», чтобы не переделывать контракт под каждую платформу. Отдельно продумайте единый формат ошибок: одинаковые коды и тексты для всех каналов, чтобы разработчики интерфейсов и боты обрабатывали сбои по одним правилам. GraphQL и gRPC — рабочие альтернативы, но для большинства проектов на старте REST проще, дешевле, и с ним проще найти исполнителей.Принцип 2: версионирование с первого дня
Мобильное приложение нельзя обновить за минуту: модерация в App Store занимает от одного до трёх дней, а пользователи устанавливают апдейты неделями. Поэтому старые версии клиентов живут месяцами, и API обязан их поддерживать. С первого релиза выносите адреса в формат /api/v1/: при несовместимых изменениях вы поднимаете v2, а первую версию поддерживаете ещё 6–12 месяцев. Правило кажется избыточным, пока канал один, но именно оно избавит от экстренных «заплаток» в момент, когда у половины пользователей внезапно перестанут работать заказы.Принцип 3: один пользователь — один аккаунт
Авторизация проектируется сквозной: пользователь идентифицируется не «аккаунтом на сайте», а записью в единой базе. На сайте он входит по e-mail, в приложении — по номеру телефона или через соцсети, в боте — отправляет контакт по кнопке или переходит по magic-link. Сервер выдаёт JWT-токен с ограниченным сроком жизни и refresh-механизмом — одинаковый для всех каналов. В результате у клиента одна история заказов, один баланс бонусов и одна корзина везде, а вы видите сквозную аналитику вместо трёх разрозненных баз.Принцип 4: канал — на входе, логика — в ядре
У каждого канала своя специфика доставки контента: приложению нужны push-уведомления, боту — сообщения Telegram, сайту — e-mail и браузерные уведомления. Поэтому в архитектуре выделяется слой адаптеров: ядро фиксирует событие «заказ отправлен», а адаптеры решают, как именно о нём сообщить. Разграничение ответственности выглядит так:- В бэкенде: цены, скидки, остатки, валидация, оплата, интеграции с CRM и 1С, аналитика.
- В клиентах: экраны, анимации, кнопки, кэширование для скорости, оффлайн-режим приложения.
Принцип 5: документация как часть продукта
Контракт описывается в формате OpenAPI (Swagger): из него автоматически генерируются документация и заглушки клиентов для Swift, Kotlin и JavaScript. Это сокращает подключение новых разработчиков с недель до дней — они видят список эндпоинтов, форматы запросов и примеры ответов, не читая чужой код. Документация защищает и вас как заказчика: без описанного контракта вы привязаны к текущей команде, с ним — можете подключить любого подрядчика. Для реалтайм-сценариев вроде трекинга заказа или чата поддержки заранее закладывайте WebSocket и вебхуки — добавить их постфактум в «сырой» API сложно и дорого.Пять ошибок, которые приведут к переписыванию
Эти просчёты мы чаще всего находим на аудите проектов, где «всё работало, пока не начали расти»:- Бизнес-логика в клиентах. Расчёт стоимости или скидок в коде интерфейса — главная причина расхождения цен между каналами.
- API, заточенный под один экран. Методы вида «получить всё для главного экрана» не переиспользуются и ломаются при любом редизайне.
- Нет версионирования и лимитов запросов. Первый же релиз приложения или бот-атака кладут весь сервис.
- Тяжёлые синхронные операции. Отправка данных в 1С или генерация документов должны уходить в очередь, иначе пользователь ждёт таймаут.
- Хардкод интеграций. Платёжный шлюз и CRM «зашиты» в ядро без абстракции — смена провайдера превращается в проект на квартал.
Единый бэкенд — это не «усложнение ради красоты», а прямая инвестиция в скорость роста: каждый следующий канал — сайт, бот, приложение, виджет — становится надстройкой над готовым ядром, а не отдельным проектом. Перед стартом разработки задайте подрядчику три вопроса: будет ли общий API для всех каналов, как решено версионирование и есть ли документация в OpenAPI. Отрицательный ответ на любой из них — повод пересмотреть предложение, иначе через год-два вы оплатите архитектуру повторно. Хотите оценить текущую систему или спроектировать платформу под рост — оставьте заявку: проведём технический аудит и покажем, во что выльется масштабирование именно вашего продукта.