Firebase Storage: यह क्या है, फ़ाइल अपलोड और क्लाउड स्टोरेज

Firebase Storage क्या है और यह कैसे काम करता है

Firebase Storage एक क्लाउड ऑब्जेक्ट स्टोरेज है जो Google Cloud Storage के ऊपर बनाया गया है और Android, iOS और वेब प्लेटफ़ॉर्म के लिए SDK प्रदान करता है। प्रत्येक फ़ाइल Google Cloud bucket में एक ऑब्जेक्ट के रूप में संग्रहीत होती है और फ़ाइल सिस्टम जैसे पथ से संबोधित की जाती है: gs://bucket-name/path/to/file.jpg. एक फ़ाइल 5 TB तक की हो सकती है, जो बिना पूर्व संपीड़न के किसी भी मीडिया डेटा को संग्रहीत करने की अनुमति देती है।

Firebase Storage की आर्किटेक्चर क्लासिक फ़ोल्डर पदानुक्रम के बजाय लिंक का रेफरेंस मॉडल (gsutil references) का उपयोग करती है, हालांकि SDK डेवलपर की सुविधा के लिए निर्देशिका इंटरफ़ेस प्रदान करता है। भौतिक रूप से, सभी ऑब्जेक्ट bucket के फ्लैट नेमस्पेस में संग्रहीत होते हैं, और वर्चुअल फ़ोल्डर पथ प्रीफ़िक्स का उपयोग करके बनाए जाते हैं। यह फ़ाइलों की संख्या की परवाह किए बिना रैखिक खोज प्रदर्शन सुनिश्चित करता है।

Google Cloud Storage के सीधे उपयोग की तुलना में Firebase Storage का मुख्य लाभ Firebase Authentication और Security Rules के साथ अंतर्निहित एकीकरण है। डेवलपर को अलग IAM भूमिकाएं और सेवा खाते कॉन्फ़िगर करने की आवश्यकता नहीं है: पहुंच नियम Firebase Realtime Database Rules के समान घोषणात्मक भाषा में लिखे जाते हैं और प्रत्येक अनुरोध पर स्वचालित रूप से लागू होते हैं।

bucket संरचना और फ़ाइल पथ

Firebase कंसोल में सेवा सक्षम करने पर Firebase Storage bucket स्वचालित रूप से बनाया जाता है। फ़ाइल पथ पैटर्न /फ़ोल्डर_नाम/फ़ाइल_नाम का अनुसरण करता है और इसमें नेस्टेड स्तर हो सकते हैं। उपयोगकर्ताओं के बीच डेटा को अलग करने के लिए /users/{userId}/images/{imageId}.jpg योजना के अनुसार पथों को व्यवस्थित करने की अनुशंसा की जाती है। यह संरचना सुरक्षा नियम लिखने को सरल बनाती है क्योंकि पथ में मालिक का पहचानकर्ता होता है।

यह समझना महत्वपूर्ण है कि Firebase Storage शास्त्रीय अर्थों में कोई रिलेशनल डेटाबेस या फ़ाइल सर्वर नहीं है। यह संपूर्ण फ़ाइलों को पढ़ने और लिखने के संचालन के लिए अनुकूलित ऑब्जेक्ट स्टोरेज है। आंशिक फ़ाइल अपडेट संभव नहीं है: यदि आप उसी पथ पर पुनः अपलोड करते हैं, तो पुराने ऑब्जेक्ट को नए से बदल दिया जाता है। छोटे संरचित डेटा को संग्रहीत करने के लिए, Firebase Realtime Database या Cloud Firestore का उपयोग करें।

Firebase Storage मूल्य निर्धारण और सीमाएं

