ডেটা সংরক্ষণ করা হচ্ছে

ডাটা সেভ করার উপায়
PUT	একটি সংজ্ঞায়িত পথে ডেটা লিখুন বা প্রতিস্থাপন করুন, যেমন fireblog/users/user1/<data>
প্যাচ	সমস্ত ডেটা প্রতিস্থাপন না করে একটি সংজ্ঞায়িত পথের জন্য কিছু কী আপডেট করুন।
পোস্ট	আমাদের ফায়ারবেস ডাটাবেসের ডেটার তালিকায় যোগ করুন । প্রতিবার যখন আমরা একটি POST অনুরোধ পাঠাই, Firebase ক্লায়েন্ট একটি অনন্য কী তৈরি করে, যেমন fireblog/users/<unique-id>/<data>
মুছুন	নির্দিষ্ট ফায়ারবেস ডাটাবেস রেফারেন্স থেকে ডেটা সরান।

মনে রাখবেন যে সমস্ত উদাহরণ শুধুমাত্র-পঠনযোগ্য Firebase Realtime Database , docs-example.firebaseio.com ব্যবহার করে। আপনার অ্যাক্সেস আছে এমন Firebase কনসোল থেকে এই Realtime Database ইউআরএলটি প্রতিস্থাপন করুন।

PUT দিয়ে ডেটা লেখা

REST API-এর মাধ্যমে মৌলিক লেখার অপারেশন হল PUT । ডেটা সংরক্ষণের প্রদর্শন করতে, আমরা পোস্ট এবং ব্যবহারকারীদের নিয়ে একটি ব্লগিং অ্যাপ্লিকেশন তৈরি করব৷ আমাদের অ্যাপ্লিকেশনের সমস্ত ডেটা Firebase ডাটাবেস URL `https://docs-examples.firebaseio.com/fireblog`-এ `fireblog` এর পথের অধীনে সংরক্ষণ করা হবে।

যদি আমরা একটি ব্রাউজার থেকে REST কল করি যা উপরের কিছু পদ্ধতি সমর্থন করে না, Firebase X-HTTP-Method-Override হেডার সমর্থন করে।

আমাদের ফায়ারবেস ডাটাবেসে কিছু ব্যবহারকারীর ডেটা সংরক্ষণ করে শুরু করা যাক। আমরা প্রতিটি ব্যবহারকারীকে একটি অনন্য ব্যবহারকারীর নাম দ্বারা সংরক্ষণ করব, এবং আমরা তাদের পুরো নাম এবং জন্ম তারিখও সংরক্ষণ করব৷ যেহেতু প্রতিটি ব্যবহারকারীর একটি অনন্য ব্যবহারকারীর নাম থাকবে, তাই এখানে POST এর পরিবর্তে PUT ব্যবহার করা বোধগম্য কারণ আমাদের কাছে ইতিমধ্যে কী আছে এবং একটি তৈরি করার প্রয়োজন নেই।

PUT ব্যবহার করে, আমরা আমাদের ফায়ারবেস ডাটাবেসে একটি স্ট্রিং, নম্বর, বুলিয়ান, অ্যারে বা যেকোনো JSON অবজেক্ট লিখতে পারি। এই ক্ষেত্রে আমরা এটি একটি বস্তু পাস করব:

curl -X PUT -d '{
  "alanisawesome": {
    "name": "Alan Turing",
    "birthday": "June 23, 1912"
  }
}' 'https://docs-examples.firebaseio.com/fireblog/users.json'

যখন একটি JSON অবজেক্ট ডাটাবেসে সংরক্ষিত হয়, তখন অবজেক্টের বৈশিষ্ট্যগুলি স্বয়ংক্রিয়ভাবে নেস্টেড ফ্যাশনে চাইল্ড লোকেশনে ম্যাপ করা হয়। যদি আমরা নতুন তৈরি নোডে নেভিগেট করি, তাহলে আমরা "অ্যালান টুরিং" মান দেখতে পাব। আমরা সরাসরি একটি শিশু অবস্থানে ডেটা সংরক্ষণ করতে পারি:

curl -X PUT -d '"Alan Turing"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/name.json'

curl -X PUT -d '"June 23, 1912"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/birthday.json'

উপরের দুটি উদাহরণ—একটি বস্তুর মতো একই সময়ে মান লেখা এবং চাইল্ড লোকেশনে আলাদাভাবে লেখা—এর ফলে একই ডেটা আমাদের ফায়ারবেস ডাটাবেসে সংরক্ষিত হবে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing"
    }
  }
}

একটি সফল অনুরোধ একটি 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে, এবং প্রতিক্রিয়াতে ডাটাবেসে আমরা যে ডেটা লিখেছিলাম তা থাকবে৷ প্রথম উদাহরণটি শুধুমাত্র ক্লায়েন্টদের উপর একটি ইভেন্ট ট্রিগার করবে যারা ডেটা দেখছে, যেখানে দ্বিতীয় উদাহরণটি দুটি ট্রিগার করবে। এটি লক্ষ করা গুরুত্বপূর্ণ যে যদি ব্যবহারকারীর পথে ডেটা ইতিমধ্যেই বিদ্যমান থাকে, তবে প্রথম পদ্ধতিটি এটিকে ওভাররাইট করবে, তবে দ্বিতীয় পদ্ধতিটি অন্য শিশুদের অপরিবর্তিত রেখে প্রতিটি পৃথক চাইল্ড নোডের মান পরিবর্তন করবে। PUT আমাদের JavaScript SDK-এ set() এর সমতুল্য।

PUT ব্যবহার করলে যেকোন চাইল্ড নোড সহ নির্দিষ্ট স্থানে ডেটা ওভাররাইট হবে।

প্যাচ দিয়ে ডেটা আপডেট করা হচ্ছে

একটি PATCH অনুরোধ ব্যবহার করে, আমরা বিদ্যমান ডেটা ওভাররাইট না করে একটি অবস্থানে নির্দিষ্ট শিশুদের আপডেট করতে পারি। চলুন একটি PATCH অনুরোধের সাথে তার ব্যবহারকারীর ডেটাতে টুরিংয়ের ডাকনাম যোগ করা যাক:

curl -X PATCH -d '{
  "nickname": "Alan The Machine"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

উপরের অনুরোধটি name বা birthday বাচ্চাদের মুছে না দিয়ে আমাদের alanisawesome বস্তুতে nickname লিখবে। মনে রাখবেন যে আমরা যদি এর পরিবর্তে এখানে একটি PUT অনুরোধ জারি করতাম, তাহলে name এবং birthday মুছে ফেলা হবে কারণ সেগুলি অনুরোধে অন্তর্ভুক্ত ছিল না। আমাদের ফায়ারবেস ডাটাবেসের ডেটা এখন এইরকম দেখাচ্ছে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    }
  }
}

একটি সফল অনুরোধ একটি 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে, এবং প্রতিক্রিয়াতে ডাটাবেসে লেখা আপডেট করা ডেটা থাকবে।

Firebase মাল্টি-পাথ আপডেটগুলিকেও সমর্থন করে। এর মানে হল PATCH এখন একই সময়ে আপনার Firebase ডাটাবেসের একাধিক অবস্থানে মান আপডেট করতে পারে, একটি শক্তিশালী বৈশিষ্ট্য যা আপনাকে আপনার ডেটাকে অস্বাভাবিক করতে সাহায্য করে। মাল্টি-পাথ আপডেট ব্যবহার করে, আমরা একই সময়ে অ্যালান এবং গ্রেস উভয়ের ডাকনাম যোগ করতে পারি:

curl -X PATCH -d '{
  "alanisawesome/nickname": "Alan The Machine",
  "gracehopper/nickname": "Amazing Grace"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

এই আপডেটের পরে, অ্যালান এবং গ্রেস উভয়েরই তাদের ডাকনাম যোগ করা হয়েছে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "date_of_birth": "December 9, 1906",
      "full_name": "Grace Hopper",
      "nickname": "Amazing Grace"
    }
  }
}

