Firebase Realtime Database: یہ کیا ہے، JSON ساخت اور ہم آہنگی

Firebase Realtime Database کیا ہے

Firebase Realtime Database پہلے کلاؤڈ ریئل ٹائم ڈیٹا بیسز میں سے ایک ہے، جسے Google نے Firebase کے ساتھ 2012 میں شروع کیا تھا۔ یہ ایک NoSQL ڈیٹا بیس ہے جہاں ڈیٹا ایک JSON درخت کی شکل میں محفوظ ہوتا ہے جو ایک URL کے ذریعے قابل رسائی ہے۔ کلائنٹ SDK (Android, iOS, Web) WebSocket کے ذریعے مخصوص درخت کے نوڈس کو سبسکرائب کرتے ہیں اور ہر ڈیٹا تبدیلی پر اپ ڈیٹس وصول کرتے ہیں — سرور پولنگ یا کسٹم Push میکانزم کے نفاذ کے بغیر۔

تاریخ اور ترقی

اصل Firebase 2011 میں James Tamplin اور Andrew Lee نے قائم کیا تھا، اور پہلی پروڈکٹ خود Realtime Database تھی۔ 2014 میں Google کے حصول کے بعد (TechCrunch کے مطابق — 50 سے 100 ملین ڈالر کے درمیان رقم میں)، ڈیٹا بیس کو Google Cloud میں ضم کر دیا گیا اور نمایاں طور پر زیادہ تھروپٹ حاصل کیا۔ 2017 میں، Google نے Firestore کو ایک ارتقائی متبادل کے طور پر اعلان کیا، لیکن Realtime Database اب بھی فعال طور پر سپورٹ اور اپ ڈیٹ ہوتی ہے۔ Google (2026) کے مطابق، Realtime Database اب بھی 1.5 ملین سے زیادہ فعال منصوبوں میں استعمال ہوتی ہے۔

مفت حدود اور قیمت کا تعین

Spark منصوبہ (مفت) شامل ہے: 1 GB اسٹوریج، ماہانہ 10 GB ڈاؤن لوڈ کردہ ڈیٹا، 100 بیک وقت کنکشنز اور ایک علاقے میں ڈیٹا بیس سپورٹ۔ Blaze منصوبے (pay-as-you-go) پر، اضافی اسٹوریج ($1/GB)، ٹریفک ($0.12/GB) اور بیک وقت کنکشنز (حد سے اوپر ہر 100 ہزار پر $5) کے لیے چارج کیا جاتا ہے۔ ٹیسٹنگ کے لیے، ایک ایمولیشن موڈ بھی دستیاب ہے — firebase emulators:start — جو کلاؤڈ سے کنکشن کے بغیر مقامی طور پر Realtime Database چلاتا ہے۔

ڈیٹا کی ساخت: JSON درخت اور نارملائزیشن

Realtime Database میں ٹیبلز، کلیکشنز یا دستاویزات نہیں ہیں — سب کچھ ایک JSON درخت ہے جو https://project-name-default-rtdb.firebaseio.com/ جیسے URL کے ذریعے قابل رسائی ہے۔ درخت کی ہر کلید یا تو ایک آخری قدر (سٹرنگ، نمبر، بولین، null) ہے یا چائلڈ کیز والا ایک nested نوڈ ہے۔ ڈیٹا بیس انجن JOIN، ذیلی سوالات یا جمع کو سپورٹ نہیں کرتا — ایک سوال ہمیشہ ایک نوڈ کا مواد اس کے تمام چائلڈ عناصر کے ساتھ لوٹاتا ہے۔

ڈیٹا نارملائزیشن

Realtime Database میں JOIN کی کمی کی وجہ سے، ڈیٹا نارملائزیشن لازمی ہے۔ nested درخت (صارف → اس کی پوسٹس کی فہرست) کے بجائے، ڈیٹا کو کیز کے ذریعے حوالوں کے ساتھ فلیٹ فہرستوں میں تقسیم کیا جاتا ہے۔ یہ معیاری طریقہ ہے: ڈیٹا کو ڈی نارملائز کیا جاتا ہے تاکہ ایک نوڈ کو پڑھنے سے پورا سیاق و سباق نہ کھنچے۔ مثال کے طور پر، چیٹ پیغامات کی فہرست صارف پروفائلز سے الگ محفوظ کی جاتی ہے، اور ہر پوسٹ میں صرف مصنف کا ID ہوتا ہے، ان کا پورا پروفائل نہیں۔

Realtime Database میں سوالات

سوالات Realtime Database میں فلٹرز (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) کا استعمال کرتے ہوئے انجام دیے جاتے ہیں۔ Firestore کے برعکس، انڈیکس Rules سیکشن (.indexOn) کے ذریعے دستی طور پر بنائے جاتے ہیں۔ اگر انڈیکس اعلان نہیں کیا گیا ہے، تو ترتیب کے ساتھ سوال PERMISSION_DENIED خرابی لوٹاتا ہے۔ سوالات صرف ایک فیلڈ پر کام کرتے ہیں — مرکب سوالات (قیمت کے مطابق فلٹر + تاریخ کے مطابق ترتیب) سپورٹ نہیں ہیں۔ پیچیدہ فلٹرنگ کے لیے، ڈیٹا کو اکثر مختلف ترتیب کیز کے ساتھ مختلف نوڈس میں نقل کیا جاتا ہے۔