Firebase Storage मूल्य निर्धारण संग्रहीत डेटा की मात्रा और संचालन की संख्या पर निर्भर करता है। मुफ़्त योजना (Spark) में प्रति दिन 5 GB स्टोरेज, 20,000 राइट संचालन और 50,000 रीड संचालन शामिल हैं। भुगतान योजना (Blaze) वास्तविक उपयोग के आधार पर शुल्क लेती है: $0.026 प्रति GB संग्रहीत डेटा, $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 के माध्यम से बनाई जाती है और bucket में एक विशिष्ट फ़ाइल को इंगित करती है। UploadTask प्रगति, ठहराव और पूर्णता के लिए लिसनर लौटाता है। जब कनेक्शन बाधित होता है, UploadTask स्वचालित रूप से अंतिम सफलतापूर्वक ट्रांसमिटेड बाइट से अपलोड फिर से शुरू करता है — इस व्यवहार को रिज़्यूमेबल अपलोड कहा जाता है।

फ़ाइल मेटाडेटा (Content-Type, कस्टम फ़ील्ड) अपलोड शुरू करते समय एक अलग SettableMetadata ऑब्जेक्ट के रूप में पास किया जाता है। ब्राउज़र में फ़ाइलों के सही प्रदर्शन और CDN कैशिंग के लिए Content-Type को सही ढंग से सेट करना महत्वपूर्ण है। 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 द्वारा अलग से संरक्षित नहीं है — उन तक पहुंच फ़ाइल के समान नियमों द्वारा नियंत्रित होती है।

एकाधिक अपलोड और बैच प्रोसेसिंग

जब आपको एक साथ कई फ़ाइलें अपलोड करने की आवश्यकता होती है (जैसे गैलरी से फ़ोटो), तो बिना सीमा के समानांतर में स्वतंत्र UploadTasks चलाने की अनुशंसा नहीं की जाती है। मोबाइल उपकरणों पर, 3–5 से अधिक फ़ाइलों का समानांतर अपलोड नेटवर्क स्टैक को ओवरलोड करता है और टाइमआउट का कारण बनता है। इष्टतम रणनीति 3 की समवर्ती सीमा या साझा प्रोग्रेस बार प्रदर्शन के साथ अनुक्रमिक अपलोड का उपयोग करना है।

अपलोड के बाद सर्वर-साइड प्रोसेसिंग (थंबनेल जनरेशन, संपीड़न, सामग्री मॉडरेशन) के लिए, Firebase Cloud Functions ट्रिगर का उपयोग करें: functions.storage.object().onFinalize(). यह फ़ंक्शन प्रत्येक फ़ाइल अपलोड पूरा होने के बाद स्वचालित रूप से कॉल किया जाता है और एक अलग पथ पर प्रोसेस्ड कॉपी सहेज सकता है। अधिक विवरण विशिष्ट उपयोग के मामलों अनुभाग में हैं।

फ़ाइलें डाउनलोड करना और लिंक प्रबंधित करना

Firebase Storage दो डाउनलोड विधियों का समर्थन करता है: SDK के माध्यम से प्रत्यक्ष डाउनलोड (बाइट ऐरे या स्थानीय फ़ाइल प्राप्त करना) और HTTP पहुंच के लिए प्रत्यक्ष डाउनलोड URL प्राप्त करना। प्रत्यक्ष URL का उपयोग ImageView, WebView में इमेज प्रदर्शित करने या उपयोगकर्ता को लिंक प्रदान करने के लिए किया जा सकता है। डाउनलोड URL एक सुरक्षा टोकन के साथ उत्पन्न होता है जिसे Firebase कंसोल में रिवोक किया जा सकता है।

storageReference.downloadUrl विधि https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token} प्रारूप में URL लौटाती है। सुरक्षा टोकन जनरेशन के दौरान स्वचालित रूप से URL में शामिल होता है, इसलिए लिंक को अनधिकृत पहुंच के जोखिम के बिना तीसरे पक्ष (जैसे मैसेंजर में) के साथ साझा किया जा सकता है। हालांकि, यदि टोकन से समझौता किया जाता है, तो इसे Firebase कंसोल में Storage अनुभाग के माध्यम से रिवोक किया जा सकता है — उसके बाद, इस टोकन वाले सभी लिंक काम करना बंद कर देंगे।