উল্লেখ্য যে অন্তর্ভুক্ত পাথগুলির সাথে অবজেক্ট লিখে অবজেক্ট আপডেট করার চেষ্টা করলে ভিন্ন আচরণ হবে। এর পরিবর্তে আমরা যদি গ্রেস এবং অ্যালানকে এভাবে আপডেট করার চেষ্টা করি তাহলে কী হবে তা একবার দেখে নেওয়া যাক:

curl -X PATCH -d '{
  "alanisawesome": {"nickname": "Alan The Machine"},
  "gracehopper": {"nickname": "Amazing Grace"}
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

এর ফলে বিভিন্ন আচরণ দেখা যায়, যথা সমগ্র /fireblog/users নোড ওভাররাইট করা:

{
  "users": {
    "alanisawesome": {
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "nickname": "Amazing Grace"
    }
  }
}

শর্তসাপেক্ষ অনুরোধের সাথে ডেটা আপডেট করা হচ্ছে

আপনি শর্তসাপেক্ষ অনুরোধগুলি ব্যবহার করতে পারেন, লেনদেনের সমতুল্য REST, তার বিদ্যমান অবস্থা অনুযায়ী ডেটা আপডেট করতে। উদাহরণস্বরূপ, আপনি যদি একটি আপভোট কাউন্টার বাড়াতে চান, এবং নিশ্চিত করতে চান যে গণনাটি সঠিকভাবে একাধিক, একযোগে আপভোটের প্রতিফলন করে, তাহলে কাউন্টারে নতুন মান লেখার জন্য একটি শর্তসাপেক্ষ অনুরোধ ব্যবহার করুন। দুটি লেখার পরিবর্তে কাউন্টারটিকে একই নম্বরে পরিবর্তন করুন, একটি লেখার অনুরোধ ব্যর্থ হয় এবং আপনি নতুন মান দিয়ে অনুরোধটি পুনরায় চেষ্টা করতে পারেন।

1. একটি অবস্থানে একটি শর্তসাপেক্ষ অনুরোধ সম্পাদন করতে, সেই অবস্থানে বর্তমান ডেটার জন্য অনন্য শনাক্তকারী বা ETag পান৷ যদি সেই অবস্থানে ডেটা পরিবর্তিত হয়, তাহলে ETagও পরিবর্তিত হয়। আপনি PATCH ছাড়া অন্য কোনো পদ্ধতিতে একটি ETag এর জন্য অনুরোধ করতে পারেন। নিম্নলিখিত উদাহরণ একটি GET অনুরোধ ব্যবহার করে।

   curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
   

   বিশেষভাবে হেডারে ETag কল করলে HTTP প্রতিক্রিয়ায় নির্দিষ্ট অবস্থানের ETag ফিরে আসে।

   HTTP/1.1 200 OK
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   ETag: [ETAG_VALUE]
   Cache-Control: no-cache
   
   10 // Current value of the data at the specified location
   

2. প্রত্যাবর্তিত ETag আপনার পরবর্তী PUT এ অন্তর্ভুক্ত করুন বা ETag মানের সাথে বিশেষভাবে মেলে এমন ডেটা আপডেট করার অনুরোধ DELETE । আমাদের উদাহরণ অনুসরণ করে, কাউন্টারটিকে 11-এ আপডেট করতে বা 10-এর প্রারম্ভিক মানের থেকে 1 বড়, এবং অনুরোধটি ব্যর্থ করতে যদি মানটি আর মেলে না, নিম্নলিখিত কোডটি ব্যবহার করুন:

   curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
   

   যদি নির্দিষ্ট স্থানে ডেটার মান এখনও 10 হয়, তাহলে PUT অনুরোধের ETag মেলে, এবং অনুরোধটি সফল হয়, ডাটাবেসে 11 লিখে।

   HTTP/1.1 200 OK
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   Cache-Control: no-cache
   
   11 // New value of the data at the specified location, written by the conditional request
   

   যদি অবস্থানটি আর ETag-এর সাথে মেলে না, যা ঘটতে পারে যদি অন্য ব্যবহারকারী ডাটাবেসে একটি নতুন মান লেখেন, অনুরোধটি অবস্থানে না লিখে ব্যর্থ হয়। ফেরত প্রতিক্রিয়া নতুন মান এবং ETag অন্তর্ভুক্ত.

   HTTP/1.1 412 Precondition Failed
   Content-Length: 6
   Content-Type: application/json; charset=utf-8
   Access-Control-Allow-Origin: *
   ETag: [ETAG_VALUE]
   Cache-Control: no-cache
   
   12 // New value of the data at the specified location
   