Realtime Database بمقابلہ Firestore: کیا انتخاب کریں

Realtime Database اور Firestore کے درمیان انتخاب منصوبہ شروع کرتے وقت عام آرکیٹیکچرل فیصلوں میں سے ایک ہے۔ Google نئی ایپلی کیشنز کی اکثریت کے لیے Firestore تجویز کرتا ہے، لیکن Realtime Database ان منظرناموں کے لیے بہترین انتخاب رہتی ہے جہاں کم سے کم ڈیٹا ٹرانسفر لیٹنسی اہم ہو۔

Realtime Database کے لیے تین اہم منظرنامے

پہلا منظرنامہ — حالت کی ہم آہنگی کے ساتھ ملٹی پلیئر گیمز (شطرنج، تاش کے کھیل، ریئل ٹائم ایکشن)۔ Realtime Database کی لیٹنسی 10-30 ms ہے جبکہ اسی علاقے میں Firestore کی 50-100 ms ہے۔ دوسرا منظرنامہ — اعلی پیغام فریکوئنسی والے چیٹ اور میسنجر۔ Realtime Database کا بل ڈیٹا والیوم کے مطابق کیا جاتا ہے، نہ کہ تحریروں کی تعداد کے مطابق، جو اسے 1 پیغام فی سیکنڈ سے زیادہ فریکوئنسی پر Firestore کے مقابلے میں نمایاں طور پر سستا بناتا ہے۔ تیسرا منظرنامہ — صارفین کی آن لائن/آف لائن موجودگی، جہاں Realtime Database کے onDisconnect ہینڈلر کنکشن ختم ہونے پر ایٹمی طور پر حالت مقرر کرنے کی اجازت دیتے ہیں۔

Google (2026) کے مطابق، تقریباً 15% نئے Firebase منصوبے شعوری طور پر Realtime Database کا انتخاب کرتے ہیں — جب ٹیم لیٹنسی، ڈیٹا کی ساخت اور بجٹ کے لیے اپنی ضروریات کو واضح طور پر سمجھتی ہے۔ باقی 85% معاملات میں، Firestore بہتر اسکیل ایبلٹی، زیادہ طاقتور سوالات اور خودکار نقل کی وجہ سے زیادہ محفوظ انتخاب ہے۔

Android میں Realtime Database کا انضمام

Realtime Database کو Android ایپلی کیشن سے جوڑنا build.gradle میں firebase-database-ktx انحصار شامل کرکے کیا جاتا ہے۔ FirebaseDatabase آبجیکٹ getInstance(url) کے ذریعے دستیاب ہے — آپ ایک Firebase منصوبے کے تحت متعدد ڈیٹا بیسز سے منسلک ہو سکتے ہیں۔ ابتدا کے بعد، SDK خود بخود سرور کے ساتھ WebSocket کنکشن قائم کرتا ہے اور ڈیٹا ہم آہنگی شروع کرتا ہے۔

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-database-ktx")
}

// Initialization with custom URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

ڈیٹا تحریر اور پڑھنا

Realtime Database تمام آپریشنز کے لیے DatabaseReference آبجیکٹ استعمال کرتی ہے۔ setValue() مخصوص نوڈ میں ڈیٹا لکھتا ہے، اس کے تمام مواد کو مکمل طور پر تبدیل کرتا ہے۔ push() فہرست میں آئٹم شامل کرنے کے لیے خود بخود ایک منفرد کلید (ٹائم سٹیمپ پر مبنی) پیدا کرتا ہے — یہ چیٹ پیغامات، پوسٹس اور ریکارڈز بنانے کا معیاری طریقہ ہے۔ updateChildren() ایک ہی آپریشن میں متعدد نوڈس کو ایٹمی طور پر تبدیل کرتا ہے۔ addValueEventListener نوڈ تبدیلیوں کو سبسکرائب کرتا ہے اور ہر ڈیٹا اپ ڈیٹ پر کال بیک وصول کرتا ہے۔

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

ریئل ٹائم ہم آہنگی اور آف لائن موڈ

ہم آہنگی کا طریقہ کار WebSocket پروٹوکول (پہلے — لمبی پولنگ) پر مبنی ہے۔ کلائنٹ ایک مخصوص نوڈ کو سبسکرائب کرنے کی درخواست بھیجتا ہے، اور سرور کنکشن کو کھلا رکھتا ہے۔ سبسکرائب کردہ نوڈ میں کسی بھی ڈیٹا تبدیلی پر، سرور اس نوڈ کا مکمل JSON کلائنٹ کو بھیجتا ہے۔ کلائنٹ پر SDK خود بخود مقامی حالت کو اپ ڈیٹ کرتا ہے اور متعلقہ کال بیکس (onDataChange) کو متحرک کرتا ہے۔