क्लाइंट पर डाउनलोड की गई फ़ाइलों को कैश करने के लिए, ETag तंत्र या MD5 हैश के साथ स्थानीय स्टोरेज का उपयोग करें। Firebase Storage फ़ाइल का अनुरोध करते समय HTTP शीर्षक ETag लौटाता है, जिसकी तुलना अपरिवर्तित फ़ाइलों को पुनः डाउनलोड करने से बचने के लिए स्थानीय रूप से संग्रहीत मान से की जा सकती है। यह विशेष रूप से मीडिया सामग्री के लिए उपयोगी है: अवतार, कवर इमेज, पूर्वावलोकन — ऐसी फ़ाइलें जो शायद ही कभी अपडेट होती हैं लेकिन अक्सर अनुरोध की जाती हैं।

प्रत्यक्ष डाउनलोड URL और उनकी सुरक्षा

टोकन के साथ एक डाउनलोड URL गैर-प्रमाणित उपयोगकर्ताओं को फ़ाइल पहुंच प्रदान करने का प्राथमिक तरीका है (जैसे समाचार फ़ीड में एक इमेज प्रदर्शित करना)। टोकन एक बार उत्पन्न होता है और रिवोक होने तक नहीं बदलता है, इसलिए URL को डेटाबेस में संग्रहीत किया जा सकता है (जैसे Firestore में avatarUrl फ़ील्ड के बगल में)। जब अवतार बदला जाता है, तो पुरानी फ़ाइल हटा दी जाती है, और एक नया URL उत्पन्न और सहेजा जाता है।

याद रखना महत्वपूर्ण है: डाउनलोड URL का होना Security Rules को ओवरराइड नहीं करता. यदि कोई नियम फ़ाइल पढ़ने से इनकार करता है, तो downloadUrl विधि अनुमति अस्वीकृत त्रुटि लौटाएगी। इसका मतलब है कि फ़ाइल का सही पथ जानने के बावजूद, एक गैर-प्रमाणित क्लाइंट लिंक प्राप्त नहीं कर सकता है। एक बार प्राप्त होने के बाद, URL Security Rules को दरकिनार करते हुए HTTP पहुंच प्रदान करता है — इसलिए टोकन डाउनलोड लिंक की एकमात्र सुरक्षा है।

कैशिंग और ETag के साथ काम करना

HTTP ETag एक फ़ाइल संस्करण पहचानकर्ता है जो सामग्री संशोधित होने पर बदलता है। Firebase Storage स्वचालित रूप से GET प्रतिक्रिया में ETag लौटाता है। क्लाइंट एप्लिकेशन ETag को स्थानीय कैश में संग्रहीत कर सकता है और बाद के अनुरोधों पर If-None-Match: {etag} शीर्षक भेज सकता है। यदि फ़ाइल नहीं बदली है, तो सर्वर डेटा ट्रांसमिट किए बिना 304 Not Modified स्थिति लौटाता है।

मोबाइल एप्लिकेशन में इंटेलिजेंट कैशिंग लागू करने के लिए, स्थानीय फ़ाइल सिस्टम और डेटाबेस (जैसे पथ-ETag जोड़े संग्रहीत करने के लिए Room) के संयोजन का उपयोग करें। फ़ाइल लोड करते समय, डेटाबेस से ETag जांचें: यदि यह सर्वर से मेल खाता है, तो स्थानीय कॉपी का उपयोग करें। यह दृष्टिकोण स्थिर मीडिया फ़ाइलों के लिए ट्रैफ़िक को 60–80% तक कम करता है और गैलरी वाली स्क्रीन लोडिंग को गति देता है।

Firebase Storage के लिए सुरक्षा नियम

Security Rules Firebase Storage में फ़ाइलों तक पहुंच नियंत्रण के लिए एक घोषणात्मक भाषा है, जो Firebase सर्वर साइड पर निष्पादित होती है। प्रत्येक नियम bucket पथ से जुड़ा होता है और उन शर्तों को परिभाषित करता है जिनके तहत रीड या राइट संचालन की अनुमति है। प्रत्येक अनुरोध से पहले नियमों की जाँच की जाती है और क्लाइंट कोड द्वारा उन्हें दरकिनार नहीं किया जा सकता है। यह अनधिकृत पहुंच के खिलाफ डेटा की रक्षा की एकमात्र पंक्ति है।

