Разработка Backend на Python (Django/FastAPI) для мобильных приложений

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка Backend на Python (Django/FastAPI) для мобильных приложений
Средний
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Разработка серверной части (Backend) для мобильного приложения на Python (Django/FastAPI)

Представьте: ваше мобильное приложение выросло до 100 000 DAU, а сервер перестаёт справляться с пиковыми нагрузками. MongoDB кластеризация уже не помогает — нужен отказоустойчивый бэкенд на Python с грамотной архитектурой. Python — второй по популярности язык для мобильных бэкендов после Node.js, и у нас есть две доминирующие опции: Django REST Framework — batteries-included, ORM, admin, auth из коробки; FastAPI — асинхронный, типобезопасный, быстрый старт. Выбор между ними зависит от требований к скорости разработки, производительности и размера команды. Наши инженеры с опытом 10+ лет помогут определиться и реализуют проект под ключ за 2–3 недели (MVP) или 1–3 месяца (полноценный бэкенд). Свяжитесь с нами, чтобы обсудить детали.

Как выбрать между Django REST Framework и FastAPI?

Ключевое различие — модель выполнения и встроенные возможности. FastAPI с первого дня работает асинхронно на asyncio, что даёт высокую пропускную способность при работе с I/O-bound операциями (сетевые запросы, работа с БД). Django REST Framework исторически синхронный, но с версии 4.1 поддерживает асинхронные view через ASGI. Если ваш проект требует real-time фич, WebSocket, высокой конкурентности — FastAPI очевидный выбор. Если же нужна быстрая разработка с админ-панелью и богатым ORM, DRF сэкономит недели.

FastAPI: когда нужна скорость и типизация

FastAPI строится на Pydantic и Starlette. Каждый endpoint автоматически валидирует входные данные через аннотации типов и генерирует OpenAPI-документацию:

from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
from pydantic import BaseModel, UUID4
from sqlalchemy.ext.asyncio import AsyncSession

app = FastAPI()
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="/auth/token")

class CreatePostRequest(BaseModel):
    title: str
    content: str
    author_id: UUID4

class PostResponse(BaseModel):
    id: UUID4
    title: str
    content: str
    created_at: datetime

    class Config:
        from_attributes = True

@app.post("/posts", response_model=PostResponse, status_code=201)
async def create_post(
    body: CreatePostRequest,
    db: AsyncSession = Depends(get_db),
    current_user: User = Depends(get_current_user),
):
    if body.author_id != current_user.id:
        raise HTTPException(status_code=403, detail="Forbidden")
    post = await post_service.create(db, body)
    return post

Pydantic v2 (Rust-based) валидирует данные быстрее, чем большинство альтернатив. response_model автоматически сериализует ORM-объект и скрывает поля, которых нет в схеме (например, пароль-хеш не попадёт в ответ).

SQLAlchemy 2.x + AsyncSession для асинхронной работы с PostgreSQL через asyncpg:

from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession
from sqlalchemy.orm import sessionmaker

engine = create_async_engine(settings.DATABASE_URL)  # postgresql+asyncpg://...
AsyncSessionLocal = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

async def get_db():
    async with AsyncSessionLocal() as session:
        yield session

Alembic для миграций схемы БД — генерирует diff между моделями и текущей БД.

Аутентификация JWT

from jose import JWTError, jwt
from datetime import datetime, timedelta

def create_access_token(user_id: str) -> str:
    expires = datetime.utcnow() + timedelta(minutes=15)
    return jwt.encode(
        {"sub": user_id, "exp": expires, "type": "access"},
        settings.JWT_SECRET,
        algorithm="HS256",
    )

async def get_current_user(
    token: str = Depends(oauth2_scheme),
    db: AsyncSession = Depends(get_db),
) -> User:
    try:
        payload = jwt.decode(token, settings.JWT_SECRET, algorithms=["HS256"])
        user_id: str = payload.get("sub")
    except JWTError:
        raise HTTPException(status_code=401, detail="Could not validate token")
    user = await user_repo.get(db, user_id)
    if not user:
        raise HTTPException(status_code=401, detail="User not found")
    return user

Django REST Framework: когда нужен полный стек

DRF выигрывает, когда нужно быстро получить admin-панель, богатый ORM с select_related/prefetch_related, встроенные permissions и throttling:

# serializers.py
class PostSerializer(serializers.ModelSerializer):
    author_name = serializers.SerializerMethodField()

    class Meta:
        model = Post
        fields = ['id', 'title', 'content', 'author_name', 'created_at']
        read_only_fields = ['id', 'created_at']

    def get_author_name(self, obj):
        return obj.author.get_full_name()

# views.py
class PostViewSet(ModelViewSet):
    serializer_class = PostSerializer
    permission_classes = [IsAuthenticated]
    throttle_classes = [UserRateThrottle]

    def get_queryset(self):
        return Post.objects.filter(author=self.request.user)\
            .select_related('author')\
            .order_by('-created_at')

select_related решает N+1 проблему: один SQL JOIN вместо запроса для каждого автора. prefetch_related — для many-to-many.

django-channels для WebSocket (чат, realtime). Celery + Redis для фоновых задач (отправка email, пуш-уведомлений, тяжёлые вычисления).

# tasks.py
from celery import shared_task
import firebase_admin.messaging as fcm

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def send_push_notification(self, token: str, title: str, body: str):
    try:
        message = fcm.Message(
            token=token,
            notification=fcm.Notification(title=title, body=body),
            android=fcm.AndroidConfig(priority='high'),
            apns=fcm.APNSConfig(payload=fcm.APNSPayload(aps=fcm.Aps(sound='default'))),
        )
        fcm.send(message)
    except Exception as exc:
        raise self.retry(exc=exc)

Сравнение подходов

Критерий FastAPI Django REST Framework
Async из коробки Да (asyncio) Частично (Django 4.1+)
Скорость запуска Высокая Средняя
Admin-панель Нет (сторонние) Встроенная
ORM SQLAlchemy / Tortoise Django ORM
Документация API Автогенерация (Swagger) drf-spectacular
Подходит для Новые проекты, API-only Быстрый MVP с admin

Типичные ошибки при выборе архитектуры бэкенда

  • Игнорирование требований к real-time: если приложению нужны уведомления в реальном времени, лучше сразу закладывать WebSocket и асинхронный фреймворк. Переход с синхронного Django на async в процессе — затратная миграция.
  • Недооценка микросервисной архитектуры: на старте достаточно монолита, но если планируется рост до 50+ эндпоинтов, стоит предусмотреть разбиение на микросервисы. Python хорошо подходит для микросервисов с использованием FastAPI или Nameko.
  • Отсутствие автоматической документации API: мобильные разработчики тратят часы на согласование форматов. OpenAPI (Swagger) решает эту проблему.

Как обеспечить безопасность API?

Помимо JWT, мы используем CORS, rate limiting, валидацию входных данных, логирование подозрительной активности. Для защиты от SQL-инъекций применяем ORM с параметризованными запросами. Все секреты хранятся в Vault или AWS Secrets Manager. Регулярно обновляем зависимости.

Для дополнительной защиты внедряем TOTP через pyotp и QR-коды. Это снижает риски компрометации аккаунта на 99% (по данным OWASP).

Развёртывание

FastAPI или Django запускается через Uvicorn + Gunicorn с несколькими воркерами. Docker с многоэтапной сборкой для минимального образа. Nginx как reverse proxy. PostgreSQL + Redis в docker-compose для локала, RDS + ElastiCache для продакшена. С такой конфигурацией мы гарантируем SLA 99.9% и снижаем затраты на инфраструктуру до 40% по сравнению с монолитным подходом.

Этапы работ над бэкендом

  1. Анализ требований — изучаем ТЗ, нагрузки, интеграции. Оцениваем сроки.
  2. Проектирование API — спецификация OpenAPI, выбор стека.
  3. Разработка — реализация модулей, настройка БД, аутентификации, фоновых задач.
  4. Тестирование — unit-тесты, интеграционные, нагрузочные (locust/k6).
  5. Деплой — Docker, CI/CD (GitHub Actions), мониторинг (Prometheus + Grafana).

Что входит в разработку

  • Проектирование API под требования мобильного клиента
  • Настройка PostgreSQL + Alembic миграции
  • Auth (JWT)
  • CRUD-модули
  • Push-уведомления (Firebase Admin SDK)
  • Фоновые задачи (Celery)
  • Docker + CI/CD
  • Документация OpenAPI
  • Консультации на всех этапах

Сроки и стоимость

MVP (Auth + 3–5 ресурсов): от 2 до 3 недель. Полноценный бэкенд: от 1 до 3 месяцев. Стоимость рассчитывается индивидуально после анализа требований. Наши инженеры с опытом 50+ проектов гарантируют качество и соблюдение сроков. Закажите разработку бэкенда под ключ — получите консультацию уже сегодня.