3. আপনি অনুরোধটি পুনরায় চেষ্টা করার সিদ্ধান্ত নিলে নতুন তথ্য ব্যবহার করুন। Realtime Database স্বয়ংক্রিয়ভাবে ব্যর্থ হয়েছে এমন শর্তসাপেক্ষ অনুরোধগুলি পুনরায় চেষ্টা করে না। যাইহোক, আপনি ব্যর্থ প্রতিক্রিয়া দ্বারা ফিরে আসা তথ্যের সাথে একটি নতুন শর্তাধীন অনুরোধ তৈরি করতে নতুন মান এবং ETag ব্যবহার করতে পারেন।

REST-ভিত্তিক শর্তসাপেক্ষ অনুরোধগুলি HTTP ইফ-ম্যাচ স্ট্যান্ডার্ড বাস্তবায়ন করে। যাইহোক, তারা নিম্নলিখিত উপায়ে মান থেকে পৃথক:

• আপনি প্রতিটি যদি-মিল অনুরোধের জন্য শুধুমাত্র একটি ETag মান সরবরাহ করতে পারেন, একাধিক নয়।
• যদিও স্ট্যান্ডার্ড পরামর্শ দেয় যে সমস্ত অনুরোধের সাথে ETags ফেরত দেওয়া হবে, রিয়েলটাইম ডেটাবেস শুধুমাত্র X-Firebase-ETag শিরোনাম সহ অনুরোধ সহ ETags ফেরত দেয়। এটি স্ট্যান্ডার্ড অনুরোধের জন্য বিলিং খরচ হ্রাস করে।

শর্তসাপেক্ষ অনুরোধগুলি সাধারণ REST অনুরোধের চেয়ে ধীর হতে পারে।

ডেটার তালিকা সংরক্ষণ করা হচ্ছে

ফায়ারবেস ডাটাবেস রেফারেন্সে যোগ করা প্রতিটি শিশুর জন্য একটি অনন্য, টাইমস্ট্যাম্প-ভিত্তিক কী তৈরি করতে আমরা একটি POST অনুরোধ পাঠাতে পারি। আমাদের users পথের জন্য, প্রতিটি ব্যবহারকারীর একটি অনন্য ব্যবহারকারীর নাম থাকায় আমাদের নিজস্ব কীগুলি সংজ্ঞায়িত করা বোধগম্য। কিন্তু যখন ব্যবহারকারীরা অ্যাপটিতে ব্লগ পোস্ট যোগ করেন, তখন আমরা প্রতিটি ব্লগ পোস্টের জন্য একটি কী স্বয়ংক্রিয়ভাবে তৈরি করতে একটি POST অনুরোধ ব্যবহার করব:

curl -X POST -d '{
  "author": "alanisawesome",
  "title": "The Turing Machine"
}' 'https://docs-examples.firebaseio.com/fireblog/posts.json'

আমাদের posts পাথে এখন নিম্নলিখিত তথ্য আছে:

{
  "posts": {
    "-JSOpn9ZC54A4P4RoqVa": {
      "author": "alanisawesome",
      "title": "The Turing Machine"
    }
  }
}

লক্ষ্য করুন যে কী -JSOpn9ZC54A4P4RoqVa আমাদের জন্য স্বয়ংক্রিয়ভাবে তৈরি হয়েছে কারণ আমরা একটি POST অনুরোধ ব্যবহার করেছি৷ একটি সফল অনুরোধ একটি 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে, এবং প্রতিক্রিয়াতে যোগ করা নতুন ডেটার কী থাকবে:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