मूल नियम है केवल प्रमाणित उपयोगकर्ताओं के लिए पहुंच: 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 MB तक सीमित है, और प्रकार केवल इमेज तक सीमित है। नियमों का यह संयोजन सामाजिक और UGC एप्लिकेशन में Firebase Storage के 80% उपयोग के मामलों को कवर करता है।

सुरक्षा सलाह: पूरे bucket के लिए allow read, write: if true नियम का कभी उपयोग न करें। यह आपके projectId को जानने वाले किसी भी व्यक्ति के लिए राइट एक्सेस खोलता है। 2025 में, असुरक्षित Firebase buckets पर हमले बढ़ गए हैं, जहां हमलावर अवैध सामग्री संग्रहीत करने के लिए खुले एक्सेस का उपयोग करते हैं। हमेशा न्यूनतम आवश्यक अनुमतियों से शुरू करें और स्पष्ट रूप से आवश्यक होने पर ही उनका विस्तार करें।

Cloud Functions के माध्यम से सामग्री सत्यापन

Cloud Functions ट्रिगर functions.storage.object().onFinalize() अपलोड के बाद सामग्री सत्यापन करने की अनुमति देता है। यदि फ़ाइल सत्यापन पास नहीं करती है (जैसे वायरस होना या प्लेटफ़ॉर्म नियमों का उल्लंघन करना), तो फ़ंक्शन इसे हटा सकता है और उपयोगकर्ता को सूचित कर सकता है। यह वास्तविक सामग्री की जांच करने का एकमात्र तरीका है, क्योंकि Security Rules केवल मेटाडेटा (आकार और MIME प्रकार) देखते हैं, बाइनरी डेटा नहीं।

सत्यापन उदाहरण: एक Node.js फ़ंक्शन अपलोड की गई फ़ाइल को एक अस्थायी निर्देशिका में डाउनलोड करता है, इसे एक एंटीवायरस डिटेक्टर (जैसे ClamAV) के माध्यम से चलाता है, और यदि खतरा पाया जाता है — फ़ाइल हटाता है और Firebase Crashlytics में घटना लॉग करता है। फ़ंक्शन निष्पादन समय 540 सेकंड तक सीमित है, जो 50 MB तक की फ़ाइलों की जांच के लिए पर्याप्त है।

Kotlin में Firebase Storage के लिए कोड उदाहरण

आइए Kotlin में Android एप्लिकेशन में Firebase Storage को एकीकृत करने के व्यावहारिक उदाहरण देखें। कोड मानक Firebase SDK क्लास का उपयोग करता है और डिवाइस गैलरी से एक इमेज अपलोड करना, प्रगति ट्रैकिंग के साथ फ़ाइल डाउनलोड करना और डाउनलोड 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 वेरिएबल प्रोजेक्ट bucket का रूट रेफरेंस है। child विधि एक पथ स्ट्रिंग स्वीकार करती है और एक विशिष्ट फ़ाइल को इंगित करने वाली StorageReference लौटाती है। यदि निर्दिष्ट पथ पर कोई फ़ाइल पहले से मौजूद है, तो इसे अधिलेखित कर दिया जाएगा। contentType और customMetadata SettableMetadata ऑब्जेक्ट के माध्यम से पास किए जाते हैं, जो putFile अनुरोध से जुड़ा होता है।

प्रगति के साथ फ़ाइल डाउनलोड करना

दूसरा उदाहरण ImageView में प्रदर्शन के लिए बाइट ऐरे प्राप्त करके फ़ाइल डाउनलोड प्रदर्शित करता है। getBytes(maxSize) विधि पूरी फ़ाइल को मेमोरी में लोड करती है। 10 MB से बड़ी फ़ाइलों के लिए, getFile(localUri) का उपयोग करें — यह सामग्री को RAM में संग्रहीत किए बिना सीधे स्थानीय फ़ाइल में सहेजता है, जिससे 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}")
    }

