Firebase Storage: що це, завантаження файлів та хмарне сховище

Що таке Firebase Storage і як він влаштований

Firebase Storage — це хмарне об'єктне сховище, побудоване на базі Google Cloud Storage, яке надає SDK для Android, iOS та веб-платформ. Кожен файл зберігається у вигляді об'єкта в бакеті Google Cloud і адресується шляхом, що нагадує файлову систему: gs://bucket-name/path/to/file.jpg. Розмір одного файлу може сягати 5 ТБ, що дозволяє зберігати будь-які медіадані без попередньої компресії.

Архітектура Firebase Storage використовує референсну модель посилань (gsutil references), а не класичну ієрархію папок, хоча SDK надає інтерфейс із директоріями для зручності розробника. Фізично всі об'єкти зберігаються в плоскому просторі імен бакета, а віртуальні папки створюються за допомогою префіксів шляху. Це забезпечує лінійну продуктивність пошуку незалежно від кількості файлів.

Ключова перевага Firebase Storage перед прямим використанням Google Cloud Storage — вбудована інтеграція з Firebase Authentication та Security Rules. Розробнику не потрібно налаштовувати окремі IAM-ролі та сервісні акаунти: правила доступу пишуться декларативною мовою, схожою на Firebase Realtime Database Rules, і застосовуються автоматично при кожному запиті.

Структура бакета та шляхи до файлів

Бакет Firebase Storage створюється автоматично при підключенні сервісу в консолі Firebase. Шлях до файлу будується за принципом /ім'я_папки/ім'я_файлу і може містити вкладені рівні. Рекомендується організовувати шляхи за схемою /users/{userId}/images/{imageId}.jpg для ізоляції даних між користувачами. Така структура спрощує написання правил безпеки, оскільки шлях містить ідентифікатор власника.

Важливо розуміти, що Firebase Storage не є реляційною базою даних або файловим сервером у класичному розумінні. Це об'єктне сховище, оптимізоване для операцій читання та запису цілих файлів. Оновлення частини файлу неможливе: при повторному завантаженні з тим самим шляхом старий об'єкт замінюється новим. Для зберігання невеликих структурованих даних використовуйте Firebase Realtime Database або Cloud Firestore.

Тарифи та ліміти Firebase Storage

Ціноутворення Firebase Storage залежить від обсягу збережених даних та кількості операцій. Безкоштовний тариф (Spark) включає 5 ГБ сховища, 20 000 операцій запису та 50 000 операцій читання на день. Платний тариф (Blaze) оплачується за фактом використання: $0,026 за ГБ збережених даних, $0,05 за 10 000 операцій запису та $0,004 за 10 000 операцій читання. Додатково стягується плата за вихідний трафік.

Для більшості мобільних застосунків з кількома тисячами користувачів безкоштовного ліміту достатньо на етапі прототипування та тестування. При масштабуванні до сотень тисяч користувачів витрати на Storage рідко перевищують $50–$100 на місяць при оптимізованому підході до завантаження та кешуванні на стороні клієнта.

Як завантажувати файли в Firebase Storage

Завантаження файлу в Firebase Storage виконується через відповідний метод SDK, який приймає шлях у сховищі та дані файлу (масив байтів, URI, потік або Bitmap). SDK автоматично керує з'єднанням, сегментує файл на частини при великому розмірі та надає зворотні виклики для відстеження прогресу. Завантаження виконується безпосередньо з клієнтського пристрою на Google Cloud, минаючи ваш сервер, що знижує навантаження на власну інфраструктуру.

Для Android Firebase Storage SDK використовує класи StorageReference та UploadTask. StorageReference створюється з кореневого шляху через Firebase.storage.reference і вказує на конкретний файл у бакеті. UploadTask повертає слухачі прогресу, призупинення та завершення. При обриві з'єднання UploadTask автоматично відновлює завантаження з останнього успішно переданого байта — ця поведінка називається довантаженням (resumable upload).

Метадані файлу (Content-Type, кастомні поля) передаються окремим об'єктом SettableMetadata при старті завантаження. Правильне встановлення Content-Type критично важливе для коректного відображення файлів у браузері та роботи CDN-кешування. Firebase Storage підтримує всі стандартні MIME-типи: image/jpeg, image/png, video/mp4, application/pdf та інші.