Архитектура мобильных приложений

Приложение собрано в одном ViewController на 2000 строк. Сетевые вызовы, бизнес-логика, обновление UI — всё в одном месте. Добавить новую фичу без регрессии сложно, написать тест невозможно. Это не «плохой код» — это отсутствие архитектуры. И это встречается чаще, чем можно ожидать, даже в production-приложениях с миллионом пользователей.

Мы проектируем архитектуру под ключ: от выбора паттерна до полной структуры проекта с тестами и документацией. За 7–10 дней получаете чистый модульный код, готовый к масштабированию.

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

MVVM: базовый паттерн

Model-View-ViewModel — стандарт для iOS (SwiftUI + Combine/async, UIKit + Combine) и Android (Jetpack ViewModel + StateFlow + Compose). ViewModel содержит состояние UI и бизнес-логику. View только отображает состояние и передаёт намерения пользователя в ViewModel. Model — данные и их источник.

Ключевое правило: ViewModel не знает об UIKit или Android View-классах. Нет импортов UIKit, нет Context-зависимостей (кроме Application context через Hilt). Это гарантирует тестируемость: ViewModel тестируется как чистый Kotlin/Swift-код без Android Instrumented Test.

MVVM закрывает 70% потребностей. Остальные 30% — где нужна строгая изоляция фич, масштабирование команды, сложный flow управления состоянием.

Clean Architecture: когда MVVM недостаточно

Добавляет слои поверх MVVM:

Domain-слой — бизнес-логика, независимая от платформы. UseCase (или Interactor) содержит одно бизнес-правило: GetUserOrdersUseCase, PlaceOrderUseCase. Зависит только от интерфейсов (protocol/interface), не от конкретных реализаций.

Data-слой — реализация репозиториев. OrderRepositoryImpl реализует OrderRepository из domain. Знает про Retrofit, Room, UserDefaults. ViewModel не знает, откуда данные — из сети или кеша.

Presentation-слой — ViewModel + View. Знает о Domain, не знает о Data.

Dependency rule: зависимости направлены только внутрь. Domain не зависит ни от чего. Data и Presentation зависят от Domain.

Presentation → Domain ← Data

Это даёт возможность подменять реализацию: тест использует in-memory репозиторий вместо сетевого, интерфейс остаётся тем же.

Практическая оговорка: Clean Architecture добавляет файлы и слои. Для небольшого приложения это overhead. Оправдан от ~15 фич и при команде 3+ разработчиков.

BLoC для Flutter: предсказуемый поток состояний

BLoC (Business Logic Component) — стандартный паттерн в Flutter-сообществе. Библиотека flutter_bloc реализует его через два типа: Bloc (Event → State) и Cubit (State без Events, только методы).

Bloc обрабатывает Event и эмитирует новый State через on<EventType> хендлеры. Состояние иммутабельно — новый объект на каждое изменение. BlocBuilder перерисовывает только ту часть дерева, где изменился state.

// Event
abstract class CartEvent {}
class AddItemToCart extends CartEvent {
  final String productId;
  AddItemToCart(this.productId);
}

// State
abstract class CartState {}
class CartLoaded extends CartState {
  final List<CartItem> items;
  CartLoaded(this.items);
}

// Bloc
class CartBloc extends Bloc<CartEvent, CartState> {
  CartBloc(this._cartRepository) : super(CartLoaded([])) {
    on<AddItemToCart>(_onAddItem);
  }

  Future<void> _onAddItem(AddItemToCart event, Emitter<CartState> emit) async {
    final current = state as CartLoaded;
    final updated = await _cartRepository.addItem(event.productId);
    emit(CartLoaded(updated));
  }
}

Преимущество BLoC — тестируемость. blocTest из bloc_test пакета позволяет проверить: при таком-то Event, с таким-то начальным State, BLoC должен эмитировать такой-то State. Без UI, без моков для Flutter-фреймворка.

VIPER: для крупных iOS-проектов

VIPER (View, Interactor, Presenter, Entity, Router) — наиболее строгое разделение обязанностей для iOS. Каждый компонент имеет протокол и конкретную реализацию.

  • View — только UI, делегирует всё Presenter
  • Interactor — бизнес-логика, работа с сетью и данными
  • Presenter — посредник между View и Interactor, форматирует данные для View
  • Entity — модели данных (чистые структуры)
  • Router — навигация между модулями