পুশ কী কীভাবে তৈরি হয় সে সম্পর্কে আরও জানতে আগ্রহী? এই ব্লগ পোস্ট দেখুন.

ডেটা সরানো হচ্ছে

ডাটাবেস থেকে ডেটা মুছে ফেলার জন্য, আমরা যে পথ থেকে ডেটা মুছতে চাই সেই পথের URL সহ আমরা একটি DELETE অনুরোধ পাঠাতে পারি। নিম্নলিখিতগুলি আমাদের users পথ থেকে অ্যালানকে মুছে ফেলবে:

curl -X DELETE \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

একটি সফল DELETE অনুরোধ একটি 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে একটি প্রতিক্রিয়া সহ JSON null ।

URI পরামিতি

ডাটাবেসে ডেটা লেখার সময় REST API নিম্নলিখিত URI পরামিতিগুলি গ্রহণ করে:

প্রমাণ

auth রিকোয়েস্ট প্যারামিটার Firebase Realtime Database Security Rules দ্বারা সুরক্ষিত ডেটা অ্যাক্সেস করার অনুমতি দেয় এবং সব ধরনের অনুরোধের দ্বারা সমর্থিত। যুক্তিটি হয় আমাদের Firebase অ্যাপের গোপনীয়তা বা একটি প্রমাণীকরণ টোকেন হতে পারে, যা আমরা ব্যবহারকারীর অনুমোদন বিভাগে কভার করব। নিম্নলিখিত উদাহরণে আমরা একটি auth প্যারামিটার সহ একটি POST অনুরোধ পাঠাই, যেখানে CREDENTIAL হয় আমাদের Firebase অ্যাপ গোপন বা একটি প্রমাণীকরণ টোকেন:

curl -X POST -d '{"Authenticated POST request"}' \
  'https://docs-examples.firebaseio.com/auth-example.json?auth=CREDENTIAL'

টোকেন debug ফ্ল্যাগ সেট করা থাকলে, প্রতিক্রিয়ার X-Firebase-Auth-Debug হেডারে ডিবাগ তথ্য পাওয়া যাবে।

মুদ্রণ

print প্যারামিটার আমাদের ডেটাবেস থেকে আমাদের প্রতিক্রিয়ার বিন্যাস নির্দিষ্ট করতে দেয়। আমাদের অনুরোধে print=pretty যোগ করলে তথ্যটি মানব-পাঠযোগ্য বিন্যাসে ফিরে আসবে। print=pretty GET , PUT , POST , PATCH , এবং DELETE অনুরোধ দ্বারা সমর্থিত।

ডেটা লেখার সময় সার্ভার থেকে আউটপুট দমন করতে, আমরা আমাদের অনুরোধে print=silent যোগ করতে পারি। ফলস্বরূপ প্রতিক্রিয়া খালি হবে এবং অনুরোধটি সফল হলে একটি 204 No Content HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে। print=silent GET , PUT , POST , এবং PATCH অনুরোধ দ্বারা সমর্থিত।

সার্ভার মান লেখা

সার্ভার মান একটি স্থানধারক মান ব্যবহার করে একটি অবস্থানে লেখা যেতে পারে, যা একটি একক ".sv" কী সহ একটি বস্তু। সেই কীটির মান হল সার্ভারের মান যে ধরনের আমরা সেট করতে চাই। উদাহরণস্বরূপ, একটি ব্যবহারকারী তৈরি করার সময় একটি টাইমস্ট্যাম্প সেট করতে আমরা নিম্নলিখিতগুলি করতে পারি:

curl -X PUT -d '{".sv": "timestamp"}' \
  'https://docs-examples.firebaseio.com/alanisawesome/createdAt.json'

"timestamp" হল একমাত্র সমর্থিত সার্ভারের মান, এবং এটি মিলিসেকেন্ডে ইউনিক্স যুগের সময়।

লেখার কর্মক্ষমতা উন্নত করা