डाउनलोड URL प्राप्त करने के लिए (जैसे Firestore में लिंक सहेजना), downloadUrl विधि का उपयोग करें:

islandRef.downloadUrl.addOnSuccessListener { uri ->
    Log.d("Storage", "डाउनलोड URL: $uri")
    // uri.toString() को Firestore में सहेजें
}

सलाह: डाउनलोड URL एक बार उत्पन्न होता है और रिवोक होने तक स्थिर रहता है। इसे हर बार फ़ाइल प्रदर्शित करते समय अनुरोध करने के बजाय पहले अपलोड पर डेटाबेस में सहेजें। यह Firebase Storage को अनुरोधों की संख्या कम करता है और UI प्रदर्शन में सुधार करता है।

Firebase Storage के विशिष्ट उपयोग के मामले

Firebase Storage का उपयोग मोबाइल एप्लिकेशन में किसी भी उपयोगकर्ता और सिस्टम फ़ाइलों को संग्रहीत करने के लिए किया जाता है। सबसे सामान्य परिदृश्यों में अवतार और प्रोफ़ाइल फ़ोटो, सामग्री फ़ीड इमेज, वीडियो और ऑडियो फ़ाइलें, उपयोगकर्ताओं के बीच साझा करने के लिए दस्तावेज़ (PDF, DOCX), और छोटे पैमाने पर डेटा बैकअप शामिल हैं। इन सभी मामलों में, Storage मेटाडेटा और लिंक संग्रहीत करने के लिए Firestore के साथ मिलकर एक विशेष फ़ाइल स्टोरेज के रूप में कार्य करता है।

सामाजिक एप्लिकेशन सबसे सामान्य उपयोग का मामला है। प्रत्येक उपयोगकर्ता एक अवतार, पोस्ट फ़ोटो और मीडिया फ़ाइलें अपलोड करता है। पथ संरचना /users/{uid}/posts/{postId}/image.jpg डेटा को अलग करती है और Security Rules को सरल बनाती है। जब कोई उपयोगकर्ता हटाया जाता है, तो Cloud Function सभी उपयोगकर्ता निर्देशिकाओं को पार कर सकती है और स्टोरेज साफ कर सकती है। Firebase ब्लॉग (2025) के अनुसार, यह पैटर्न 70% प्रोडक्शन Firebase प्रोजेक्ट्स में उपयोग किया जाता है।

ई-कॉमर्स एप्लिकेशन उत्पाद फ़ोटो, कैटलॉग और निर्देशों के साथ PDF फ़ाइलों को संग्रहीत करने के लिए Firebase Storage का उपयोग करते हैं। इस मामले में, फ़ाइल पहुंच आमतौर पर सार्वजनिक होती है (बिना प्रमाणीकरण के पढ़ना), जबकि राइट एक्सेस अनुमति जांच के साथ Cloud Functions के माध्यम से प्रशासकों तक सीमित है। उत्पाद डाउनलोड URL अन्य उत्पाद डेटा के साथ Firestore में संग्रहीत किए जाते हैं, जो Storage को अतिरिक्त अनुरोध किए बिना इमेज प्रदर्शित करने की अनुमति देता है।

मैसेंजर और चैट Firebase Storage में बातचीत में भेजी गई इमेज और वॉइस संदेश संग्रहीत करते हैं। पथ /chats/{chatId}/messages/{messageId}.jpg के रूप में संरचित है। रीड एक्सेस केवल चैट प्रतिभागियों तक सीमित है, जो Firestore डेटा का उपयोग करके Security Rules के माध्यम से सत्यापित किया जाता है। यह उन कुछ परिदृश्यों में से एक है जहां एक नियम किसी अन्य Firebase सेवा से डेटा पढ़ता है: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid}).