Каждый модуль (экран или фича) — отдельный VIPER-модуль. Это исключает coupling между фичами и позволяет большим командам работать параллельно без конфликтов.

Цена: много файлов, много протоколов. Шаблонный код генерируется через Sourcery или кастомные Xcode-шаблоны. VIPER оправдан для приложений с 10+ разработчиками и 50+ экранами.

TCA (The Composable Architecture)

TCA от Point-Free — более современная альтернатива VIPER для iOS/macOS. Основные концепции: State (иммутабельное состояние фичи), Action (все возможные события), Reducer (State + Action → новый State + Effect), Store (хранит State, обрабатывает Actions).

Scope позволяет composable строить большие фичи из маленьких: родительский Reducer делегирует часть State дочернему. Каждая фича тестируется изолированно через TestStore с точным контролем над Effects.

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

Какой паттерн выбрать под вашу задачу?

Оценим проект за 1 день — подберём архитектуру с учётом размера команды, платформы и планов роста.

Паттерн Платформа Команда Когда выбирать
MVVM iOS, Android, Flutter 1–5 Стартовый стандарт, MVP, небольшие проекты
MVVM + Clean iOS, Android 3–10 Средние проекты, тестируемость критична
BLoC Flutter 2–8 Flutter с предсказуемым state management
VIPER iOS 5–20 Крупные iOS-проекты, модульная архитектура
TCA iOS/macOS 3–15 Строгая тестируемость, Swift Concurrency

Универсального ответа нет. Архитектуру выбирают под размер команды, требования к тестируемости и горизонт поддержки приложения.

Что входит в нашу работу

  • Аудит текущей архитектуры (если приложение уже существует) — выявим узкие места и регрессионные зоны.
  • Проектирование модульной структуры с чёткими границами слоёв и правилами зависимостей.
  • Создание каркаса проекта (Scaffold) с внедрением DI, организации папок и настройки линтеров.
  • Написание юнит-тестов для слоя домена и ViewModel — минимум 80% покрытия ключевых use case.
  • Подготовка документации — архитектурные диаграммы, README с правилами модификации кода, инструкция для онбординга новых разработчиков.
  • Передача рабочего репозитория с CI-пайплайном (GitHub Actions / Bitrise), настроенным запуском тестов и статическим анализом.

Всё это входит в стоимость проектирования. Дополнительно — поддержка на этапе внедрения: консультации команды, code review первых pull request.

Что происходит без архитектуры

Типичный сценарий через 18 месяцев без архитектуры: 40% времени разработки уходит на дебаг регрессий. Новый разработчик разбирается в коде неделю перед тем, как сделать первый PR. Тесты не пишутся, «потому что сложно мокировать». Добавление новой фичи требует понимания половины кодовой базы.

Выбор архитектуры на старте — это инвестиция с возвратом через 3–6 месяцев. По нашим данным, правильно спроектированная архитектура с MVVM + Clean даёт в 3 раза меньше регрессий по сравнению с монолитным ViewController. А затраты на её внедрение окупаются за 2–3 спринта.

Согласно рекомендациям Apple по проектированию приложений, разделение ответственности — ключевой фактор устойчивости кода (https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/ImplementingaViewController.html).

Почему стоит доверить архитектуру профессионалам?

Неправильный выбор паттерна на старте ведёт к переписыванию половины кода через год. Мы видели десятки проектов, где попытка сэкономить на архитектуре оборачивалась многомесячным рефакторингом. У нас за плечами 10+ лет коммерческой разработки, опыт работы с приложениями от 1 до 50 разработчиков. Мы помогаем избежать типовых ошибок:

  • Overengineering для простого MVP (назначаем MVVM, а не VIPER).
  • Отсутствие dependency injection — подключаем Hilt/Koin/Dagger уже на старте.
  • Игнорирование тестируемости — закладываем протоколы/интерфейсы с первого коммита.

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

Дополнительная таблица: сравнение затрат на внедрение

Паттерн Время проектирования Количество файлов на 1 экран Время написания тестов
MVVM 2–3 дня 5–7 1 день
MVVM + Clean 4–5 дней 10–12 2 дня
BLoC 3–4 дня 6–8 1.5 дня
VIPER 5–7 дней 12–15 2.5 дня
TCA 5–6 дней 8–10 2 дня

Время указано для команды из 2–3 разработчиков. С нашим шаблоном (generator) стартовый каркас готов за 1 день вне зависимости от выбранного паттерна.