Firebase Realtime DB — یہ کیا ہے، آرکیٹیکچر اور JSON کے ساتھ کام

Firebase Realtime Database کیا ہے؟

Firebase Realtime Database ایک کلاؤڈ NoSQL ڈیٹابیس ہے جو تمام منصل کلائنٹس کے درمیان حقیقی وقت میں ڈیٹا کو ذخیرہ اور هم آہنگ کرتا ہے۔ 2012 میں Firebase کے روپ میں لانچ کیا گیا، یہ موبائل ڈیویلپرز کے لیے پہلا کلاؤڈ حقیقی وقت کا ڈیٹابیس بن گیا۔ ڈیٹا JSON فارمیٹ میں پیش کیا جاتا ہے اور ایک درجہ بندی درخت میں منظم ہوتا ہے، جہاں ہر نوڈ کا ایک منفرد راستہ ہوتا ہے۔

Realtime Database کی بنیادی اہمیت مضمونی مطابقت ہے۔ جب کوئی ایپلیکیشن کسی دیوائس پر ڈیٹا بدلتا ہے تو باقی تمام منصل کلائنٹس ایک مستقل کنیکشن کے ذریعے فوری تازہ کرنے والی تبدیلی وصول کرتے ہیں۔ یہ ڈیویلپر کو کلائنٹس کے درمیان ڈیٹا منتقل کے لیے اپنا مطابقت میکشناسم، WebSocket سرور یا REST API لاگو کرنے کی ضرورت کو ختم کرتا ہے۔

یہ ڈیٹابیس تمام اہم پلیٹ فارمز کے لیے SDK فراہم کرتا ہے: Android (Java, Kotlin)، iOS (Swift, Objective-C)، Web (JavaScript) اور Admin SDK کے ذریعے سرور ماحول۔ Google کے مطابق، Realtime Database دنیا بھر میں 1.5 ملین سے زائد فعال Firebase مناصب میں استعمال ہوتا ہے۔ زیادہ جدید Firestore کے ابھرار کے باوجود، Realtime Database سادہ ڈیٹا ساخت والے مناصب کے لیے ایک مقبول منصوبہ بنا ہوا ہے۔

ڈیٹا کی ساخت: JSON درخت

ریلیشنل ڈیٹابیس کے برعکس، Realtime Database ٹیبلز اور قطاروں کا استعمال نہیں کرتا۔ تمام ڈیٹا ایک واحد JSON درخت ہے جو ایک دوسرے میں گھرے گئے JavaScript آبجیکٹس کی طرح نظر آتا ہے۔ مثال کے طور پر، صارفین اور ان کے پیغاموں کو ذخیرہ کرنے کے لیے ایک درجہ بندی بنائی جاتی ہے: users/userId/name اور messages/messageId/text۔ درخت میں ہر راستہ ایک سطر ہے اور اس راستے سے سیدھے ڈیٹا تک رسائی حاصل کی جا سکتی ہے۔

{
  "users": {
    "user1": {
      "name": "ایوان پیٹروف",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "ماریا سوکولوفا",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "ہیلو!",
      "userId": "user1"
    }
  }
}

ایک اہم خاصیت یہ ہے کے گھری ساخت کارکردگی کو متاثر کرتی ہے۔ جب کوئی ایپلیکیشن ایک مقرر راستے پر ڈیٹا پڑھتا ہے تو وہ اس راستے کے تمام چیلڈ نوڈز کو لوڈ کرتا ہے۔ لہذا، ڈیٹا کی ساخت کو ممکن ہو تک چپٹی رکھنے اور 3-4 سطحوں سے زیادہ گھرے ساخت سے بچنے کی سفارش کی جاتی ہے۔ اس مسئلے سے نمٹنے کے لیے، ڈیٹا ڈی نارملائزیشن (درخت کے مختلف نوڈز میں معلومات کی نقل) استعمال کی جاتی ہے۔

Realtime Database بنام Firestore: کب چنیں

