Разработка серверной части (Backend) для мобильного приложения на Ruby on Rails
Rails выбирают для мобильного бэкенда когда нужна скорость разработки MVP, стартапный темп, или когда продукт уже живёт на Rails и масштабируется через горизонтальное добавление инстансов. Ecosystem зрелый: Devise, Pundit, Sidekiq, Active Storage — всё это production-ready инструменты с годами боевой проверки.
Что чаще ломается в Rails API для мобайла
ActiveRecord callbacks цепляются неожиданно. after_create :send_push_notification в модели User — и каждый User.create! в тестах, rake-задачах или data migration пытается отправить FCM-запрос. Мобильный клиент здесь ни при чём, но регрессию в production ловить неприятно. Для side effects используем Service Objects или обработку событий через ActiveSupport::Notifications.
N+1 через сериализацию. ActiveModelSerializers или fast_jsonapi (jsonapi-serializer) с has_many отношениями — если не передать include:, каждый вложенный объект грузится отдельным запросом. Диагностируем через Bullet gem в development, фиксируем через includes(:association) до сериализации.
Стек для мобильного API
Rails 7.x в API-only режиме (rails new myapp --api), PostgreSQL, Redis + Sidekiq для фоновых задач. Аутентификация — Devise + devise-jwt (JWT через JWTSessions) или Rodauth для более гибкого контроля над токенами.
Push-уведомления — гем rpush: поддерживает APNs (HTTP/2) и FCM, управляет connection pool, умеет батч-отправку и логирует доставку. Sidekiq-джоб для массовых рассылок с bulk_push не нагружает HTTP-handler.
Хранение файлов — Active Storage с S3-адаптером. Для мобильного клиента — presigned URL через blob.service_url_for_direct_upload, чтобы клиент загружал напрямую в S3, минуя Rails-сервер.
Кейс: lifestyle-приложение для iOS/Android, 40 000 MAU. Rails 6 API, PostgreSQL, Sidekiq. Endpoint /api/v1/feed — лента с постами, лайками, комментариями. Время ответа доходило до 1.2 секунды. Проблема: сериализатор подгружал user, likes_count, comments_count отдельными запросами для каждого поста. Решение: переход на jsonapi-serializer с явным includes(:user) и counter_cache: true для лайков и комментариев на уровне БД. Результат: 80ms на типичной выборке 20 постов.
Организация кода
Rails API-only проект с сервисными объектами:
app/
├── controllers/api/v1/ — тонкие контроллеры, только HTTP-логика
├── services/ — бизнес-логика (CreateOrderService, ProcessPaymentService)
├── serializers/ — jsonapi-serializer
├── jobs/ — Sidekiq-джобы
└── policies/ — Pundit-политики для авторизации
Versioning API через namespace (/api/v1, /api/v2) — обязательно с первого дня. Мобильный клиент обновляется медленно, старые версии живут 6–12 месяцев параллельно с новыми.
Производительность и кеширование
Russian Doll Caching — фрагментное кеширование в Rails через cache(model) работает и в API-режиме через etag. Для агрегатов (счётчики, рейтинги) — Rails.cache с Redis, инвалидация через after_commit callback.
Rack::Attack для rate limiting: ограничиваем по IP и по токену, чтобы мобильный клиент с зависшим retry-циклом не положил БД.
Сроки: MVP API с аутентификацией, базовыми CRUD, пушами — 2–4 недели. Продуктовый бэкенд с платежами, реалтаймом через ActionCable и полноценным DevOps — 8–12 недель.