Управління метаданими при завантаженні

Метадані файлу містять системні поля (Content-Type, Cache-Control, Content-Disposition) та користувацькі пари ключ-значення (customMetadata). Системні поля керують HTTP-заголовками при вивантаженні. Наприклад, Cache-Control: public, max-age=31536000 вмикає кешування відповіді на рік, що суттєво знижує кількість повторних вивантажень одного й того ж файлу та економить трафік.

Користувацькі метадані зручні для передачі додаткової інформації про файл без створення окремої колекції в Firestore. Наприклад, у полі uploadedBy можна зберегти userId користувача, який завантажив файл, що спрощує реалізацію галерей з авторським контентом. Кастомні метадані не захищені Security Rules окремо — доступ до них регулюється тими ж правилами, що й до самого файлу.

Множинне завантаження та пакетна обробка

При необхідності завантажити багато файлів одночасно (наприклад, фотографії з галереї) не рекомендується запускати незалежні UploadTask паралельно без обмежень. На мобільних пристроях паралельне завантаження більш ніж 3–5 файлів призводить до перевантаження мережевого стеку та тайм-аутів. Оптимальна стратегія — використовувати конкурентний ліміт 3 або послідовне завантаження з відображенням спільного прогресу.

Для серверної обробки після завантаження (генерація thumbnail, стиснення, модерація контенту) використовуйте тригер Firebase Cloud Functions: functions.storage.object().onFinalize(). Ця функція викликається автоматично після завершення завантаження кожного файлу і може зберегти оброблену копію за іншим шляхом. Докладніше про це — у розділі про типові сценарії.

Вивантаження файлів та управління посиланнями

Firebase Storage підтримує два способи вивантаження: пряме вивантаження через SDK з отриманням масиву байтів або локального файлу, та отримання прямого download URL для доступу через HTTP. Прямий URL можна використовувати для відображення зображень у ImageView, у WebView або для надання посилання користувачеві. Download URL генерується з токеном безпеки, який можна відкликати в консолі Firebase.

Метод storageReference.downloadUrl повертає URL виду https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token}. Токен безпеки автоматично включається в URL при генерації, тому посилання можна передавати третім особам (наприклад, у месенджері) без ризику несанкціонованого доступу. Однак якщо токен скомпрометовано, його можна відкликати через консоль Firebase у розділі Storage — після цього всі посилання з цим токеном перестануть працювати.

Для кешування вивантажених файлів на клієнті використовуйте локальне сховище та механізм ETag або MD5-хеш. Firebase Storage повертає HTTP-заголовок ETag при запиті файлу, який можна звірити з локально збереженим значенням і уникнути повторного вивантаження незмінених файлів. Це особливо корисно для медіаконтенту: аватарів, обкладинок, прев'ю — файлів, які оновлюються рідко, але запитуються часто.

Прямі download URL та їх безпека

Download URL з токеном — це основний спосіб надання доступу до файлів для неавтентифікованих користувачів (наприклад, для відображення зображення в стрічці новин). Токен генерується один раз і не змінюється до відкликання, тому URL можна зберегти в базі даних (наприклад, поряд із полем avatarUrl у Firestore). При зміні аватара старий файл видаляється, а новий URL генерується та зберігається.

Важливо пам'ятати: наявність download URL не скасовує Security Rules. Якщо правило забороняє читання файлу, метод downloadUrl поверне помилку Permission Denied. Це означає, що навіть знаючи правильний шлях до файлу, неавтентифікований клієнт не зможе отримати посилання. Після отримання URL доступ до файлу здійснюється через HTTP, минаючи Security Rules — тому токен є єдиним захистом download посилання.

Кешування та робота з ETag

HTTP ETag — це ідентифікатор версії файлу, який змінюється при кожній зміні вмісту. Firebase Storage автоматично повертає ETag у відповіді на GET-запит. Клієнтський застосунок може зберегти ETag у локальному кеші та при повторному запиті відправити заголовок If-None-Match: {etag}. Якщо файл не змінився, сервер поверне статус 304 Not Modified без передачі даних.

