Розробка Ruby on Rails бекенду для мобільних додатків
Rails вибирають для мобільного бекенду коли потрібна швидкість розробки MVP, стартапний темп, або коли продукт вже живе на Rails та масштабується через горизонтальне додавання інстансів. Екосистема зріла: 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-політики для авторизації
Версіонування 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, push-ами — 2–4 тижні. Продуктовий бекенд з платежами, реалтаймом через ActionCable та повноцінним DevOps — 8–12 тижнів.