Налаштування сховища медіафайлів мобільного додатку (S3/Cloud Storage)

Завантаження фото та відео з мобільного додатку — завдання, яке легко недооцінити. Один запит на 50 МБ відео через бекенд-проксі створює колосальне навантаження на сервер, збільшує час відповіді та витрачає подвійний трафік. Користувачі кидають завантаження, якщо воно триває довше трьох секунд. Ми пропонуємо перевірену архітектуру: presigned URL → пряме завантаження з клієнта в S3 або GCS. Бекенд тільки видає токен і отримує підтвердження — вся важкість лягає на хмарну інфраструктуру. Такий підхід під ключ знижує навантаження на ваш сервер, прискорює віддачу контенту та гарантує безпеку. Наш досвід — понад 5 років інтеграції хмарних сховищ у мобільні додатки для iOS та Android.

Чому варто завантажувати медіа безпосередньо в S3?

Пряме завантаження через presigned URL вирішує проблеми з продуктивністю та надійністю. Порівняйте з проксі-методом:

Ми наполегливо рекомендуємо пряме завантаження для медіа — це знижує вартість інфраструктури та підвищує чуйність додатку. Офіційна документація AWS: Presigned URLs.

Порівняння провайдерів хмарного зберігання

R2 та B2 сумісні з S3 API — один і той же клієнтський код, тільки інший endpoint. Вибір провайдера залежить від регіону трафіку та бюджету. Наприклад, для проєктів з великим вихідним трафіком Cloudflare R2 може скоротити витрати на egress до нуля.

Як ми реалізуємо завантаження з прогресом?

Користувач бачить progress bar — це не опціонально для відео. Кроки реалізації:

1. Додаток запитує у бекенда presigned URL, передаючи тип та розмір файлу.
2. Бекенд генерує тимчасовий токен з обмеженими правами (наприклад, PUT-дозвіл на конкретний об'єкт).
3. Клієнт завантажує файл безпосередньо в хмарне сховище, використовуючи отриманий URL та стандартні механізми відстеження прогресу.

iOS через URLSession.uploadTask з делегатом:

class MediaUploader: NSObject, URLSessionTaskDelegate {
    private lazy var session: URLSession = {
        URLSession(configuration: .default, delegate: self, delegateQueue: nil)
    }()

    func upload(fileURL: URL, presignedURL: URL,
                progress: @escaping (Double) -> Void,
                completion: @escaping (Result<Void, Error>) -> Void) {
        var request = URLRequest(url: presignedURL)
        request.httpMethod = "PUT"
        request.setValue(fileURL.mimeType, forHTTPHeaderField: "Content-Type")

        let task = session.uploadTask(with: request, fromFile: fileURL)
        task.taskDescription = fileURL.lastPathComponent

        uploadCompletionHandlers[task.taskIdentifier] = completion
        uploadProgressHandlers[task.taskIdentifier] = progress
        task.resume()
    }

    func urlSession(_ session: URLSession, task: URLSessionTask,
                    didSendBodyData bytesSent: Int64,
                    totalBytesSent: Int64, totalBytesExpectedToSend: Int64) {
        let progress = Double(totalBytesSent) / Double(totalBytesExpectedToSend)
        uploadProgressHandlers[task.taskIdentifier]?(progress)
    }
}

На Android через OkHttp з кастомним RequestBody:

class ProgressRequestBody(
    private val file: File,
    private val contentType: MediaType,
    private val onProgress: (Int) -> Unit
) : RequestBody() {
    override fun contentType() = contentType
    override fun contentLength() = file.length()

    override fun writeTo(sink: BufferedSink) {
        val buffer = ByteArray(8192)
        var uploaded = 0L
        file.inputStream().use { input ->
            var bytesRead: Int
            while (input.read(buffer).also { bytesRead = it } != -1) {
                sink.write(buffer, 0, bytesRead)
                uploaded += bytesRead
                val progress = (uploaded * 100 / file.length()).toInt()
                onProgress(progress)
            }
        }
    }
}

Що робити з великими відеофайлами?

S3 вимагає multipart для файлів більше 5 МБ (рекомендується від 100 МБ). Переваги: паралельне завантаження частин, можливість відновити після переривання.

class S3MultipartUploader(private val s3Client: S3Client) {
    suspend fun upload(bucketName: String, key: String, file: File): String {
        // 1. Ініціалізуємо multipart upload
        val createResponse = s3Client.createMultipartUpload {
            bucket = bucketName
            this.key = key
            contentType = file.detectMimeType()
        }
        val uploadId = createResponse.uploadId!!

        val partSize = 10 * 1024 * 1024L // 10 МБ на частину
        val parts = mutableListOf<CompletedPart>()

        try {
            file.inputStream().use { stream ->
                var partNumber = 1
                val buffer = ByteArray(partSize.toInt())
                var bytesRead: Int

                while (stream.read(buffer).also { bytesRead = it } != -1) {
                    val partData = buffer.copyOf(bytesRead)
                    val uploadPartResponse = s3Client.uploadPart {
                        bucket = bucketName
                        this.key = key
                        this.uploadId = uploadId
                        this.partNumber = partNumber
                        body = ByteStream.fromBytes(partData)
                    }
                    parts.add(CompletedPart {
                        this.partNumber = partNumber
                        eTag = uploadPartResponse.eTag
                    })
                    partNumber++
                }
            }

            // 3. Завершуємо multipart upload
            s3Client.completeMultipartUpload {
                bucket = bucketName
                this.key = key
                this.uploadId = uploadId
                multipartUpload = CompletedMultipartUpload { this.parts = parts }
            }

            return "https://$bucketName.s3.amazonaws.com/$key"
        } catch (e: Exception) {
            // Очищаємо незавершений upload — інакше оплачується
            s3Client.abortMultipartUpload {
                bucket = bucketName
                this.key = key
                this.uploadId = uploadId
            }
            throw e
        }
    }
}

abortMultipartUpload при помилці — важливо. Незавершені multipart uploads продовжують тарифікуватися в AWS. Додайте Lifecycle Rule на видалення незавершених uploads через 7 днів як страховку.

Обробка медіа перед завантаженням

Відео 4K 200 МБ безпосередньо в S3 — рідко потрібно. На клієнті перед завантаженням:

• Зображення: стиснення через UIGraphicsImageRenderer (iOS) або BitmapFactory.Options.inSampleSize (Android). WebP замість JPEG — краще співвідношення якості/розміру.
• Відео: транскодування через AVAssetExportSession (iOS) або MediaCodec/Transformer (Android) до 1080p/720p. Для React Native — react-native-video-processing.

// iOS: стиснення відео перед завантаженням
let exporter = AVAssetExportSession(asset: asset, presetName: AVAssetExportPreset1280x720)!
exporter.outputURL = outputURL
exporter.outputFileType = .mp4
exporter.shouldOptimizeForNetworkUse = true

await exporter.export()
// Після експорту — завантажуємо outputURL в S3

Клієнтське стиснення — компроміс: менше трафіку, швидше завантаження, але навантаження на CPU пристрою. Це дозволяє заощадити на зберіганні та вихідному трафіку (особливо при великих обсягах).

CDN для роздачі

S3 безпосередньо — тільки для приватних файлів. Публічні медіа (аватари, контент) — через CloudFront або Cloudflare CDN. Це кешування на edge-вузлах по всьому світу та HTTPS без додаткового налаштування. Підключення CDN може знизити затримки до 50 мс для користувачів у віддалених регіонах.

{
  "CORSRules": [
    {
      "AllowedOrigins": ["*"],
      "AllowedMethods": ["PUT", "POST"],
      "AllowedHeaders": ["*"],
      "ExposeHeaders": ["ETag"]
    }
  ]
}

Що входить у налаштування сховища медіа?

Ми надаємо комплексне рішення:

• Архітектурна схема інтеграції presigned URL
• Серверний endpoint для генерації токенів (вибираємо між API Gateway + Lambda або власним контролером)
• SDK-інтеграція на клієнтській стороні (iOS Swift/Kotlin/Flutter)
• Реалізація multipart upload для відео
• Налаштування CDN та політик життєвого циклу
• Тестування під навантаженням
• Документація з експлуатації
• Підтримка протягом 30 днів після здачі

Строки та вартість

Типовий проєкт займає від 1 до 3 тижнів залежно від складності та стеку. Ми оцінюємо кожен проєкт індивідуально — зв'яжіться з нами для консультації та отримайте попередню оцінку. Економія на egress-трафіку може скласти до 90% при використанні Cloudflare R2, а зниження навантаження на сервери — до 70% за рахунок прямого завантаження.

Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати консультацію. Досвід нашої команди — понад 5 років розробки мобільних додатків та 50+ успішних інтеграцій хмарних сховищ. Ми гарантуємо надійність та безпеку ваших медіаданих.

Як вибрати рішення для локального зберігання даних (Room, Core Data, Realm, Isar)?

Ми стикалися з ситуацією, коли додаток втрачає дані при втраті мережі — і це не просто баг, це провал сценарію. Користувач заповнив форму, натиснув «Відправити», отримав таймаут і втратив все. Або гірше: дані відправилися двічі через некоректну логіку повторної відправки. Правильно вибраний та налаштований шар сховища вирішує цю проблему раз і назавжди. Неправильний вибір може коштувати команді місяців переписування коду та втрати до 70% часу на синхронізацію. Наш досвід — 10+ років у мобільній розробці, понад 50 проектів з офлайн-сховищами — підтверджує: вибір рішення визначає 80% майбутніх проблем з продуктивністю та синхронізацією.

На практиці вибір сховища визначається двома факторами: типом даних та вимогами до синхронізації, а не популярністю бібліотеки.

Room (Android) — обгортка над SQLite з compile-time верифікацією SQL-запитів. Якщо запит невалідний, збірка падає — це краще, ніж SQLiteException в рантаймі. Room добре інтегрується з Kotlin Flow та LiveData, що робить реактивні UI-оновлення прямолінійними. Основна складність — міграції схеми. @Database(version = N, exportSchema = true) з файлами міграцій в assets/databases/ — обов'язкова практика, інакше при оновленні додатка fallbackToDestructiveMigration() просто зітре дані користувача.

Core Data (iOS) — не база даних, а фреймворк управління графом об'єктів поверх SQLite (або XML, або in-memory). NSPersistentContainer з viewContext для читання на main thread та newBackgroundContext() для запису — базова схема. Проблема починається, коли розробник робить save() в viewContext з фонового потоку: EXC_BAD_ACCESS в рандомний момент, відтворюється раз на тиждень, в крешлозі майже нічого корисного. Потрібно використовувати performAndWait або perform для кожного контексту строго в своєму потоці. Apple Core Data Programming Guide рекомендує саме такий підхід.

Realm виграє там, де потрібна швидкість роботи з великими наборами об'єктів та вбудована реактивність через Results + observe(). Realm зберігає об'єкти напряму, без маппінгу ORM, тому читання не потребує десеріалізації. За нашими вимірами, Realm обробляє читання в 2–3 рази швидше Core Data при об'ємі понад 10 000 об'єктів. На Flutter Realm SDK (ex-MongoDB Realm) підтримує Device Sync — але це вже managed-сервіс з окремою інфраструктурою.

Hive та Isar — Flutter-специфічні рішення. Hive — key-value сховище, швидко, просто, підходить для налаштувань та кешів. Isar — повноцінна документо-орієнтована БД з індексами, написана на Rust, компілюється в нативний код. Для Flutter-додатків з офлайн-функціональністю Isar зараз переважніше: вбудований query builder з типобезпечними фільтрами, транзакції, watchObject/watchQuery для реактивності.

Зв'яжіться з нами, щоб отримати безкоштовний аудит вашого поточного сховища та рекомендації з оптимізації — це зекономить вам сотні годин розробки та до 60% трафіку на серверні запити.

Чому офлайн-синхронізація — найскладніша частина?

Локальне сховище саме по собі нескладне. Складність — у синхронізації з сервером при наявності конфліктів.

Найчастіший патерн — optimistic updates з rollback. Користувач редагує запис, UI відображає зміну миттєво, фоновий запит йде на сервер. Якщо сервер повертає помилку — відкочуємо локальний стейт. Виглядає просто. На практиці: якщо користувач встиг піти з екрану і повернутися, а відкат відбувся через 3 секунди — UX зламаний. Потрібна явна черга операцій зі станом (PENDING, SYNCED, FAILED) в окремій таблиці.

На Android для фонової синхронізації використовуємо WorkManager з Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Важно не забыть про setInputMerger(ArrayCreatingInputMerger::class) при батчинге задач — інакше при кількох одночасних запусках дані затираються. Типова реалізація черги операцій:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

На iOS аналог — BGTaskScheduler з BGProcessingTaskRequest. Обмеження iOS на фоновий час виконання (~30 секунд для refresh tasks) означають, що синхронізація повинна бути інкрементальною: не «синхронізувати все», а «синхронізувати наступні N записів, зберегти курсор».

Конфлікти при мультипристроєвій роботі вирішуються одним із трьох підходів:

• Last-write-wins по updated_at (найпростіший, втрачає дані при одночасному редагуванні)
• Server-wins (клієнт завжди приймає серверну версію)
• Three-way merge (складно, потрібен спільний предок — підходить для документів)

У більшості B2C-додатків достатньо last-write-wins з вектором часу на рівні користувача, але при спільному редагуванні потрібен CRDTs-підхід — тоді дивимося на Automerge або Yjs з мобільними біндингами.

Як ми будуємо шар сховища

Репозиторний патерн — не опціональний, а обов'язковий. UserRepository не знає, звідки дані: з Room, Realm чи мережі. ViewModel викликає repository.getUser(id), отримує Flow/Stream, відображає дані. Логіка кешування — всередині репозиторія.

Для Flutter типова архітектура: Isar для персистентності, Riverpod для управління стейтом, ConnectivityPlus для визначення стану мережі, кастомний SyncService з чергою операцій. Riverpod AsyncNotifier зручно покриває логіку «показати кеш, оновити з мережі, показати нові дані». Приклад репозиторія з кешуванням:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // 1. спробувати з локального сховища
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // 2. інакше з мережі
    final remote = await api.fetchUser(id);
    // 3. зберегти локально
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Окрема тема — шифрування. Якщо додаток зберігає медичні дані, платіжні картки або корпоративні документи, SQLCipher (Android) та NSFileProtection (iOS) — не опція. Realm підтримує шифрування нативно через ключ у 64 байти, який потрібно зберігати в Keychain/Keystore, а не в SharedPreferences. Економія на безпеці може обійтися у витік даних з гучними наслідками.

Що входить в роботу

Ми гарантуємо прозорий процес і фіксуємо кожен етап:

Бажаєте уникнути типових помилок при проектуванні сховища? Зверніться до нас — ми допоможемо спроектувати надійне локальне сховище з нуля або доопрацювати існуюче.

Які етапи роботи?

Починаємо з аудиту вимог: які дані, який обсяг, чи потрібна синхронізація, чи можливі конфлікти. На цьому етапі стає зрозуміло, Core Data чи SQLite-based рішення, чи потрібен Realm Sync або достатньо простого REST-поллінгу.

Далі — проектування схеми з урахуванням міграцій. Схему змінюють у будь-якому проекті — питання не «чи будуть міграції», а «наскільки болісно вони пройдуть». Експортуємо схему в JSON, зберігаємо в репозиторії, пишемо тести на міграцію кожної версії.

Розробка йде з покриттям репозиторного шару юніт-тестами: моки мережевого шару, реальна in-memory база для тестування запитів. Перед релізом — профілювання запитів через Android Profiler (вкладка Database Inspector) або Core Data debug флаги (-com.apple.CoreData.SQLDebug 1).

Термін реалізації шару сховища з базовою офлайн-синхронізацією — від 2 до 6 тижнів залежно від складності схеми та вимог до конфлікт-резолюції. Вартість розраховується індивідуально після аудиту вашого проекту. Замовте розробку під ключ — отримайте консультацію з вибору оптимального стеку та міграціям.