Бэкенд мобильного приложения простыми словами: стек, API, админка
Мобильное приложение — только видимая часть продукта. Каталог, цены, заказы, бонусы и обмен данными с учётной системой живут на сервере, и от его устройства зависит, выдержит ли приложение пиковый день распродажи. Разбираем без лишних терминов, из чего состоит бэкенд, как приложение обменивается данными через API, зачем бизнесу админка, какой стек выбирают и из чего складывается бюджет.
Что такое бэкенд мобильного приложения простыми словами
Бэкенд (от английского back end — «задняя часть») — серверная часть приложения, которую пользователь не видит. Всё, что человек видит на экране телефона, — кнопки, каталог, корзина, экран оплаты — называют клиентской частью, или фронтендом. Приложение на телефоне показывает данные и принимает нажатия. Всё остальное — хранение товаров, расчёт цен, приём заказов и передачу их в учётную систему — выполняет сервер.
Удобно сравнить с офлайн-магазином. Приложение — это торговый зал: витрины, ценники, примерочная, касса. Бэкенд — всё, что находится за дверью «Только для персонала»: склад с остатками, бухгалтерия, которая сверяет цены с учётной системой, отдел лояльности с бонусными счетами, служба доставки. Покупатель туда не заходит, но без этих служб зал не работает: ценник разойдётся с кассой, а заказ не дойдёт до склада.
В приложении интернет-магазина бэкенд отвечает за такие задачи:
- Каталог. Хранит товары, фотографии, цены и остатки по магазинам и городам.
- Вход и профиль. Регистрирует покупателя, отправляет код подтверждения, хранит адреса и историю заказов.
- Заказы. Принимает заказ, резервирует товар, передаёт заказ в учётную систему и обновляет статус.
- Скидки и бонусы. Применяет промокоды, начисляет и списывает баллы так, чтобы сумма в приложении совпала с кассой.
- Оплата. Создаёт платёж в банке и получает от банка подтверждение, что деньги списаны.
- Уведомления. Отправляет push-сообщения о статусе заказа, акциях и брошенной корзине.
- Данные для аналитики. Собирает события, по которым маркетолог видит, где покупатели уходят из воронки.
Один бэкенд обычно обслуживает сразу несколько клиентов: приложение для iPhone, приложение для Android и сайт. Поэтому бонусы, корзина и история заказов у покупателя одинаковы на любом устройстве. По нашему опыту, многие жалобы пользователей — «не пришёл код», «бонусы не списались», «товар оказался не в наличии» — возникают на сервере, а не в интерфейсе. Когда каталог открывается медленно или заказ теряется, причину чаще ищут в бэкенде, а не в дизайне.
Из чего состоит бэкенд приложения
Бэкенд — не одна программа, а несколько частей, каждая со своей задачей. В небольшом проекте часть из них объединяют, в крупном разносят по отдельным сервисам. Состав для приложения магазина:
| Часть бэкенда | Что делает | Пример в приложении магазина |
|---|---|---|
| Бизнес-логика | Выполняет правила бизнеса: считает цену, проверяет наличие, применяет скидки | Скидка на вторую вещь в чеке считается одинаково в приложении и на сайте |
| База данных | Хранит данные в упорядоченном виде и отдаёт их по запросу | Профили покупателей, заказы, избранное, история бонусов |
| API | Договор, по которому приложение запрашивает данные и отправляет действия | «Покажи товары категории», «создай заказ», «примени промокод» |
| Административная панель | Рабочее место сотрудников для управления контентом и заказами | Маркетолог меняет баннер на главном экране, оператор смотрит состав заказа |
| Интеграции | Обмен данными с внешними системами | 1С, CRM, банк-эквайер, службы доставки, маркетплейсы |
| Фоновые задачи | Работа по расписанию или в очереди, без участия покупателя | Ночная выгрузка каталога, массовая рассылка push, пересчёт бонусов |
| Хранилище файлов | Хранит картинки и документы и быстро отдаёт их на телефон | Фото товаров, сертификаты, баннеры и сториз |
| Мониторинг и журналы | Следит за ошибками и нагрузкой, сообщает о сбоях | Оповещение дежурному разработчику, если перестали проходить оплаты |
Не каждому проекту все восемь частей нужны с первого дня. Для первой версии продукта хватает базы данных, бизнес-логики, API и минимальной админки, а интеграции и фоновые задачи добавляют по мере роста. Как эти части складываются в общую схему вместе с экранами приложения и кэшем каталога, разобрано в материале об архитектуре мобильного приложения интернет-магазина.
API простыми словами: как приложение обменивается данными с сервером
API (Application Programming Interface, программный интерфейс) — набор заранее оговорённых запросов, через которые приложение общается с сервером. Похоже на окно выдачи в кафе: гость не заходит на кухню, а говорит заказ по меню, и кухня возвращает блюдо в понятном виде. Приложение так же не лезет в базу данных напрямую — оно отправляет запрос из списка, а сервер проверяет права, выполняет действие и возвращает ответ.
Что происходит за одним нажатием покупателя:
| Действие в приложении | Запрос к API | Что делает сервер |
|---|---|---|
| Открыть каталог | «Выдай товары категории, первую страницу» | Берёт товары и цены из базы с учётом города покупателя и остатков |
| Добавить в корзину | «Добавь позицию в корзину» | Проверяет наличие, пересчитывает сумму и скидки |
| Ввести промокод | «Примени промокод» | Проверяет срок действия и условия акции, считает новую сумму |
| Нажать «Оплатить» | «Создай заказ и платёж» | Резервирует товар, создаёт платёж в банке и ждёт подтверждения |
| Получить уведомление «Заказ собран» | Запроса нет — сервер пишет первым | Получает новый статус из учётной системы и отправляет push через сервисы Apple и Google |
Для заказчика важны три свойства хорошего API.
- Описанный договор. Все запросы и ответы фиксируют в документации по стандарту OpenAPI. Тогда мобильная команда и команда сервера работают одновременно, а новая команда разберётся в проекте по документам, а не по переписке.
- Поддержка старых версий приложения. Сайт обновляется у всех посетителей сразу, а приложение — только когда пользователь его обновит. На телефонах месяцами живут прошлые версии, поэтому сервер обязан отвечать и им. Если поменять формат ответа без новой версии API, у части покупателей перестанет открываться корзина.
- Защита. Сервер проверяет, кто делает запрос: покупатель видит только свои заказы, а подобрать код подтверждения перебором не получится из-за ограничения частоты запросов.
Приложения на Flutter обращаются к серверу через стандартные сетевые запросы — порядок описан в документации Flutter. Подробный разбор правил, версий и ошибок — в статье проектирование REST API.
Админка: где бизнес управляет приложением
Административная панель, или админка, — внутренний сайт для сотрудников, через который бизнес управляет приложением без участия разработчиков. Покупатели её не видят. Если приложение — торговый зал, то админка — пульт управления магазином: здесь меняют витрину, смотрят заказы и отвечают клиентам.
Кто и что делает в админке приложения магазина:
- Контент-менеджер — меняет баннеры, сториз и подборки на главном экране, публикует новости.
- Маркетолог — заводит промокоды и акции, запускает push-рассылки по сегментам покупателей.
- Оператор заказов — видит состав и статус заказа, меняет способ доставки, оформляет возврат.
- Служба поддержки — находит покупателя по номеру телефона, проверяет начисление бонусов.
- Руководитель — смотрит отчёты по заказам и выгружает данные в таблицу.
Главный вопрос при проектировании админки — какая система считается главным источником данных. Цены, остатки и карточки товаров в ритейле обычно ведут в 1С, и дублировать их в админке нельзя: две правды о цене быстро разойдутся. В админку выносят то, чего в учётной системе нет, — витрина приложения, акции, push-рассылки, модерация отзывов. Как устроен обмен с учётной системой, разобрано в материале об автоматизации учёта товара в рознице на 1С.
Второй вопрос — права доступа. У каждой роли свой набор разделов: оператор не меняет цены, маркетолог не видит платёжные данные. Хорошая админка ведёт журнал действий — кто и когда изменил баннер или отменил заказ. Без журнала ошибку сотрудника найти сложно.
Сделать админку можно двумя путями. Фреймворк Django даёт встроенную административную панель: списки, карточки, фильтры, права по ролям появляются почти без отдельной разработки интерфейса. Для операционной работы этого часто достаточно. Если сотрудникам нужны сложные сценарии — конструктор витрины с предпросмотром, визуальные отчёты, согласования в несколько шагов, — разрабатывают отдельный интерфейс поверх того же API.
Стек бэкенда: Python, Django, FastAPI, PostgreSQL и Docker
Стек — набор технологий, на которых написан продукт. Заказчику не нужно разбираться в них глубоко, но полезно понимать, за что отвечает каждая и почему её выбрали. Стек серверной части, на котором работает команда FITTIN:
| Технология | Что это | За что отвечает в проекте |
|---|---|---|
| Python | Язык программирования | На нём пишут логику сервера; для интеграций, обработки данных и работы с ИИ есть большой выбор готовых библиотек |
| Django | Фреймворк — готовый каркас сервера на Python | Модели данных, права доступа, встроенная админка; вместе с Django REST Framework — API для приложения |
| FastAPI | Лёгкий фреймворк на Python для API | Сервисы, которые обрабатывают много одновременных запросов, и интеграционный слой между системами |
| PostgreSQL | Реляционная база данных | Заказы, пользователи, бонусы — данные, где важна точность и целостность |
| Redis | Быстрое хранилище в оперативной памяти | Кэш каталога, очереди задач, коды подтверждения с ограниченным сроком жизни |
| Celery | Система фоновых задач | Рассылки, синхронизация с 1С и отчёты по расписанию |
| Docker | Упаковка сервера в контейнер вместе со всем окружением | Одинаковый запуск на тестовом и рабочем сервере, перенос к другому хостингу без переписывания |
| Firebase Cloud Messaging | Облачный сервис Google для доставки уведомлений | Доставка push-сообщений на телефоны покупателей |
У такого стека есть понятное для бизнеса свойство: Django, FastAPI, PostgreSQL и Docker — открытые технологии без платы за лицензию. Специалистов по ним много, поэтому сервер можно развивать дальше силами другой команды, если у заказчика есть исходный код и документация.
Django или FastAPI
Оба фреймворка написаны на Python, но закрывают разные задачи. Django удобен, когда у продукта много сущностей и правил: каталог, заказы, роли сотрудников, личные кабинеты, и нужна готовая админка. FastAPI выбирают для отдельных сервисов под высокую нагрузку: приём событий, расчёты в режиме онлайн, интеграционный слой. В крупных проектах их нередко сочетают: основная логика и админка на Django, нагруженные участки — отдельными сервисами на FastAPI. Подробнее о первом фреймворке — в статье разработка на Django.
Облачный сервис, платформа или свой сервер: три варианта бэкенда
Писать сервер с нуля нужно не всегда. На рынке три основных подхода, и у каждого своя сильная сторона.
| Критерий | Облачный бэкенд-сервис | Бэкенд модульной платформы | Собственный бэкенд на Django или FastAPI |
|---|---|---|---|
| Что это | Готовые облачные функции: база, вход, файлы, уведомления, которые настраиваются без своего сервера | Серверная часть уже написана вместе с модулями каталога, корзины, оплаты и лояльности и настраивается под бренд | Сервер разрабатывают под задачи конкретного продукта |
| Старт | Самый быстрый путь для прототипа: первые экраны работают через несколько дней | Интеграция под бренд — до 30 рабочих дней | Срок фиксируют после технического задания |
| Своя бизнес-логика | В пределах возможностей сервиса | Готовые сценарии e-commerce; уникальные — кастомными доработками на исходном коде | Любая |
| Интеграции с 1С, CRM и доставкой | Нужен отдельный сервер-посредник или облачные функции | 1С, маркетплейсы, CRM, доставка и эквайринг подключаются модулями | Разрабатывают под нужные системы |
| Кто сопровождает сервер | Поставщик отвечает за инфраструктуру, логику и данные — команда заказчика | Команда платформы, поддержка включена в лицензию | Подрядчик по договору поддержки или своя команда |
| Порядок оплаты | Тариф сервиса, растёт с числом пользователей и запросов | Разовая интеграция, ежемесячная лицензия и доработки по Time & Materials | Fix Price по ТЗ или Time & Materials, плюс хостинг |
| Кому подходит | Прототип, проверка идеи, небольшой внутренний сервис | Приложение и сайт интернет-магазина, ритейл-сети | Продукт с уникальной логикой, B2B-портал, сервис под высокую нагрузку |
Облачный сервис выигрывает на старте, но зависимость от поставщика растёт вместе с продуктом: сложную логику и интеграции с российскими учётными системами всё равно приходится выносить на отдельный сервер. Отдельно стоит проверить, где физически хранятся персональные данные покупателей, — об этом в разделе вопросов к подрядчику.
Модульная платформа закрывает типовые задачи магазина готовыми модулями, серверная часть которых уже проверена на других проектах. Так устроена модульная платформа FITTIN — отечественное ПО в реестре российского ПО Минцифры (№ 2487103): это не SaaS с фиксированным функционалом и не разработка с нуля. Собственный бэкенд даёт полную свободу в логике и архитектуре — ценой более долгого старта. Для нестандартных продуктов этот путь описан на страницах разработки ПО на заказ и корпоративных приложений.
Когда приложению нужен собственный бэкенд
Собственная серверная часть — самостоятельно разработанная или на основе платформы — нужна, когда приложение работает с деньгами, заказами и учётной системой. Пять типичных ситуаций:
- Приложение магазина с заказами и бонусами. Каталог из 1С, оплата, доставка, программа лояльности — без сервера эти данные не связать. Что обычно входит в такой продукт, собрано в материале о функциях приложения интернет-магазина.
- Единые данные для сайта, приложения и магазинов. Покупатель копит бонусы на кассе, а тратит в приложении. Одна база клиентов и бонусов живёт на сервере — подробнее в статье о программе лояльности в приложении.
- Уникальные правила. Индивидуальные цены по договорам для оптовых клиентов, франшиза с разными юрлицами, конструктор товара. Такие сценарии типичны для B2B-приложений для юридических лиц.
- Пиковая нагрузка. В распродажу число заказов в час может вырасти в разы, и сервер должен выдержать это без остановки. Как к этому готовятся, разобрано в статье о высоконагруженных системах в e-commerce.
- Требования к хранению данных. Компании нужно держать данные клиентов на своих серверах или в определённом облаке, с контролем доступа и журналами.
Когда отдельный сервер можно отложить: приложение-справочник без заказов и личных кабинетов или первая версия для проверки спроса. Тогда хватает облачного сервиса или облегчённой серверной части — такой путь описан на странице разработки MVP.
Как разрабатывают бэкенд: шесть этапов
Этапы одинаковы для любого серверного проекта, меняется объём. На модульной платформе серверная часть каталога, корзины, оплаты и лояльности уже написана, поэтому этапы 3 и 4 сводятся к настройке и доработкам, а интеграция под бренд укладывается в срок до 30 рабочих дней. У собственного бэкенда срок и объём определяет техническое задание.
Этап 1. Техническое задание и модель данных
Что происходит: команда описывает, с какими данными работает продукт — товары, заказы, покупатели, бонусы, — кто из сотрудников что может делать и с какими системами нужен обмен. По этому документу считают срок и бюджет.
Если требований много, их оформляют отдельной услугой — разработка технического задания. Типичная ошибка: начать разработку без полного списка интеграций. Подключение службы доставки, о которой вспомнили в конце, может потребовать изменить модель заказа и часть уже готового кода.
Этап 2. Архитектура и договор API
Что происходит: команда решает, как разделить сервер на части, где хранить кэш и какие задачи уводить в фон. Все запросы и ответы описывают заранее, чтобы экраны приложения и серверная логика разрабатывались одновременно.
Типичная ошибка: менять формат ответов по ходу проекта без версии API. На тестовых телефонах всё работает, а после выхода обновления старые версии приложения у покупателей перестают открывать экраны.
Этап 3. Разработка сервера и админки
Что происходит: разработчики создают модели данных, бизнес-логику и запросы API, настраивают административную панель и права ролей. Заказчик проверяет результат на тестовом сервере, а не на рабочем.
Типичная ошибка: выдать всем сотрудникам полный доступ «пока не настроим роли». Временные права остаются надолго, а случайная правка цены или удаление заказа потом ищется без журнала действий.
Этап 4. Интеграции
Что происходит: сервер подключают к 1С, CRM, банку, службам доставки. Для каждой связи решают, что передаётся, как часто и что делать, если внешняя система недоступна: поставить заказ в очередь и повторить отправку позже.
Подробнее — на страницах интеграции с ERP и 1С для интернет-магазина и интеграции приложения с CRM. Типичная ошибка: запрашивать у 1С данные на каждый показ товара. Учётная система не рассчитана на тысячи одновременных запросов из приложения, поэтому каталог держат в базе сервера и обновляют по расписанию.
Этап 5. Тестирование и проверка нагрузки
Что происходит: автотесты проверяют расчёт цен, скидок и бонусов, тестировщики проверяют права доступа и сценарии оплаты. Перед распродажами сервер проверяют под нагрузкой, чтобы найти узкие места до того, как их найдут покупатели.
Как устроена такая проверка — на страницах нагрузочного тестирования и тестирования мобильных приложений. Типичная ошибка: проверять только «счастливый путь» покупки и не проверять отказ банка, двойное нажатие кнопки оплаты и повторную отправку заказа.
Этап 6. Запуск и сопровождение
Что происходит: сервер разворачивают в Docker на инфраструктуре заказчика или в облаке, настраивают автоматический выпуск обновлений, мониторинг, оповещения о сбоях и резервное копирование базы. После запуска команда сопровождает сервер: обновляет библиотеки, закрывает уязвимости, дорабатывает функции.
Сопровождение — отдельная статья расходов, её разбор — в материале о стоимости поддержки приложения после запуска, а услуга описана на странице технической поддержки приложений. Типичная ошибка: настроить резервные копии и ни разу не проверить восстановление из них. Копия, из которой не получается восстановить базу, обнаруживается в самый неудобный момент.
Сколько стоит бэкенд мобильного приложения
Единой цены у серверной части нет: два приложения с похожими экранами могут отличаться по объёму бэкенда в разы. Бюджет определяют семь факторов.
| Фактор | Как влияет на объём работ |
|---|---|
| Число сущностей и ролей | Каждый тип данных и каждая роль сотрудника — отдельные модели, права и разделы админки |
| Объём API | Больше экранов и сценариев в приложении — больше запросов, которые нужно разработать, описать и проверить |
| Интеграции | Считается каждая система; интеграции с 1С часто требуют доработки выгрузки в самой учётной системе |
| Нагрузка | Пики распродаж требуют кэша, очередей, нескольких серверов и нагрузочного тестирования |
| Админка | Встроенная панель Django — меньше работ; отдельный интерфейс со сложными сценариями — отдельный фронтенд |
| Безопасность и данные | Персональные данные, платежи и журналы доступа добавляют требования к хранению и проверкам |
| Сопровождение | Хостинг, мониторинг, обновления и дежурство после запуска — регулярные расходы, а не разовые |
Порядок оплаты зависит от выбранного варианта.
- Собственный бэкенд по Fix Price. Стоимость и срок фиксируются в договоре после согласования технического задания. Подходит, когда модель данных и состав API понятны заранее.
- Собственный бэкенд по Time & Materials. Оплата по отработанным часам, перед стартом каждой задачи — оценка в часах. Подходит для развития продукта и задач, объём которых уточняется по ходу. Сравнение моделей — в статье T&M или Fix Price.
- Модульная платформа. Модель состоит из трёх частей. Первая — единоразовая интеграция под бренд, до 30 рабочих дней. Вторая — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN, поэтому при типовом наборе функций своя команда разработки не требуется. Третья — новый функционал и доработки отдельно, по Time & Materials со сметой перед стартом задачи. Суммы — на странице тарифов.
- Усиление своей команды. Если серверную часть ведут штатные разработчики, но не хватает специалистов, подключают бэкенд-разработчиков на аутстаффинг или DevOps-инженеров.
Помимо разработки, в бюджет закладывают расходы на инфраструктуру: серверы или облако, отправку SMS с кодами подтверждения, хранилище файлов. FITTIN — федеральная команда с центром разработки в Воронеже: распределённая модель позволяет держать эффективные ставки без потери качества. Ориентир по своему проекту можно получить на калькуляторе стоимости разработки.
Что спросить у подрядчика о бэкенде
Серверная часть не видна на демонстрации, поэтому качество бэкенда проверяют вопросами. Ответы на них стоит получить до подписания договора.
- Кому принадлежат исходный код и база данных? Передаются ли документация API, схема базы и инструкция по развёртыванию.
- Где будет работать сервер? На инфраструктуре заказчика, в облаке или на серверах подрядчика, и кто оплачивает хостинг.
- Где хранятся персональные данные покупателей? По закону о персональных данных (152-ФЗ) при сборе данных граждан России их запись и хранение ведут в базах, расположенных на территории России. Это стоит проверить до выбора облачного сервиса.
- Как устроены резервные копии? Как часто делаются, где хранятся и когда последний раз проверяли восстановление.
- Как команда узнаёт о сбоях? Какой мониторинг настроен, кто получает оповещения и за какое время реагирует.
- Как сервер работает со старыми версиями приложения? Есть ли версии API и сколько их поддерживают.
- Что происходит, если 1С или банк недоступны? Теряется ли заказ или встаёт в очередь на повторную отправку.
- Как проверяли нагрузку? На какое число одновременных покупателей рассчитан сервер и проводилось ли нагрузочное тестирование.
- Как устроены права в админке? Есть ли роли и журнал действий сотрудников.
Если бэкенд уже работает и его писал другой подрядчик, ответы на эти вопросы даёт аудит кода: он показывает, что в сервере устроено надёжно, а что стоит переделать до роста нагрузки. Какие роли нужны в команде серверной разработки, разобрано в статье о ролях и составе команды разработки, а на что обратить внимание при приёме платежей — в материале о безопасности платежей в мобильном приложении.
Кейсы: что делает бэкенд в приложениях магазинов
Покупатель видит экраны, но результат в цифрах обеспечивает серверная часть. Четыре проекта FITTIN, в которых это заметно. Данные — со страниц кейсов.
«Сатурн»: заказы уходят на склад своего города в 1С, конверсия в покупку 12,4%
Сеть строительных гипермаркетов с каталогом свыше 30 000 товаров. На сайте каждый город работал на отдельном поддомене со своими складами и ценами. В приложении эту логику перенесли на сервер: заказ из Санкт-Петербурга не попадёт на московский склад, а корректно уйдёт в 1С нужного города. Через приложение заказывают колеровку и распил, доставку с манипулятором и оформляют покупку на юридическое лицо. За первый месяц — 7 594 установки, конверсия в покупку — 12,4%.
DAISYKNIT: переход на собственное приложение со 100% сохранностью клиентской базы
Fashion-бренд уходил с коробочного решения на своё кроссплатформенное приложение. Главная задача серверной части — перенести клиентскую базу и историю взаимодействий в Mindbox, не разорвав связи с аналитикой, платежами и push-уведомлениями. Результат — 100% сохранность клиентской базы и интеграций. События кастомного адвент-календаря передаются в CRM.
Gulliver: серверная часть на Python и 50% дохода через приложение
Мультибрендовый магазин детских товаров: пять направлений и четыре бренда одежды и игрушек. Стек проекта — Flutter для приложения и Python для серверной части. Приложение даёт 50% дохода бренда, поэтому стабильность сервера здесь напрямую связана с выручкой.
One Price Coffee: сервер на Python сверяет корзину со стоп-листом и считает кешбэк до 10%
Сеть кофеен по франшизе: точки принадлежат разным юрлицам, у каждой свой эквайринг и доступ к системе лояльности. Серверная часть на Python синхронизирует меню с кассовой системой, обновляет стоп-листы каждые 15 минут, повторно проверяет корзину перед оплатой и отсекает самоприглашения в реферальной программе. Уровни лояльности дают кешбэк от 3 до 10%.
Как устроено приложение магазина целиком, показано на странице мобильных приложений для интернет-магазинов. Остальные проекты — в разделе кейсов.
Итог: бэкенд приложения на одной странице
Сводка для разговора с подрядчиком.
| Вопрос | Короткий ответ |
|---|---|
| Что такое бэкенд | Серверная часть: хранит данные, считает цены и бонусы, принимает заказы, обменивается данными с 1С и банком |
| Из чего состоит | Бизнес-логика, база данных, API, админка, интеграции, фоновые задачи, хранилище файлов, мониторинг |
| Что такое API | Описанный договор запросов между приложением и сервером; должен поддерживать старые версии приложения |
| Зачем админка | Управлять витриной, акциями, заказами и рассылками без разработчиков; цены и остатки остаются в учётной системе |
| Стек | Python, Django и FastAPI, PostgreSQL, Redis, Celery, Docker |
| Варианты | Облачный сервис — для прототипа; модульная платформа — для магазина; собственный сервер — для уникальной логики |
| Как платить | Fix Price или Time & Materials за собственный бэкенд; интеграция, лицензия с поддержкой и доработки — на платформе |
Материалы по теме:
- Как устроено приложение целиком: архитектура мобильного приложения интернет-магазина; правила обмена данными — проектирование REST API.
- Функции, которые держит сервер: личный кабинет в приложении, push-уведомления, CRM для интернет-магазина.
- Услуги: разработка на Django, разработка бэкенда на FastAPI, аутстаффинг бэкенд-разработчиков.
Что делать дальше:
- Описать сущности, роли и интеграции — разработка технического задания; проверить действующий сервер — аудит кода.
- Посчитать бюджет — калькулятор стоимости и тарифы.
- Обсудить проект — бэкенд на Django, контакты или форма ниже.
Часто задаваемые вопросы
Чем бэкенд отличается от фронтенда?
Фронтенд — то, что пользователь видит и нажимает: экраны приложения, кнопки, каталог, корзина. Бэкенд — серверная часть, которую пользователь не видит: она хранит товары и заказы, считает цены и бонусы, проводит оплату и обменивается данными с 1С, CRM и банком. Приложение на телефоне отправляет запросы, а сервер их выполняет и возвращает результат. Если сравнивать с магазином, фронтенд — торговый зал, а бэкенд — склад, бухгалтерия и служба доставки.
Можно ли сделать мобильное приложение без бэкенда?
Можно, если приложению не нужны общие данные: калькулятор, заметки, справочник, который хранит всё на телефоне. Как только появляются вход по номеру телефона, заказы, оплата, бонусы или синхронизация между устройствами, нужен сервер. Для прототипа его роль может выполнить облачный бэкенд-сервис, но для магазина с 1С, доставкой и программой лояльности обычно нужна полноценная серверная часть — собственная или в составе модульной платформы.
Что выбрать для бэкенда: Django или FastAPI?
Django удобен, когда у продукта много данных и правил: каталог, заказы, роли сотрудников, личные кабинеты, и нужна готовая административная панель. FastAPI выбирают для отдельных сервисов под высокую нагрузку и интеграционного слоя между системами. Оба фреймворка написаны на Python, поэтому их часто сочетают: основная логика и админка на Django, нагруженные участки — сервисами на FastAPI. Стек выбирают на этапе технического задания.
Сколько стоит разработка бэкенда для мобильного приложения?
Единой цены нет: бюджет зависит от числа сущностей и ролей, объёма API, количества интеграций, требований к нагрузке, вида админки и сопровождения после запуска. Собственный бэкенд оплачивают по Fix Price, когда стоимость фиксируется в договоре после технического задания, или по Time & Materials — по отработанным часам с оценкой перед стартом задачи. На модульной платформе серверная часть типовых модулей уже готова, а оплата состоит из разовой интеграции, ежемесячной лицензии с техподдержкой и доработок по Time & Materials.
Можно ли использовать один бэкенд для сайта и приложения?
Да, и это распространённая схема. Сервер отдаёт данные через API и сайту, и приложениям для iPhone и Android, поэтому корзина, бонусы и история заказов у покупателя одинаковы на любом устройстве. Сотрудники ведут витрину и акции в одной админке, а обмен с 1С и CRM настраивается один раз. Важно заранее учесть в API различия каналов: например, push-уведомления есть только в приложении.
Нужна ли админка, если товары и цены уже ведутся в 1С?
Нужна, но с другим набором разделов. Цены, остатки и карточки товаров остаются в учётной системе и приходят на сервер по расписанию — дублировать их в админке не стоит. В админку выносят то, чего в 1С нет: баннеры и сториз на главном экране, промокоды и акции приложения, push-рассылки, модерацию отзывов, просмотр заказов и данных покупателя для службы поддержки. У каждой роли сотрудников свой набор прав.
Где размещать сервер приложения и нужно ли хранить данные в России?
Сервер размещают на инфраструктуре заказчика или в облаке, а упаковка в Docker позволяет при необходимости переехать к другому провайдеру. Если приложение собирает персональные данные граждан России — имя, телефон, адрес доставки, — закон о персональных данных (152-ФЗ) требует вести их запись и хранение в базах на территории России. Поэтому перед выбором облачного сервиса стоит проверить, где физически находятся его серверы.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Требования законодательства к хранению персональных данных приведены в общем виде — для решения по конкретному проекту сверяйтесь с актуальной редакцией закона. Python, Django, PostgreSQL, Redis, Docker и Firebase — товарные знаки соответствующих правообладателей; упоминаются для описания технологий.
