Firebase Firestore: یہ کیا ہے، NoSQL اور یہ کیسے کام کرتا ہے

Firebase Firestore کیا ہے؟

Firebase Firestore ایک لچکدار، اسکیل ایبل NoSQL ڈیٹا بیس ہے جسے Google نے 2019 میں Firebase Realtime Database کے ارتقاء کے طور پر لانچ کیا۔ یہ دستاویزات کے کلیکشنز میں ڈیٹا ذخیرہ کرتا ہے، جہاں ہر دستاویز میں کلید-قدر کے جوڑوں کا ایک سیٹ ہوتا ہے۔ روایتی رلیشنل ڈیٹا بیسز کے برعکس، Firestore کو پہلے سے طے شدہ اسکیما کی ضرورت نہیں ہوتی — ڈیٹا کا ڈھانچہ لکھی جانے والی دستاویزات کی بنیاد پر متحرک طور پر تشکیل پاتا ہے۔

Firestore اور کلاسک کلاؤڈ ڈیٹا بیسز کے درمیان بنیادی فرق بلٹ ان ریئل ٹائم ہم آہنگی ہے۔ جب سرور پر ڈیٹا تبدیل ہوتا ہے، تمام منسلک کلائنٹس ایک مستقل WebSocket کنکشن کے ذریعے اپ ڈیٹس وصول کرتے ہیں۔ یہ دستی سرور پولنگ کی ضرورت کو ختم کرتا ہے اور لائیو اپ ڈیٹس والی ایپلیکیشنز بنانے کی اجازت دیتا ہے: چیٹس، سرگرمی فیڈز، باہمی تعاون والے ایڈیٹرز اور مانیٹرنگ سسٹم۔

یہ ڈیٹا بیس تمام بڑے پلیٹ فارمز پر دستیاب ہے: Android، iOS، Web (JavaScript) اور Admin SDK کے ذریعے سرور سائڈ زبانیں۔ Firestore Swift، Kotlin، JavaScript، Python، Go، Java اور Node.js کے لیے SDK فراہم کرتا ہے۔ Google کے مطابق، Firestore پورے Firebase ایکو سسٹم میں روزانہ 100 بلین سے زیادہ درخواستوں پر کارروائی کرتا ہے، جو پروڈکشن ایپلیکیشنز کی بنیاد کے طور پر اس کی وشوسنییتا کی تصدیق کرتا ہے۔

بنیادی تصورات: کلیکشنز اور دستاویزات

Firestore میں، ڈیٹا ایک درجہ بندی کے ڈھانچے میں منظم ہوتا ہے۔ کلیکشن دستاویزات کا ایک کنٹینر ہے، جو SQL میں ٹیبل کی طرح ہے لیکن فکسڈ اسکیما کے بغیر۔ دستاویز ایک ریکارڈ ہے جس میں مختلف اقسام کے فیلڈز ہوتے ہیں: سٹرنگز، نمبرز، بولین ویلیوز، اریز، نیسٹڈ آبجیکٹس اور جیوپوائنٹس۔ دستاویزات میں ذیلی کلیکشنز ہو سکتے ہیں، جو کسی بھی گہرائی کے نیسٹڈ ڈیٹا ڈھانچے بنانے کی اجازت دیتے ہیں۔

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Anna Petrova",
    "email" to "anna@example.com",
    "age" to 28,
    "isActive" to true
)

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "دستاویز ID کے ساتھ شامل کی گئی: ${docRef.id}")
    }

کلیکشن میں ہر دستاویز کا ایک منفرد شناخت کنندہ ہوتا ہے، جو خودکار طور پر پیدا یا دستی طور پر سیٹ کیا جا سکتا ہے۔ Firestore خود بخود تمام دستاویز فیلڈز کو انڈیکس کرتا ہے، جس سے دستی انڈیکس کنفیگریشن کے بغیر فلٹرنگ، ترتیب اور نتائج کی حد بندی کے ساتھ پیچیدہ کوریز ممکن ہوتی ہیں۔

Firebase Firestore بمقابلہ Realtime Database: موازنہ

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

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

اسکیل ایبلٹی اور ڈیٹا کا ڈھانچہ

Firestore اپنی ملٹی ریجن آرکیٹیکچر کی بدولت لاکھوں بیک وقت کنکشنز تک خودکار طور پر اسکیل ہوتا ہے۔ Realtime Database ایک علاقے تک محدود ہے اور زیادہ سے زیادہ 200,000 بیک وقت کنکشنز۔ عالمی سامعین کو نشانہ بنانے والے پروجیکٹس کے لیے، Firestore افضل ہے کیونکہ ڈیٹا خود بخود متعدد Google ڈیٹا سینٹرز میں نقل ہوتا ہے۔