আমরা যদি ডাটাবেসে প্রচুর পরিমাণে ডেটা লিখি, তাহলে আমরা আমাদের লেখার কর্মক্ষমতা উন্নত করতে এবং ব্যান্ডউইথের ব্যবহার কমাতে print=silent প্যারামিটার ব্যবহার করতে পারি। সাধারণ লেখার আচরণে, সার্ভার JSON ডেটার সাথে প্রতিক্রিয়া জানায় যা লেখা হয়েছিল। print=silent নির্দিষ্ট করা হলে, ডেটা প্রাপ্তির সাথে সাথে সার্ভার সংযোগটি বন্ধ করে দেয়, ব্যান্ডউইথের ব্যবহার হ্রাস করে।

যে ক্ষেত্রে আমরা ডাটাবেসের কাছে অনেক অনুরোধ করছি, আমরা HTTP হেডারে একটি Keep-Alive অনুরোধ পাঠিয়ে HTTPS সংযোগ পুনরায় ব্যবহার করতে পারি।

ত্রুটি শর্ত

REST API এই পরিস্থিতিতে ত্রুটি কোড ফেরত দেবে:

HTTP স্ট্যাটাস কোড
400 খারাপ অনুরোধ	নিম্নলিখিত ত্রুটি শর্তগুলির মধ্যে একটি: PUT বা POST ডেটা পার্স করতে অক্ষম৷ PUT বা POST ডেটা অনুপস্থিত৷ অনুরোধটি খুব বড় ডেটা PUT বা POST চেষ্টা করে। REST API কলে পথের অংশ হিসাবে অবৈধ সন্তানের নাম রয়েছে। REST API কল পাথ অনেক লম্বা৷ অনুরোধে একটি অচেনা সার্ভার মান রয়েছে৷ আপনার Firebase Realtime Database Security Rules কোয়েরির সূচী সংজ্ঞায়িত করা হয়নি। অনুরোধটি নির্দিষ্ট করা কোয়েরি প্যারামিটারগুলির একটিকে সমর্থন করে না৷ অনুরোধটি একটি অগভীর GET অনুরোধের সাথে ক্যোয়ারী পরামিতি মিশ্রিত করে।
401 অননুমোদিত	নিম্নলিখিত ত্রুটি শর্তগুলির মধ্যে একটি: প্রমাণীকরণ টোকেনের মেয়াদ শেষ হয়ে গেছে। অনুরোধে ব্যবহৃত প্রমাণীকরণ টোকেনটি অবৈধ। একটি অ্যাক্সেস_টোকেন দিয়ে প্রমাণীকরণ ব্যর্থ হয়েছে৷ অনুরোধটি আপনার Firebase Realtime Database Security Rules লঙ্ঘন করে।
404 পাওয়া যায়নি	নির্দিষ্ট ফায়ারবেস ডাটাবেস পাওয়া যায়নি।
500 অভ্যন্তরীণ সার্ভার ত্রুটি৷	সার্ভার একটি ত্রুটি ফিরিয়ে দিয়েছে৷ আরো বিস্তারিত জানার জন্য ত্রুটি বার্তা দেখুন.
503 পরিষেবা অনুপলব্ধ৷	নির্দিষ্ট ফায়ারবেস রিয়েলটাইম ডেটাবেস সাময়িকভাবে অনুপলব্ধ, যার মানে অনুরোধের চেষ্টা করা হয়নি।

ডেটা সুরক্ষিত করা

ফায়ারবেসের একটি নিরাপত্তা ভাষা রয়েছে যা আমাদেরকে সংজ্ঞায়িত করতে দেয় কোন ব্যবহারকারীরা আমাদের ডেটার বিভিন্ন নোডে পড়ার এবং লেখার অ্যাক্সেস পেয়েছে। আপনি Realtime Database Security Rules এটি সম্পর্কে আরও পড়তে পারেন।

এখন যেহেতু আমরা ডেটা সেভিং কভার করেছি, আমরা পরবর্তী বিভাগে REST API-এর মাধ্যমে Firebase ডাটাবেস থেকে কীভাবে আমাদের ডেটা পুনরুদ্ধার করতে পারি তা শিখতে পারি।