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")
    // Firestore-এ uri.toString() সংরক্ষণ করুন
}

টিপ: ডাউনলোড 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}).