Для реалізації інтелектуального кешування в мобільному застосунку використовуйте комбінацію локальної файлової системи та бази даних (наприклад, Room для зберігання пар шлях-ETag). При завантаженні файлу перевірте ETag із БД: якщо він збігається з серверним, використовуйте локальну копію. Такий підхід скорочує трафік на 60–80% для статичних медіафайлів і прискорює завантаження екранів із галереями.

Правила безпеки для Firebase Storage

Security Rules — це декларативна мова розмежування доступу до файлів у Firebase Storage, що виконується на стороні сервера Firebase. Кожне правило прив'язується до шляху в бакеті та визначає умови, за яких дозволена операція читання (read) або запису (write). Правила перевіряються перед кожним запитом і не можуть бути обійдені клієнтським кодом. Це єдина лінія захисту даних від неавторизованого доступу.

Базове правило — доступ лише автентифікованим користувачам: allow read, write: if request.auth != null. Таке правило гарантує, що лише користувачі, які ввійшли в систему, можуть читати та записувати файли. Для більш тонкого налаштування використовується змінна request.auth.uid, яка містить ідентифікатор поточного користувача. Порівнюючи uid із частиною шляху до файлу, можна створити ізольоване сховище для кожного користувача.

Важливо: Security Rules не є механізмом валідації вмісту. Якщо потрібно перевіряти тип файлу, його розмір або наявність шкідливого коду, використовуйте правило request.resource, яке містить метадані завантаженого файлу. Доступні властивості request.resource.size (розмір файлу), request.resource.contentType (MIME-тип) та request.resource.md5Hash (контрольна сума). Однак повна перевірка вмісту виконується на серверній стороні через Cloud Functions.

Приклад правил для користувацького контенту

Типова конфігурація для застосунку з користувацькими аватарами та галереєю виглядає наступним чином. Користувач може записувати лише у свою директорію /users/{userId}/, але читати може будь-який файл у цій директорії (галерея публічна). Розмір файлу обмежений 5 МБ, а тип — лише зображення. Така комбінація правил покриває 80% сценаріїв використання Firebase Storage у соціальних та UGC-застосунках.

Порада з безпеки: ніколи не використовуйте правило allow read, write: if true для всього бакета. Це відкриває доступ на запис будь-кому, хто знає ваш projectId. У 2025 році почастішали атаки на незахищені бакети Firebase, коли зловмисники використовували відкритий доступ для зберігання нелегального контенту. Завжди починайте з мінімально необхідних прав і розширюйте їх лише при явній необхідності.

Валідація вмісту через Cloud Functions

Cloud Functions тригер functions.storage.object().onFinalize() дозволяє виконати перевірку вмісту після завантаження. Якщо файл не проходить валідацію (наприклад, містить вірус або порушує правила платформи), функція може видалити його та повідомити користувача. Це єдиний спосіб перевірки фактичного вмісту, оскільки Security Rules бачать лише метадані (розмір та MIME-тип), а не бінарні дані.

Приклад валідації: функція на Node.js вивантажує завантажений файл у тимчасову директорію, проганяє його через антивірусний детектор (наприклад, ClamAV), і якщо загрозу виявлено — видаляє файл та записує подію в Firebase Crashlytics. Час виконання функції обмежений 540 секундами, що достатньо для перевірки файлів розміром до 50 МБ.

Приклади коду для Firebase Storage на Kotlin

Розглянемо практичні приклади інтеграції Firebase Storage в Android-застосунок на Kotlin. Код використовує стандартні класи Firebase SDK та демонструє завантаження зображення з галереї пристрою, вивантаження файлу з відстеженням прогресу та отримання download URL. Всі приклади виконані з урахуванням обробки помилок та призупинення завдань при втраті з'єднання.

Перед використанням коду переконайтеся, що у файлі build.gradle додано залежність implementation(platform("com.google.firebase:firebase-bom:33.0.0")) та implementation("com.google.firebase:firebase-storage"). Firebase BOM автоматично підбирає сумісні версії всіх SDK, що виключає конфлікти версій.

Завантаження зображення з галереї