Realtime Database اور Firestore کا اکثر Google کے دو کلاؤڈ حقیقی وقت کے ڈیٹابیس کے طور پر موازنہ کیا جاتا ہے۔ ان کے درمیان منصوبہ کا انتخاب منصوبے کی مخصوص ضروریات: سوال کی پیچیدگی، مطلوبہ مستقلیت، اور متوقع بوجھ پر منحصر ہے۔ ہر ڈیٹابیس کی طاقت کو سمجھنا سحیح فنی فیصلہ کرنے میں مدد کرتا ہے۔

Realtime Database کا اہم فائدہ کم مطابقت تاخیر ہے۔ چونکہ تمام ڈیٹا بغیر کسی اضافی تجرید کی پرت کے ایک واحد JSON درخت میں محفوظ ہوتا ہے، مطابقت Firestore کے مقابلے تیز ہوتی ہے۔ ایسی ایپلیکیشنز کے لیے جہاں تازہ کرنے کی ترسیل کی بہار اہم ہے (چٹینگ، آن لائن گیمز، مشترکہ تدوین کے نظام) کے لیے، Realtime Database زیادہ موزوں منصوبہ ہو سکتا ہے۔

Realtime Database کب استعمال کریں

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

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

Realtime Database میں مطابقت کیسے کام کرتی ہے

Realtime Database دو طرفہ ڈیٹا مطابقت کے لیے ایک مستقل WebSocket کنیکشن استعمال کرتا ہے۔ جب کوئی کلائنٹ کسی مقرر راستے پر setValue یا updateChildren کو کال کرتا ہے تو کھلے چینل کے ذریعے ڈیٹا Firebase سرور کو بھیجا جاتا ہے۔ سرور تبدیلیوں کا اطلاق کرتا ہے اور ملی سیکنڈ میں سبسکرائیب شدہ تمام کلائنٹس کو تازہ کرنے کی تبدیلیاں پہنچاتا ہے۔ ہر کنیکشن کی شناخت ایک منفرد سیشن کلید سے ہوتی ہے۔

سبسکرائیپشن کا میکشناسم لسنرز کے ذریعے کام کرتا ہے۔ ایک ڈیویلپر کسی مقرر نوڈ پر تبدیلیوں کی سبسکرائیپ کر سکتا ہے (addListenerForSingleValueEvent) یا مستقل تازہ کرنے والی تبدیلیاں وصول کر سکتا ہے (addValueEventListener)۔ جب بھی ڈیٹا بدلتا ہے تو مقرر راستے پر مکمل ڈیٹا ایک جھٹ کے ساتھ onDataChange کال بیک چلتا ہے۔ یہ Firestore سے مختلف ہے جہاں صرف بدلے گئے دستاویز موصول ہوتے ہیں۔

آف لائن موڈ اور تنازع کا انتظام

Realtime Database Android اور iOS پر ڈسک کیشنگ کے ذریعے آف لائن موڈ کی حمایت کرتا ہے۔ SDK ڈیٹا کی مقامی نقل رکھتا ہے اور نیٹ ورک نہ ہونے پر بھی لکھنے کے عملیات کو کاروائی کرتا رہتا ہے۔ جب کنیکشن بحال ہوتا ہے تو تمام جمع شدہ تبدیلیاں سرور کو بھیجی جاتی ہیں۔ تنازع کے حل کے لیے آخری لکھائی جیت کی حکمت عمل استعمال ہوتی ہے، لیکن ڈیویلپرز ٹکراو کے حل کے لیے ServerValue.TIMESTAMP کے ذریعے کسٹم لاجک لاگو کر سکتے ہیں۔

val database = FirebaseDatabase.getInstance()
val myRef = database.getReference("messages")

// ڈیٹا لکھنا
myRef.push().setValue(
    hashMapOf(
        "text" to "نئی پیغام",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// مستقل تازہ کرنے کے ساتھ پڑھنا
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "ڈیٹا: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "غلطی: ${error.message}")
    }
})