Firestore میں ڈیٹا کا ڈھانچہ ذیلی کلیکشنز کے ساتھ پیچیدہ درجہ بندی کے ماڈلز بنانے کی اجازت دیتا ہے۔ مثال کے طور پر، ایک صارف کے پاس «آرڈرز» ذیلی کلیکشن ہو سکتا ہے، اور ہر آرڈر کے پاس «آئٹمز» ذیلی کلیکشن۔ Realtime Database میں، اس طرح کی گہری نیسٹنگ کوریز کے دوران کارکردگی کے مسائل کا سبب بنتی ہے کیونکہ جڑ سے مطلوبہ نوڈ تک پورا راستہ لوڈ ہوتا ہے۔

Firestore میں ڈیٹا ہم آہنگی کیسے کام کرتی ہے

Firestore ریئل ٹائم ڈیٹا ہم آہنگی کے لیے کلائنٹ اور سرور کے درمیان ایک مستقل WebSocket کنکشن استعمال کرتا ہے۔ جب کوئی ایپلیکیشن سنیپ شاٹ لسنر کے ذریعے کسی دستاویز یا کلیکشن میں تبدیلیوں کو سبسکرائب کرتی ہے، SDK ایک مواصلاتی چینل قائم کرتا ہے جس کے ذریعے سرور ڈیٹا تبدیل ہونے پر اپ ڈیٹس بھیجتا ہے۔ کلائنٹ ہر بار پورے کلیکشن کا مکمل سنیپ شاٹ نہیں، صرف تبدیل شدہ دستاویزات وصول کرتا ہے۔

ہم آہنگی کا طریقہ کار ایونٹ سٹریم پر مبنی ہے: added (دستاویز ظاہر ہوئی)، modified (دستاویز تبدیل ہوئی) اور removed (دستاویز حذف ہوئی)۔ ڈیویلپر ہر ایونٹ کو الگ الگ سنبھال سکتا ہے، صرف متعلقہ UI عناصر کو اپ ڈیٹ کر کے۔ یہ ہزاروں دستاویزات کے باوجود اعلی کارکردگی کو یقینی بناتا ہے کیونکہ صرف تبدیل شدہ اجزاء دوبارہ پیش کیے جاتے ہیں۔

آف لائن رسائی اور کیشنگ

Firestore کے اہم فوائد میں سے ایک بلٹ ان آف لائن موڈ سپورٹ ہے۔ SDK خود بخود پڑھے گئے تمام ڈیٹا کو ڈیوائس پر کیش کرتا ہے اور نیٹ ورک نہ ہونے پر کام جاری رکھتا ہے۔ جب ایپلیکیشن آف لائن موڈ میں ڈیٹا لکھتی ہے، تو اسے مقامی قطار میں رکھا جاتا ہے اور کنکشن بحال ہونے پر سرور کو بھیجا جاتا ہے۔ تنازعات کے حل کے لیے last-write-wins حکمت عملی استعمال ہوتی ہے۔

val docRef = db.collection("cities").document("SF")

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "سننے میں خرابی", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "موجودہ ڈیٹا: ${snapshot.data}")
    }
}

کیش کا سائز FirestoreSettings کے ذریعے ترتیب دیا جا سکتا ہے۔ پہلے سے طے شدہ قدر 100 MB ہے لیکن ڈیٹا زیادہ پڑھنے والی ایپلیکیشنز کے لیے بڑھایا جا سکتا ہے۔ ایک مستقل ڈسک کیش موڈ بھی دستیاب ہے جو ایپلیکیشن دوبارہ شروع ہونے کے بعد بھی برقرار رہتا ہے۔ آف لائن موڈ کی دستیابی کو منظم کرنے کے لیے، enableNetwork اور disableNetwork طریقے استعمال کیے جاتے ہیں، جو عارضی طور پر نیٹ ورک تعامل کو غیر فعال کرنے کی اجازت دیتے ہیں۔

Firestore سیکیورٹی اور رسائی کے قوانین

Firestore Security Rules سرور کی سطح پر ڈیٹا تک رسائی کو کنٹرول کرنے کے لیے ایک اعلانیہ مارک اپ زبان ہے۔ قوانین طے کرتے ہیں کہ کون کن شرائط میں دستاویزات پڑھ اور لکھ سکتا ہے۔ وہ کوری پر عمل درآمد سے پہلے کام کرتے ہیں اور اجازت کے لیے علیحدہ سرور لاجک کی ضرورت نہیں ہوتی۔ ہر ڈیٹا پڑھنے یا لکھنے سے پہلے Firebase side پر قوانین کی جانچ کی جاتی ہے۔

رسائی کے قوانین اجازت (allow) کے اصول پر بنائے گئے ہیں۔ پہلے سے طے شدہ طور پر، تمام رسائی ممنوع ہے۔ ڈیویلپر مخصوص شرائط کے تحت مخصوص کارروائیوں (read, write, create, update, delete) کے لیے ترتیب وار رسائی کھولتا ہے۔ شرائط request.auth کے ذریعے صارف کی تصدیق، request.resource کے ذریعے درخواست کا ڈیٹا اور resource کے ذریعے موجودہ ڈیٹا کو چیک کر سکتی ہیں۔

// Firestore رسائی کے قوانین
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // صارف صرف اپنا ڈیٹا پڑھتا اور لکھتا ہے
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // کوئی بھی تصدیق شدہ صارف پوسٹس پڑھ سکتا ہے
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