OnDisconnect — کنکشن منقطع کرنے والے محرکات

OnDisconnect Realtime Database کی ایک منفرد خصوصیت ہے جو Firestore میں موجود نہیں ہے۔ ڈویلپر ایک تحریری آپریشن رجسٹر کر سکتا ہے جو کلائنٹ کا کنکشن ختم ہونے پر سرور پر خود بخود انجام پائے گا۔ یہ موجودگی کی حالتوں کے لیے استعمال ہوتا ہے: «user123/status»: onDisconnect.setValue(«offline») کے ساتھ «online»۔ اگر صارف ایپ بند کر دیتا ہے یا انٹرنیٹ کھو دیتا ہے، تو سرور خود بخود زیادہ سے زیادہ 3 منٹ میں حالت کو «offline» پر سیٹ کر دے گا (Firebase کنسول میں ترتیب پذیر)۔

آف لائن کیش

Persistence Realtime Database میں ایک لائن سے فعال ہوتا ہے: FirebaseDatabase.getInstance().setPersistenceEnabled(true)۔ SDK ڈسک پر تمام سبسکرائب کردہ نوڈس کی آخری حالت کو کیش کرتا ہے (پہلے سے طے شدہ طور پر 10 MiB تک، 100 MiB تک ترتیب پذیر)۔ کنکشن ختم ہونے پر، کلائنٹ کیش کردہ ڈیٹا کے ساتھ کام جاری رکھتا ہے، اور تمام تحریری آپریشن قطار میں لگ جاتے ہیں۔ کنکشن بحال ہونے پر، SDK تمام جمع شدہ تبدیلیاں صحیح ترتیب (FIFO) میں سرور کو بھیجتا ہے۔

Google (2026) کے مطابق، persistence کیش فعال ایپلی کیشنز میں کنکشن ختم ہونے پر صارف کا ڈیٹا کھونے کا امکان 40% کم ہوتا ہے۔ تاہم، اگر کسی کلائنٹ نے 1000 سے زیادہ زیر التواء آپریشن جمع کر لیے ہیں، تو سرور ان سب کو مسترد کر سکتا ہے اور مکمل ہم آہنگی کی درخواست کر سکتا ہے — یہ پرانے کلائنٹس کے خلاف ایک حفاظتی طریقہ کار ہے۔

سیکیورٹی قواعد اور توثیق

سیکیورٹی قواعد Realtime Database میں ایک JSON کنفیگریشن ہے جو بتاتی ہے کہ ہر نوڈ میں ڈیٹا کون اور کن شرائط میں پڑھ اور لکھ سکتا ہے۔ قواعد Google کے سرور پر چلتے ہیں اور ہر آپریشن سے پہلے لاگو ہوتے ہیں۔ پہلے سے طے شدہ طور پر (پروڈکشن میں)، قواعد کو «بند» موڈ میں سیٹ کرنے کی سفارش کی جاتی ہے — صرف تصدیق شدہ صارفین کو رسائی حاصل ہے۔

قواعد کی ساخت

Realtime Database کے قواعد .read، .write، .validate، .indexOn سیکشنز کے ساتھ JSON فارمیٹ میں لکھے جاتے ہیں۔ Firestore (جو match نحو استعمال کرتا ہے) کے برعکس، Realtime Database ڈیٹا کی ساخت کو ظاہر کرنے والے nested آبجیکٹ استعمال کرتا ہے۔ شرائط auth (تصدیق)، data (موجودہ ڈیٹا)، newData (تحریر پر نیا ڈیٹا) اور now (سرور کا وقت) چیک کرتی ہیں۔ توثیق کے قواعد (.validate) اقسام، قدروں کی حدود اور ڈیٹا کی ساخت کو چیک کرنے کی اجازت دیتے ہیں۔

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

جھرن کا رویہ اور قواعد کی جانچ

Realtime Database کے قواعد جھرن کی طرح وراثت میں ملتے ہیں — اگر اوپری سطح پر .read = false ہے، تو تمام ذیلی نوڈ اپنے قواعد سے قطع نظر پڑھنے کے لیے دستیاب نہیں ہیں۔ Firebase کنسول میں ایک قواعد سمیلیٹر فراہم کرتا ہے جہاں آپ تعیناتی سے پہلے مختلف auth ٹوکنز کے ساتھ آپریشنز کی جانچ کر سکتے ہیں۔ ہمیشہ سمیلیٹر میں قواعد کی جانچ کرنے کی سفارش کی جاتی ہے — قاعدے میں خرابی تمام صارفین کے نجی ڈیٹا تک رسائی کھول سکتی ہے۔ Google (2026) کے مطابق، Firebase منصوبوں میں 40% ڈیٹا لیک غلط ترتیب شدہ سیکیورٹی قواعد کی وجہ سے ہوتے ہیں۔