ٹریفک اور کارکردگی کو بہتر بنانے کے لیے، مقرر چیلڈ نوڈز میں تبدیلیوں کو ٹریک کرتے وقت ویلیو لسنرز کے بجائے daرمائے لسنرز استعمال کرنے کی سفارش کی جاتی ہے۔ ChildEventListener چیلڈ عناصر کے اضافے، ترمیم، ہٹانے اور منتقل کرنے کے لیے علیحدہ کال بیک فراہم کرتا ہے، جو یوآئی اپڈیٹس کو زیادہ عملی کنٹرول کرنے اور ہر ڈیٹا تبدیلی پر تمام فہرست کے اشیاء کو دبارہ کھینچنے سے بچاتا ہے۔

سیکیورٹی اصول اور ڈیٹا تصدیق

Realtime Database ڈیٹا رسائی کنٹرول کے لیے ایک اعلانی اصول زبان استعمال کرتا ہے۔ اصول بتاتے ہیں کہ JSON درخت کے ہر راستے پر کون ڈیٹا پڑھ اور لکھ سکتا ہے۔ وہ ہر درخواست سے پہلے Firebase سرور پر چیک کیے جاتے ہیں اور اجازت کے لیے سرور سائڈ لاجک کی ضرورت نہیں ہوتی۔ اصول لچیدار رسائی ترتیب کے لیے متغیرات، مضمونی آبجیکٹس اور فنکشنز کی حمایت کرتے ہیں۔

پہلے سے طے طور پر، تمام صارفین کے لیے ڈیٹابیس رسائی منع ہے۔ ڈیویلپر درخت کی مختلف سطحوں پر ".read" اور ".write" اصول کا استعمال کرتے ہوئے آہستہ آہستہ رسائی کو کھولتا ہے۔ شرائط auth متغیر کے ذریعے مصداقت، درخواست کی قسم (پڑھنا/لکھنا) اور data آبجیکٹ کے ذریعے موجودہ ڈیٹا کو چیک کر سکتی ہیں۔ مزید براں، اصول newData آبجیکٹ کے ذریعے لکھے گئے ڈیٹا کی تصدیق کی حمایت کرتے ہیں۔