Перший приклад — завантаження файлу, вибраного користувачем через Intent ACTION_GET_CONTENT. Uri отриманого файлу передається в Firebase Storage SDK, який самостійно читає дані за цим Uri. Метод putFile приймає Uri та повертає UploadTask — об'єкт, через який можна відстежувати прогрес, призупиняти та відновлювати завантаження.

val storageRef = Firebase.storage.reference
val imageRef = storageRef.child(
    "users/${auth.uid}/profile.jpg"
)

val metadata = SettableMetadata().apply {
    contentType = "image/jpeg"
    customMetadata = mapOf(
        "uploadedBy" to auth.uid!!
    )
}

imageRef.putFile(imageUri, metadata)
    .addOnSuccessListener {
        Log.d("Storage", "Файл завантажено")
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "Помилка: ${e.message}")
    }

У прикладі вище змінна storageRef — це кореневе посилання на бакет проекту. Метод child приймає рядок шляху та повертає StorageReference, що вказує на конкретний файл. Якщо файл за вказаним шляхом уже існує, він буде перезаписаний. Метадані contentType та customMetadata передаються через об'єкт SettableMetadata, який прикріплюється до запиту putFile.

Вивантаження файлу з прогресом

Другий приклад демонструє вивантаження файлу з отриманням масиву байтів для відображення в ImageView. Метод getBytes(maxSize) завантажує весь файл у пам'ять. Для файлів більше 10 МБ використовуйте getFile(localUri) — він зберігає вміст безпосередньо в локальний файл без зберігання в оперативній пам'яті, що запобігає OutOfMemoryError.

val islandRef = storageRef.child("images/island.jpg")

val ONE_MEGABYTE: Long = 1024 * 1024
islandRef.getBytes(ONE_MEGABYTE)
    .addOnSuccessListener { bytes ->
        imageView.setImageBitmap(
            BitmapFactory.decodeByteArray(
                bytes, 0, bytes.size
            )
        )
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "Не вдалося завантажити: ${e.message}")
    }

Для отримання download URL (наприклад, щоб зберегти посилання в Firestore) використовується метод downloadUrl:

islandRef.downloadUrl.addOnSuccessListener { uri ->
    Log.d("Storage", "URL завантаження: $uri")
    // Зберегти uri.toString() у Firestore
}

Порада: downloadUrl генерується один раз і стабільний, поки не відкликаний. Зберігайте його в базі даних при першому завантаженні, а не запитуйте щоразу при відображенні файлу. Це скорочує кількість запитів до Firebase Storage та прискорює роботу UI.

Типові сценарії використання Firebase Storage

Firebase Storage застосовується в мобільних застосунках для зберігання будь-яких користувацьких та системних файлів. Найчастіші сценарії — аватари та фотографії профілю, зображення в стрічці контенту, відео та аудіофайли, документи (PDF, DOCX) для обміну між користувачами, а також резервне копіювання невеликого обсягу даних. У всіх цих випадках Storage виступає як спеціалізоване файлове сховище в зв'язці з Firestore для зберігання метаданих та посилань.

Соціальні застосунки — найпоширеніший кейс. Кожен користувач завантажує аватар, фотографії постів та медіафайли. Структура шляхів /users/{uid}/posts/{postId}/image.jpg дозволяє ізолювати дані та спрощує Security Rules. При видаленні користувача Cloud Function може пройти по всіх директоріях користувача та очистити сховище. За даними Firebase blog (2025), такий патерн використовується у 70% production-проектів на Firebase.

E-commerce застосунки використовують Firebase Storage для зберігання фотографій товарів, каталогів та PDF-файлів з інструкціями. У цьому випадку доступ до файлів зазвичай публічний (читання без автентифікації), а запис — лише для адміністраторів через Cloud Functions з перевіркою прав. Download URL товарів зберігається в Firestore поряд з іншими даними товару, що дозволяє відображати зображення без додаткових запитів до Storage.

Месенджери та чати зберігають у Firebase Storage зображення та голосові повідомлення, відправлені в діалогах. Шлях будується як /chats/{chatId}/messages/{messageId}.jpg. Доступ на читання — лише учасникам чату, що перевіряється через Security Rules із використанням даних із Firestore. Це один із небагатьох сценаріїв, де правило читає дані з іншої Firebase-служби: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid}).