قوانین کے ذریعے ڈیٹا کی توثیق

رسائی کنٹرول کے علاوہ، Security Rules لکھے گئے ڈیٹا کی ساخت اور اقسام کی توثیق کرنے کی اجازت دیتی ہیں۔ مثال کے طور پر، چیک کیا جا سکتا ہے کہ ای میل فیلڈ ایک ریگولر ایکسپریشن سے میل کھاتا ہے، یا عمر 120 سال سے زیادہ نہیں ہے۔ توثیق لکھنے سے پہلے کی جاتی ہے، جو سرور پر غلط ڈیٹا کو محفوظ ہونے سے روکتی ہے۔ فیلڈ کی توثیق کے لیے، request.resource.data آبجیکٹ استعمال ہوتا ہے جس میں لکھی جانے والی پوری دستاویز ہوتی ہے۔

Firestore ان کلیکشنز کو بھی سپورٹ کرتا ہے جو کلائنٹ کی رسائی کے بغیر، صرف Admin SDK کے ذریعے سرور سائڈ تحریر کے لیے قابل رسائی ہیں۔ یہ سروس کی معلومات، API چابیاں اور کنفیگریشنز کو ذخیرہ کرنے کے لیے مفید ہے جو صارفین کو نظر نہیں آنی چاہئیں۔ اس کے لیے، قوانین میں متعلقہ کلیکشنز پر تمام کلائنٹ کارروائیوں سے انکار کرنا کافی ہے، صرف سرور کی طرف سے Admin SDK کے ذریعے رسائی کی اجازت دیتے ہوئے۔

Android میں Firebase Firestore استعمال کرنے کی مثال

آئیے کاموں کی فہرست (todo) بنانے کے لیے Android ایپلیکیشن میں Firestore انضمام کی ایک مثال دیکھتے ہیں۔ ایپلیکیشن کاموں کو ریئل ٹائم میں پڑھے گی، نئے شامل کرے گی اور مکمل شدہ کاموں کو نشان زد کرے گی۔ غیر مطابقت پذیر کام کے لیے، Firebase کال بیک انٹرفیس اور Kotlin کوریوٹینز استعمال کی جاتی ہیں۔

Firebase سیٹ اپ اور انحصار کا اضافہ

شروع کرنے سے پہلے، Firebase Console کے ذریعے پروجیکٹ کو Firebase سے منسلک کرنا اور google-services.json فائل کو ایپلیکیشن ماڈیول میں شامل کرنا ضروری ہے۔ پھر، build.gradle میں firebase-firestore-ktx انحصار اور google-services پلگ ان شامل کیا جاتا ہے۔ لائبریری کا ورژن تمام Firebase کمپوننٹس کی ایک دوسرے کے ساتھ مطابقت کے لیے موجودہ Firebase BoM ورژن کے مطابق ہونا چاہیے۔

dependencies {
    // Firebase BoM — ورژن مینجمنٹ
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-firestore-ktx"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.9.0"
}

سیٹ اپ کے بعد، ایک Task ڈیٹا ماڈل اور Firestore کے ساتھ کام کرنے کے لیے ایک ذخیرہ بنایا جاتا ہے۔ ماڈل میں id، title، isCompleted اور timestamp فیلڈز ہوتے ہیں۔ Firestore فیلڈ کے ناموں کو کلید کے طور پر استعمال کرتے ہوئے خود بخود ڈیٹا کلاس کو دستاویز میں سیریلائز کرتا ہے۔ ڈیٹا پڑھنے کے لیے، ایک سنیپ شاٹ لسنر استعمال کیا جاتا ہے جو snapshotFlow ایکسٹینشن کے ذریعے Flow واپس کرتا ہے۔

data class Task(
    val id: String = "",
    val title: String = "",
    val isCompleted: Boolean = false,
    val createdAt: Timestamp? = null
)

class TaskRepository {
    private val tasksRef = FirebaseFirestore
        .getInstance()
        .collection("tasks")

    fun getTasks(): Flow<List<Task>> = tasksRef
        .orderBy("createdAt", Query.Direction.DESCENDING)
        .snapshotFlow()
        .map { snapshot ->
            snapshot?.toObjects(Task::class.java) ?: emptyList()
        }

    suspend fun addTask(title: String) {
        tasksRef.add(Task(title = title))
    }
}

ViewModel ذخیرے سے Flow کو سبسکرائب کرتا ہے اور کاموں کی فہرست UI سطح پر بھیجتا ہے۔ جب نیا کام شامل کیا جاتا ہے، تو ذخیرے کے suspend فنکشن کو کوریوٹین اسکوپ کے ذریعے کال کیا جاتا ہے۔ Firestore خود بخود تمام کلائنٹس کے درمیان تبدیلیوں کو ہم آہنگ کرتا ہے: اگر کوئی صارف کام شامل کرتا ہے، تو دوسرے اسے اسکرین ریفریش کیے بغیر ریئل ٹائم میں دیکھتے ہیں۔