{
  "rules": {
    "users": {
      "$uid": {
        // صرف مالک اپنا ڈیٹا پڑھ سکتا ہے
        ".read": "$uid === auth.uid",
        // صرف مالک لکھ سکتا ہے
        ".write": "$uid === auth.uid",
        // لکھتے وقت فیلڈز کی تصدیق
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // کوئی بھی مصدق صارف پڑھ سکتا ہے
      ".read": "auth !== null",
      // صرف مصدق صارف لکھ سکتا ہے
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

اصول ".indexOn" ہدایت کے ذریعے ڈیٹا انڈیکسنگ کی بھی حمایت کرتے ہیں۔ اس کے بغیر، ترتیب دےنے والے سوالات (orderByChild) کو مسترد کر دیا جائے گا یا غیر موثر طور پر عمل کیا جائے گا۔ اشارے ہر ایسے راستے کے لیے متعین کی جاتی ہیں جہاں کسی مقرر فیلڈ کے مطابق ترتیب دیا جاتا ہے۔ اصول کیسکیڈ کرتے ہیں: گھرے اصول والد اصول کو منسوخ کرتے ہیں، اور اگر کسی سطح پر رسائی متعین نہیں ہے تو والد اصول کے مطابق اسے منظور یا نامنظور سمجھا جاتا ہے۔

ڈیٹا کی قسمیں اور حدود

Realtime Database پانچ ڈیٹا قسموں کی حمایت کرتا ہے: String، Number، Boolean، Map (آبجیکٹ) اور List (ایرے)۔ گھرے ساخت کی گہرائی 32 سطحوں تک محدود ہے اور ایک نوڈ کا حد اکثر حجم 256 MB سے زیادہ نہیں ہونا چاہیے۔ موثر ڈیٹابیس کام کے لیے، ایک چپٹی ڈیٹا ساخت تیار کرنے اور بڑی مقدار میں ڈیٹا لوڈ کرنے والے گھرے سوالوں سے بچنے کے لیے ڈی نارملائزیشن کا استعمال کرنے کی سفارش کی جاتی ہے۔

Android میں Realtime Database کے استعمال کی مثال

آئیں صارف کی حالتیں (آن لائن/آف لائن) کے لیے ایک Android ایپلیکیشن میں Realtime Database کے انضمام کی ایک عملی مثال پر غور کریں۔ ایپلیکیشن صارفین کی ان کی موجودہ حالت کے ساتھ ایک فہرست ظاہر کرے گا جو حقیقی وقت میں اپڈیٹ ہوتی ہے۔ مظاہرہ کے لیے صارف کی شناخت کے لیے Firebase Authentication اور غیر ہم آہنگ عملیات کے لیے کوروٹینز استعمال کیے جاتے ہیں۔

انحصاریات کا کانفیگریوریشن اور ابتدائیة کاروائی

شروع کرنے کے لیے، ایپ ماڈیول کی build.gradle فائل میں firebase-database-ktx انحصار شامل کریں۔ لائبریری کا ورژن Firebase BoM کے ذریعے منتظم ہوتا ہے تاکہ تمام اجزائی کی مطابقت یقینی ہوⷜ۔ انحصار شامل کرنے کے بعد، Firebase کو Application کلاس میں یا ViewModel میں سست ابتدائیة کے ذریعے ابتدائیہ کرنا چاہیے۔

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

کانفیگریوریشن کے بعد، صارفین کے ساتھ کام کرنے کے لیے ایک ریپوزیٹری بنائی جاتی ہے۔ ہر صارف name، email اور status فیلڈز کے ساتھ /users/{uid} درخت میں ایک نوڈ سے ظاہر کیا جاتا ہے۔ حالت کے نشان دہی کے لیے onDisconnect استعمال ہوتا ہے — Firebase کا ایک خاص میکشناسم جو کلائنٹ کنیکشن منصل ہونے پر خودکار طور پر ایک لکھنے کا عمل کرتا ہے۔ یہ یقینی بناتا ہے کے کلائنٹ کی جانب سے اضافی کوڈ کے بغیر ایپلیکیشن بند ہونے یا نیٹ ورک کے کھونے پر صارف کی حالت "offline" میں بدل جاتی ہے۔

class PresenceRepository {
    private val database = FirebaseDatabase.getInstance()
    private val auth = FirebaseAuth.getInstance()
    private val presenceRef = database
        .getReference("presence")

    fun trackPresence() {
        val uid = auth.currentUser?.uid ?: return
        val userRef = presenceRef.child(uid)

        userRef.onDisconnect().setValue("offline")
        userRef.setValue("online")
    }

    fun getPresenceStream(): Flow<Map<String, String>> =
        presenceRef.snapshotFlow()
            .map { snapshot ->
                (snapshot.value as? Map<*, *>)
                    ?.mapKeys { it.key.toString() }
                    ?.mapValues { it.value.toString() }
                    ?: emptyMap()
            }
}

مثال کا اہم عنصر onDisconnect ہے۔ یہ میکشناسم ایک ایسا لکھنے کا عمل مقرر کرنے کی اجازت دیتا ہے جو کلائنٹ کا کنیکشن منصل ہونے پر سرور پر عمل کیا جائے گا۔ اس معاملے میں، جب صارف کا کنیکشن ختم ہوتا ہے تو ایپلیکیشن بند ہونے کے واقعے کو ہینڈل کرنے کی ضرورت کے بغیر ان کی حالت خودکار طور پر "offline" پر مقرر ہو جاتی ہے۔ اگر ایپ کریش ہو جائے تو Firebase خود onDisconnect کا عمل کرے گا اور دوسرے صارفین سحیح حالت دیکھیں گے۔