فلٹر فرنٹ اینڈ سسٹم ڈیزائن: AI دور میں سینئر انجینئر کی طرح سوچنا کیسے ہے۔

سسٹم ڈیزائن کو ہمیشہ بیک اینڈ مسئلہ سمجھا جاتا رہا ہے۔

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

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

یہی فرق ہے۔ اور یہ تیزی سے بند ہو جاتا ہے۔

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

پروڈکٹ کمپنیوں میں فلٹر سینئرز کے انٹرویوز تیزی سے اس ٹیکنالوجی کی جانچ کر رہے ہیں۔ انجینئر جو واضح طور پر وضاحت کر سکے۔ کیوں انہوں نے ایک خاص فن تعمیر کا انتخاب کیا، انہوں نے ان تجارتی مواقع کا انتخاب کیا جس پر انہوں نے غور کیا، اور جس مسئلے کے لیے انہوں نے بہتر بنایا وہ ہے ملازمت اور ترقی کا مسئلہ۔

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

شرطیں

یہ مضمون فرض کرتا ہے کہ آپ ایک فلٹر ڈویلپر ہیں جو اسٹیٹ مینجمنٹ (ریور پوڈ، بلاک، وغیرہ)، REST APIs، اور بنیادی ڈارٹ سے واقف ہیں۔ کسی بیک اینڈ تجربے کی ضرورت نہیں ہے، لیکن کیشنگ، صفحہ بندی، اور WebSockets جیسے تصورات سے واقفیت آپ کو گہرے حصوں کو سمجھنے میں مدد کرے گی۔

کوڈ سیٹ اپ کی ضرورت نہیں ہے۔ یہ مضمون ٹیوٹوریل نہیں بلکہ سوچ اور فن تعمیر کے بارے میں ہے۔ ڈارٹ/فلٹر کے ٹکڑوں کا استعمال ٹھوس نفاذ میں تجریدی خیالات کو بنانے کے لیے کیا جاتا ہے۔

انڈیکس

1. فرنٹ اینڈ سسٹم ڈیزائن کیا ہے؟

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

پسدید پر، اس کا مطلب ہے مائیکرو سروسز اور یک سنگی کے درمیان فیصلہ کرنا، ڈیٹا بیس کا انتخاب کرنا، API کے معاہدوں کو ڈیزائن کرنا، اور افقی اسکیلنگ کے لیے منصوبہ بندی کرنا۔ فیڈ بیک لوپ تیز ہے۔ ایک خراب ڈیٹا بیس اسکیما کچھ دنوں میں سوالات کو سست کرنے کا سبب بنے گا، اور ایک خراب ڈیزائن کردہ API کلائنٹس کو فوری طور پر کریش کرنے کا سبب بنے گا۔

سامنے والے سرے پر، ناقص ڈیزائن کا نتیجہ سست اور پرسکون ہے۔ 600 لائن اسکرین ویجٹ اب بھی دستیاب ہیں۔ 40 طریقوں کے ساتھ بہترین ذخیرہ اب بھی کام کرتا ہے۔ کراس سیشن اسٹیٹ لیک صرف اس وقت ظاہر ہوتا ہے جب مایوس صارفین ان کی اطلاع دیتے ہیں۔

فرنٹ اینڈ سسٹم ڈیزائن سوالات کے وہی زمرے پوچھتا ہے جو کلائنٹ پرت پر لاگو ہوتے ہیں۔

• آپ ایک بڑی ایپ کو آزادانہ طور پر قابل تعمیر افعال میں کیسے توڑتے ہیں؟

• کاروباری منطق کہاں ہے، اور اس کی حدود کو کیا نافذ کرتا ہے؟

• ڈیٹا نیٹ ورک سے اسکرین پر کیسے جاتا ہے؟

• اگر نیٹ ورک ناکام ہو جائے، API کی شکل بدل جائے، یا سیشن کے دوران صارف لاگ آؤٹ ہو جائے تو کیا ہوتا ہے؟

• آپ ایسے اجزاء کو کیسے ڈیزائن کرتے ہیں جن کا آزادانہ طور پر تجربہ کیا جا سکتا ہے؟

• آپ اپنی ایپ کی ساخت کیسے بناتے ہیں تاکہ آپ کی انجینئرنگ ٹیم ایک دوسرے پر قدم رکھے بغیر کام کر سکے۔

یہ ویجیٹ کا سوال نہیں ہے۔ یہ فن تعمیر سے متعلق سوال ہے۔ اور ان کے پاس جوابات ہیں: اصولی جوابات اور عملی سمجھوتے۔

2. کیوں پھڑپھڑانے والے انجینئر اب اسے نظر انداز نہیں کر سکتے

تین قوتیں نظام کے ڈیزائن کو فلٹر گفتگو میں اس طرح آگے بڑھا رہی ہیں جو تین سال پہلے موجود نہیں تھا۔

پھڑپھڑانے والی ایپس اب صرف UI نہیں ہیں۔

سرور پر Serverpod اور Dart Frog کے ساتھ، ویب پر Jaspr، اور موبائل اور ڈیسک ٹاپ پر Flutter کے ساتھ، Dart اب واقعی ایک مکمل اسٹیک زبان ہے۔ ایک ہی کوڈبیس میں موبائل، ویب اور سرور پر آرکیٹیکچرل فیصلے کرنے والے انجینئرز کو سسٹم سوچنے کے ساتھ ساتھ ویجیٹ کنفیگریشن کی مہارتوں کی ضرورت ہوتی ہے۔

جب فلٹر کلائنٹ اور ڈارٹ بیک اینڈ کے درمیان ایک فکسڈ ماڈل کا اشتراک کیا جاتا ہے، تو "فرنٹ اینڈ” اور "بیک اینڈ” ڈیزائن کے درمیان باؤنڈری ٹوٹ جاتی ہے۔ میں ایک سسٹم ڈیزائن کر رہا ہوں۔

AI ایجنٹس فوری طور پر ناقص فن تعمیر کو بے نقاب کرتے ہیں۔

یہ نیا پریشر پوائنٹ ہے۔ جب کلاڈ کوڈ یا AI کوڈنگ ایجنٹ کولڈ کسی پروجیکٹ کو پڑھتا ہے، تو اس کے پاس اس کی گندگی کی تلافی کے لیے کوئی جمع شدہ ذہنی ماڈل نہیں ہوتا ہے۔ فائلوں کو ترتیب وار پڑھیں۔ یہ ایک محدود سیاق و سباق ونڈو کے اندر کام کرتا ہے۔ یہ ان نمونوں کی بنیاد پر فیصلے کرتا ہے جو اسے دیکھتا ہے۔

الجھے ہوئے انحصار، متضاد ناموں اور کاروباری منطق کے ساتھ ویجیٹ ٹری میں بکھرے ہوئے کوڈ بیس ناقابل اعتبار AI آؤٹ پٹ پیدا کرتے ہیں۔ ایسا اس لیے نہیں ہوتا کیونکہ AI غلط ہے، ایسا اس لیے ہوتا ہے کہ کوڈ اپنی ساخت کو اتنا واضح طور پر نہیں بتاتا کہ انسانی وجدان کے بغیر تشریف لے جا سکے۔

اچھا سسٹم ڈیزائن اور AI قابل دریافت فن تعمیر تقریباً ایک جیسے ہیں۔ فنکشن-پہلا ڈھانچہ، واضح پرت کی حدود، مسلسل نام، چھوٹی، فوکس فائلز۔ یہ اب صرف ٹیم کی حفظان صحت کی مشق نہیں ہے۔ یہ وہی ہے جو AI کی مدد سے ترقی کو واقعی پیمانے پر کام کرتا ہے۔

اب ہم سینئر فلٹر انٹرویوز میں واضح طور پر اس کی جانچ کرتے ہیں۔

جیسے جیسے فلٹر پختہ ہوتا ہے اور پروڈکٹ کمپنیاں بڑی ٹیموں کے ساتھ بڑی ایپس بناتی ہیں، انٹرویو کے معیارات بڑھ گئے ہیں۔ درمیانی سطح کا فلٹر انٹرویو ویجیٹ لائف سائیکل اور ریاستی انتظام کے بنیادی اصولوں کی جانچ کر سکتا ہے۔ سینئر انٹرویوز آپ کے خیالات کو بلند آواز میں بیان کرتے ہوئے حقیقی وقت کے دباؤ میں پہلے کبھی نہ دیکھے گئے سسٹمز کو ڈیزائن کرنے کی آپ کی صلاحیت کو جانچتے ہیں۔

اگر آپ نے کمرے میں جانے سے پہلے اس کے بارے میں کبھی نہیں سوچا تو آپ الجھن میں پڑ جائیں گے۔

3. انٹرویو کی شکل: کیا توقع کی جائے۔

سینئر عہدوں کے لیے فرنٹ اینڈ سسٹم ڈیزائن انٹرویوز عام طور پر 45 سے 60 منٹ تک رہتے ہیں۔ آپ کو "ڈیزائن” جیسا مبہم منظر نامہ دیا گیا ہے۔ "سوشل فیڈز کے لیے فلٹر کلائنٹ”اور توقع کی جاتی ہے کہ آپ گفتگو کی قیادت کریں گے۔

انٹرویو لینے والا ایک بھی صحیح جواب نہیں ڈھونڈ رہا ہے۔ وہ دیکھ رہے ہیں کہ آپ کیا سوچتے ہیں۔

• کیا آپ حل شروع کرنے سے پہلے اپنی ضروریات کو واضح کرتے ہیں؟

• کیا آپ آسان مسائل کی بجائے مشکل مسائل (ریئل ٹائم سنکرونائزیشن، پرامید UI، آف لائن موجودگی) کی نشاندہی کرتے ہیں؟

• کیا آپ اس چیز کو منتخب کرنے کے بجائے واضح طور پر تجارت کرتے ہیں جسے آپ بہتر جانتے ہیں؟

• کیا میں دھکیل کر کسی بھی تہہ میں گہرائی میں جا سکتا ہوں؟

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

4. اپنے جواب کی تشکیل کیسے کریں۔

اپنے فرنٹ اینڈ سسٹم ڈیزائن کے سوالات کے لیے اس فریم ورک کا استعمال کریں۔

1. اپنی ضروریات کو واضح کریں (5 منٹ) کون سا پلیٹ فارم؟ آپ کے کتنے صارفین ہیں؟ آف لائن سپورٹ؟ حقیقی وقت؟ ثبوت؟ اس گفتگو کا دائرہ کیا ہے؟ کبھی کچھ فرض نہ کریں۔

2. اپنے ڈیٹا ماڈل کی وضاحت کریں (5-10 منٹ) بنیادی ادارے کیا ہیں؟ ان کا رشتہ کیا ہے؟ یہ بعد کے تمام آرکیٹیکچرل فیصلوں کی بنیاد بن جاتا ہے۔

3. پرت آرکیٹیکچر ڈیزائن (10 منٹ) ایپس کی درجہ بندی کیسے کی جاتی ہے؟ پرتیں کیا ہیں؟ کیا ان کے درمیان سرحدوں کو مضبوط کرتا ہے؟

4. مشکل مسائل کو ایک ایک کرکے حل کریں (20-25 منٹ) صفحہ بندی پرامید UI۔ ریئل ٹائم سنکرونائزیشن۔ آف لائن۔ کارکردگی۔ ہر ایک کے بارے میں مزید جانیں اور ان کے فوائد اور نقصانات کی وضاحت کریں۔

5. ناکام حالات کو حل کرنا (5 منٹ) کیا ٹوٹتا ہے؟ جب ایسا ہوتا ہے تو صارف کا تجربہ کیسا ہوتا ہے؟ لیڈ جواب میں ہمیشہ غلطی کو سنبھالنا شامل ہوتا ہے۔

6. سوال کا خلاصہ اور دعوت نامہ (5 منٹ) اپنے کیے گئے اہم فیصلوں اور تجارتی معاہدوں کا خلاصہ کریں۔ دکھائیں کہ آپ پوری تصویر کھینچ سکتے ہیں۔

5. فرضی انٹرویو: سوشل فیڈ ڈیزائن

انٹرویو لینے والا: سماجی فیڈز کے لیے فلٹر کلائنٹ کا فن تعمیر ڈیزائن کریں۔ صارفین اسکرول کر سکتے ہیں، لائک کر سکتے ہیں اور پوسٹس پر تبصرہ کر سکتے ہیں اور نئی پوسٹس آنے پر ریئل ٹائم اپ ڈیٹس حاصل کر سکتے ہیں۔

یہ جواب ہے۔

مرحلہ 1: ضروریات کو واضح کریں۔

فن تعمیر سے نمٹنے سے پہلے، ایسے سوالات پوچھیں جو آپ کے فیصلوں کو روکتے ہیں۔

"شروع کرنے سے پہلے، میرے پاس کچھ سوالات ہیں: ہم کس پلیٹ فارم کو ٹارگٹ کر رہے ہیں؟ کیا ہم صرف موبائل کے لیے ہیں یا ویب اور ڈیسک ٹاپ کے لیے؟ ہم کتنے صارفین کے لیے ڈیزائن کر رہے ہیں؟ کیا یہ ایک اسٹارٹ اپ MVP ہے یا پیمانے پر ایک ایپ؟ کیا ہمیں آف لائن سپورٹ کی ضرورت ہے؟ ہمیں کتنے ریئل ٹائم کی ضرورت ہے؟ کیا ہم پش نوٹیفیکیشنز کے بارے میں بات کر رہے ہیں یا ہمیں فیڈ کو اپ ڈیٹ کرنے کی ضرورت ہے جب صارف تلاش کر رہا ہے یا لاگ ان ماڈل میں کیا ہے؟ گیسٹ موڈ؟”

یہ واک تھرو مندرجہ ذیل فرض کرتا ہے:

• موبائل (iOS + Android)، ویب روڈ میپ میں شامل ہے۔

• MAU کے دسیوں ہزار. یہ ٹویٹر پیمانے پر نہیں ہے، لیکن یہ معنی خیز ہے۔

• آف لائن: کیش شدہ مواد کی نمائش، قطاروں کے ساتھ تعامل

• ریئل ٹائم: اسکرین کھلی ہونے کے دوران لائیو فیڈ اپ ڈیٹس (ویب ساکٹ)

• توثیق: صرف لاگ ان صارفین

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

مرحلہ 2: اپنے ڈیٹا ماڈل کی وضاحت کریں۔

اداروں اور ان کے تعلقات سے شروع کریں۔ کوڈ لکھنے سے پہلے اسے کھینچیں۔

// Core entities

@freezed
class Post with _$Post {
  const factory Post({
    required String id,
    required String authorId,
    required String authorName,
    required String authorAvatarUrl,
    required String content,
    String? imageUrl,
    required int likeCount,
    required int commentCount,
    required bool isLikedByMe,      // derived from current user context
    required DateTime createdAt,
  }) = _Post;
}

@freezed
class Comment with _$Comment {
  const factory Comment({
    required String id,
    required String postId,
    required String authorId,
    required String authorName,
    required String content,
    required DateTime createdAt,
  }) = _Comment;
}

@freezed
class FeedPage with _$FeedPage {
  const factory FeedPage({
    required List posts,
    required String? nextCursor,    // null = end of feed
  }) = _FeedPage;
}

اس ماڈل میں شامل کئی ڈیزائن فیصلے انٹرویو میں واضح طور پر قابل ذکر ہیں۔

isLikedByMe میں پوسٹ میں رہتا ہوں۔ آپ اسے علیحدہ یوزر لائکس ٹیبل سے اخذ کر سکتے ہیں، لیکن پوسٹ کے جواب میں اسے شامل کرنا آسان ہے اور UI کو بے وطن بنا دیتا ہے۔ اسی طرح کے بٹنوں کو رینڈر کرنے کے لیے اسکرین پر ڈیٹا کے دو ذرائع کو اکٹھا کرنے کی ضرورت نہیں ہے۔

کرسر پر مبنی صفحہ بندی، آفسیٹ نہیں۔ nextCursor بلکہ page: 2. آفسیٹ صفحہ بندی ٹوٹ جاتی ہے جب ایک نئی پوسٹ سب سے اوپر داخل کی جاتی ہے۔ صفحہ 2 پر آئٹم 20 آئٹم 21 بن جاتا ہے، ڈپلیکیٹ کو نشان زد کرنا یا آئٹم کو چھوڑنا۔ کرسر مستحکم ہے۔

likeCount اور commentCount یہ ایک عدد ہے، ایک صف نہیں. کسی پوسٹ کو رینڈر کرنے کے لیے تمام لائکس کی ضرورت نہیں ہے۔ گنتی اور جھنڈے حاصل کریں۔ یہ لامحدود پے لوڈ سائز کو روکنے کے لیے جان بوجھ کر API معاہدہ کرنے کا فیصلہ ہے۔

مرحلہ 3: پرت فن تعمیر کو ڈیزائن کریں۔

چونکہ ڈیٹا متعدد سمتوں میں بہتا ہے (APIs سے نیچے، صارف کے تعاملات سے اوپر، اور ریئل ٹائم ایونٹس کے ساتھ ساتھ)، فیڈ پرت کے نظم و ضبط کو جانچنے کا ایک بہترین طریقہ ہے۔ فلیٹ فن تعمیر تیزی سے ٹوٹ جاتا ہے۔

ساخت مندرجہ ذیل ہے:

lib/
├── core/
│   ├── network/          # Dio client, interceptors, token refresh
│   ├── cache/            # Local storage abstraction (Hive or Isar)
│   ├── realtime/         # WebSocket connection manager
│   └── errors/           # Typed error classes
└── features/
    └── feed/
        ├── data/
        │   ├── models/   # Post, Comment, FeedPage (Freezed)
        │   ├── sources/
        │   │   ├── feed_remote_source.dart   # API calls
        │   │   └── feed_local_source.dart    # Cache reads/writes
        │   └── repositories/
        │       └── feed_repository.dart      # Coordinates remote + local
        └── presentation/
            ├── screens/
            │   └── feed_screen.dart
            ├── widgets/
            │   ├── post_card.dart
            │   ├── like_button.dart
            │   └── comment_sheet.dart
            └── providers/
                ├── feed_provider.dart        # Paginated post list
                ├── like_provider.dart        # Like/unlike actions
                └── realtime_provider.dart    # WebSocket events → state

یہاں چند باتیں قابل توجہ ہیں:

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

دوسرا، ریئل ٹائم پرت ڈیٹا امپورٹ لیئر سے الگ ہے۔ WebSocket ایونٹس کو براہ راست اسی فراہم کنندہ سے جوڑنا جو صفحہ بندی کا انتظام کرتا ہے ایک عام غلطی ہے اور اس کے بارے میں جانچنا یا استدلال کرنا ناممکن ہو جاتا ہے۔ کہ realtime_provider واقعات اور پیچ فیڈ کی حیثیت کے لئے سنیں۔ feed_provider صفحہ بندی کی فہرستوں کا نظم کریں۔ وہ ریور پوڈ کے ذریعے ہم آہنگی کرتے ہیں۔ refبراہ راست انحصار کے ذریعے نہیں۔

مرحلہ 4: صفحہ بندی اور لامحدود سکرولنگ

لامحدود سکرولنگ پہلا مشکل مسئلہ ہے۔ سادہ عمل درآمد: ListView لوڈ کرنے سے ہر چیز سینکڑوں پوسٹس میں ٹوٹ جاتی ہے۔

یہ ہے Riverford AsyncNotifier کرسر پر مبنی صفحہ بندی کو ہینڈل کرتا ہے۔

@riverpod
class FeedNotifier extends _$FeedNotifier {
  static const _pageSize = 20;
  String? _nextCursor;
  bool _isFetchingMore = false;

  @override
  Future> build() async {
    // Load first page + seed from cache if available
    final cached = await ref.read(feedLocalSourceProvider).getCachedPosts();
    if (cached.isNotEmpty) {
      // Show cache immediately, refresh in background
      _refreshInBackground();
      return cached;
    }
    return _fetchPage(cursor: null);
  }

  Future loadMore() async {
    if (_isFetchingMore || _nextCursor == null) return;
    _isFetchingMore = true;

    final currentPosts = state.valueOrNull ?? [];
    final page = await ref
        .read(feedRepositoryProvider)
        .getFeedPage(cursor: _nextCursor, limit: _pageSize);

    _nextCursor = page.nextCursor;
    state = AsyncData([...currentPosts, ...page.posts]);
    _isFetchingMore = false;
  }

  Future> _fetchPage({required String? cursor}) async {
    final page = await ref
        .read(feedRepositoryProvider)
        .getFeedPage(cursor: cursor, limit: _pageSize);
    _nextCursor = page.nextCursor;
    await ref.read(feedLocalSourceProvider).cachePosts(page.posts);
    return page.posts;
  }

  void _refreshInBackground() {
    Future.microtask(() async {
      final freshPosts = await _fetchPage(cursor: null);
      state = AsyncData(freshPosts);
    });
  }

  bool get hasMore => _nextCursor != null;
}

سکرین پر ٹرگر loadMore() اس سے پہلے کہ صارف نیچے پہنچ جائے، آخری شے سے پہلے چند آئٹمز:

NotificationListener(
  onNotification: (notification) {
    if (notification.metrics.pixels >
        notification.metrics.maxScrollExtent - 400) {
      ref.read(feedNotifierProvider.notifier).loadMore();
    }
    return false;
  },
  child: ListView.builder(
    itemCount: posts.length + (hasMore ? 1 : 0),
    itemBuilder: (context, index) {
      if (index == posts.length) return const FeedLoadingIndicator();
      return PostCard(post: posts[index]);
    },
  ),
)

400 پکسل تھریشولڈ کا مطلب ہے کہ اگلا صفحہ صارف کے فہرست کے اختتام کو دیکھنے سے پہلے لوڈ ہونا شروع کر دے گا۔ تجربہ ہموار محسوس ہوتا ہے۔

مرحلہ 5: پسندیدگیوں اور تبصروں کے لیے پرامید UI

پرامید UI مقامی حالت کو فوری طور پر اپ ڈیٹ کرتا ہے جب صارف سرور کے تصدیق کرنے سے پہلے کوئی کارروائی کرتا ہے، اور اگر سرور اسے مسترد کر دیتا ہے تو واپس لوٹ جاتا ہے۔ یہی وجہ ہے کہ لائک بٹن فوری محسوس ہوتا ہے نہ کہ سست۔

پیٹرن کے تین مراحل ہیں: پرامید اپ ڈیٹس کو لاگو کرنا، نیٹ ورک کی درخواست پر عمل کرنا، اور ناکامی پر واپس جانا۔

@riverpod
class LikeNotifier extends _$LikeNotifier {
  @override
  void build() {}

  Future toggleLike(String postId) async {
    final feedNotifier = ref.read(feedNotifierProvider.notifier);
    final currentPosts = ref.read(feedNotifierProvider).valueOrNull ?? [];

    // Find the post
    final postIndex = currentPosts.indexWhere((p) => p.id == postId);
    if (postIndex == -1) return;
    final post = currentPosts[postIndex];

    // Step 1: Apply optimistic update immediately
    final optimisticPost = post.copyWith(
      isLikedByMe: !post.isLikedByMe,
      likeCount: post.isLikedByMe ? post.likeCount - 1 : post.likeCount + 1,
    );
    feedNotifier.patchPost(postIndex, optimisticPost);

    // Step 2: Fire the network request
    try {
      await ref.read(feedRepositoryProvider).toggleLike(postId);
    } catch (e) {
      // Step 3: Roll back on failure
      feedNotifier.patchPost(postIndex, post);
      // Show a snackbar or error indicator
    }
  }
}

کہ patchPost طریقہ FeedNotifier آپ کی پوری فیڈ کو دوبارہ بنائے بغیر فہرست میں ایک پوسٹ کو بدل دیتا ہے۔ جب آپ کی فہرست میں سینکڑوں آئٹمز ہوں تو یہ کارکردگی کی ایک اہم تفصیل ہے۔

انٹرویو میں اپنا نام واضح طور پر بتانے کے نقصانات: پرامید UI متضاد حالت پیدا کر سکتا ہے جب سرور ملتے جلتے نمبروں کے لیے معلومات کے ذرائع ہوتے ہیں۔ ایک ہی وقت میں پسند کرنے والے دونوں صارفین مقامی تعداد میں 41 سے 42 تک بڑھتے ہوئے دیکھیں گے، لیکن اصل تعداد 43 ہے۔ سماجی ایپس کے لیے یہ عام طور پر قابل قبول ہے۔ یہ صارف کو بتائے گا کہ ٹاسک رجسٹر ہو چکا ہے اور اگلی فیڈ ریفریش پر شمار درست کر دیا جائے گا۔ مالی لین دین کے لیے، ایک پرامید UI نامناسب ہے۔ جانیں کہ لکیر کہاں کھینچنی ہے۔

مرحلہ 6: ریئل ٹائم اپ ڈیٹس

ریئل ٹائم فیڈ اپ ڈیٹس اور نئی پوسٹس جو اس وقت ظاہر ہوتی ہیں جب صارف اسکرین کو دیکھ رہا ہوتا ہے ان کے لیے مستقل رابطے کی ضرورت ہوتی ہے۔ WebSockets اس کے لیے صحیح ٹول ہیں۔ سرور سے بھیجے گئے واقعات بھی کام کریں گے، لیکن WebSockets دو طرفہ ہیں، جو اہم ہے اگر آپ واقعات کو بعد میں آگے بڑھانا چاہتے ہیں (ان پٹ انڈیکیٹر، موجودہ حالت)۔

WebSocket پرت کو فیڈ فنکشن کے اندر کی بجائے سنگلٹن سروس کے طور پر ڈیزائن کریں۔

// core/realtime/realtime_service.dart

class RealtimeService {
  WebSocketChannel? _channel;
  final _controller = StreamController.broadcast();

  Stream get events => _controller.stream;

  Future connect(String token) async {
    _channel = WebSocketChannel.connect(
      Uri.parse('wss://api.yourapp.com/ws?token=$token'),
    );

    _channel!.stream.listen(
      (data) {
        final event = RealtimeEvent.fromJson(jsonDecode(data as String));
        _controller.add(event);
      },
      onError: (_) => _scheduleReconnect(),
      onDone: () => _scheduleReconnect(),
    );
  }

  void _scheduleReconnect() {
    Future.delayed(const Duration(seconds: 3), connect);
  }

  void dispose() {
    _channel?.sink.close();
    _controller.close();
  }
}

اس کے بعد آپ کو سٹریم اور پیچ کی حیثیت موصول ہوتی ہے کیونکہ فیڈ لیئر سے نئی پوسٹس آتی ہیں۔

@riverpod
class RealtimeFeedNotifier extends _$RealtimeFeedNotifier {
  StreamSubscription? _subscription;

  @override
  void build() {
    _subscription = ref
        .read(realtimeServiceProvider)
        .events
        .where((e) => e.type == RealtimeEventType.newPost)
        .listen((event) {
      final newPost = Post.fromJson(event.payload);
      ref.read(feedNotifierProvider.notifier).prependPost(newPost);
    });

    ref.onDispose(() => _subscription?.cancel());
  }
}

انٹرویو میں سامنے آنے کے قابل UX فیصلے: کیا آپ خود بخود نئی پوسٹس اپنی فیڈ کے اوپری حصے میں شامل کرتے ہیں، یا کیا آپ "3 نئی پوسٹس، ریفریش کرنے کے لیے تھپتھپائیں” بینر دکھاتے ہیں؟

خودکار اضافہ مشکل ہے۔ صارف پوسٹ 5 پڑھ رہا ہے اور اچانک پوسٹ 8 پڑھتا ہے۔ بینر پیٹرن (Twitter/X اور LinkedIn کے ذریعے استعمال کیا جاتا ہے) تقریباً ہمیشہ ایک بہتر انتخاب ہوتا ہے۔ یہ پڑھنے کی پوزیشن میں مداخلت کیے بغیر ایک تازہ شکل دیتا ہے۔

مرحلہ 7: آف لائن اور غلطی کی حالت

آف لائن سپورٹ فیڈز کی دو تقاضے ہیں: خیال یہ ہے کہ جب کوئی کنکشن نہ ہو تو مفید مواد کو ظاہر کیا جائے، اور کنکشن کے دوبارہ شروع ہونے پر تعاملات (پسند، تبصرے) کو قطار میں کھڑا کیا جائے۔

کیش شدہ مواد کو ظاہر کرنے کے لیے، سٹوریج پیٹرن اسے صاف طور پر ہینڈل کرتا ہے۔

// feed_repository.dart

Future> getFeed({String? cursor}) async {
  try {
    final page = await _remoteSource.getFeedPage(cursor: cursor);
    await _localSource.cachePosts(page.posts);
    return page.posts;
  } on DioException catch (e) {
    if (e.type == DioExceptionType.connectionError) {
      // Network unavailable — return cache
      final cached = await _localSource.getCachedPosts();
      if (cached.isNotEmpty) return cached;
    }
    rethrow;
  }
}

تعاملات کو آف لائن قطار میں لگانے کے لیے، مقامی اسٹوریج میں ایک سادہ زیر التواء ٹاسک قطار کو برقرار رکھیں۔

@freezed
class PendingAction with _$PendingAction {
  const factory PendingAction.like({
    required String postId,
    required bool isLike,
    required DateTime queuedAt,
  }) = PendingLike;

  const factory PendingAction.comment({
    required String postId,
    required String content,
    required DateTime queuedAt,
  }) = PendingComment;
}

جب کوئی کنکشن واپس آتا ہے (بذریعہ پتہ چلا: connectivity_plus)، قطار کو خالی کرنا اور ہر کام کو ترتیب سے انجام دینا۔ اگر دوبارہ کوشش کرنے کے بعد آپریشن ناکام ہوجاتا ہے، تو یہ صارف کو دکھایا جاتا ہے۔ اسے خاموشی سے نہ چھوڑیں۔

مرحلہ 8: کارکردگی کے تحفظات

فیڈ کسی بھی ایپ میں کارکردگی کے لحاظ سے سب سے زیادہ حساس اسکرینوں میں سے ایک ہے۔ کچھ طرز عمل ایسے ہیں جن پر بات نہیں کی جا سکتی۔

سب سے پہلے ListView.builderمطلقیت ListView اور children انوینٹری بلڈر صرف وہی پیش کرتا ہے جو فی الحال اسکرین پر ہے۔ کوئی راستہ نہیں children فہرست تمام اشیاء کو ایک ساتھ پیش کرتی ہے (جو 200+ پوسٹس کی فیڈز کے لیے تباہ کن ہو سکتی ہے)۔

دوسرا، برقرار رکھنا PostCard تعمیر کا طریقہ سستا ہے۔ ہر بار جب پوسٹ کارڈ دوبارہ بنایا جاتا ہے، تو پیمانے کے لحاظ سے یہ مہنگا ہو جاتا ہے۔ استعمال کریں const جہاں بھی ممکن ہو تعمیر کنندگان بنائیں۔ اگر صرف لائکس کی تعداد میں تبدیلی آتی ہے تو پورے کارڈ کو دوبارہ نہ لکھیں۔ لائک بٹن کو اس کے اپنے ریور پوڈ صارف میں الگ کریں۔

// Bad — whole PostCard rebuilds when like changes
class PostCard extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final post = ref.watch(feedNotifierProvider)
        .valueOrNull
        ?.firstWhere((p) => p.id == postId);
    // ...
  }
}

// Good — only LikeButton rebuilds
class LikeButton extends ConsumerWidget {
  final String postId;
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final post = ref.watch(
      feedNotifierProvider.select(
        (state) => state.valueOrNull?.firstWhere((p) => p.id == postId),
      ),
    );
    // Only rebuilds when this specific post's like state changes
  }
}

تیسرا، ہم نیٹ ورک کی تصاویر کو فعال طور پر کیش کرتے ہیں۔ استعمال کریں cached_network_image میموری کیش کی حدود ہیں۔ اوتار اور پوسٹ امیجز پر مشتمل فیڈز میں، غیر محفوظ شدہ نیٹ ورک کی تصاویر جنک کی سب سے بڑی وجہ ہیں۔

آخر میں، اسکرین کے باہر ہونے پر ہم WebSocket کنکشن کو حذف کر دیتے ہیں۔ ریئل ٹائم کنکشن برقرار نہ رکھیں کیونکہ صارفین جگہ جگہ منتقل ہوتے ہیں۔ Riverford ref.onDispose یہ آسان ہے، لیکن یاد کرنا آسان ہے۔

6. تیاری کے لیے دیگر سوالات

سماجی فیڈز تعمیر کے زیادہ تر مشکل علاقوں کا احاطہ کرتی ہیں۔ ان اضافی سوالات کے ساتھ اپنی تیاری مکمل کریں:

فن تعمیر اور ساخت:

• آپ 10 انجینئرز کی ٹیم کے لیے بڑے پیمانے پر فلٹر ایپ کی تشکیل کیسے کریں گے؟

• آپ دو افعال کے درمیان مشترکہ حالت کو کیسے ہینڈل کرتے ہیں جو ایک دوسرے کے بارے میں نہیں جانتے ہیں؟

• براہ کرم میری رہنمائی کریں کہ آف لائن پہلی ایپ کی ڈیٹا لیئر کو کیسے ڈیزائن کیا جائے۔

ریاستی انتظام:

• آرکیٹیکچرل نقطہ نظر کے ساتھ ساتھ API کے فرق سے Riverpod، Block، اور Redux کا موازنہ کریں۔

• صارف کے لاگ آؤٹ ہونے کے بعد میں ریاست کو سیشنوں کے درمیان لیک ہونے سے کیسے روک سکتا ہوں؟

نیٹ ورکنگ اور ڈیٹا:

کارکردگی:

• اسکرین پر 10,000 آئٹمز ہیں۔ میں ہکلائے بغیر کیسے رینڈر کروں؟

• میں ایسی فیڈ کے لیے امیج لوڈنگ سسٹم کیسے ڈیزائن کروں جس میں میڈیا کی مخلوط قسمیں ہوں؟

ملٹی پلیٹ فارم:

ان میں سے ہر ایک کے لیے ایک ہی فریم ورک کا استعمال کریں۔ یعنی، اپنی رکاوٹوں کو واضح کریں، اپنے ڈیٹا ماڈل کی وضاحت کریں، اپنی تہوں کو نام دیں، واضح طور پر مشکل مسائل کو حل کریں، اور خرابی کے حالات کو حل کریں۔

7. اہم نکات

سسٹم ڈیزائن کوئی بیک اینڈ ڈسپلن نہیں ہے جس سے فلٹر انجینئر مستثنیٰ ہیں۔ یہ سافٹ ویئر کے بارے میں سوچنے کا ایک طریقہ ہے جو ناگزیر ہو جاتا ہے کیونکہ ایپس زیادہ پیچیدہ ہوتی جاتی ہیں، ٹیمیں بڑی ہوتی ہیں، اور AI ایجنٹس ترقیاتی ورک فلو کا حصہ بن جاتے ہیں۔

سماجی فیڈ کا منظر نامہ پانچ اصولوں کی وضاحت کرتا ہے جو تمام فرنٹ اینڈ سسٹم ڈیزائن کے مسائل پر لاگو ہوتے ہیں:

1. پرت کی حدود بوجھ برداشت کرنے والی ہیں۔

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

2. ڈیٹا ماڈل ہر چیز کو اپنی جگہ پر رکھتا ہے۔

ماڈل کے ذریعے کیے گئے فیصلے، جیسے کرسر پر مبنی صفحہ بندی؛ isLikedByMe arrays کے بجائے integer counts) کو تمام تہوں کے ذریعے پھیلایا جاتا ہے۔ کسی اور چیز کو ڈیزائن کرنے سے پہلے فوراً ماڈل حاصل کریں۔

3. امید پرست UI ایک UX معاہدہ ہے، نہ کہ صرف ایک نمونہ۔

جب آپ ایک پرامید اپ ڈیٹ کا اطلاق کرتے ہیں، تو آپ اپنے صارفین سے وعدہ کر رہے ہوتے ہیں۔ جانیں کہ یہ عزم کب مناسب ہے (سماجی تعاملات) اور کب نہیں (مالی لین دین)۔

4. ریئل ٹائم ایک فن تعمیر کا مسئلہ ہے، فیچر نہیں۔

WebSocket کنکشنز مستقل وسائل ہیں جن کا نظم ہونا ضروری ہے، ضرورت پڑنے پر جڑنا، نہ ہونے پر منقطع ہونا، اور ناکام ہونے پر دوبارہ جڑنا۔ اسے ایک بنیادی ڈھانچے کے طور پر تعمیر کریں، نہ کہ کسی ایک اسکرین کے حصے کے طور پر۔

5. آف لائن بہترین ہے۔

یہ کوئی انتہائی معاملہ نہیں ہے، اور نہ ہی یہ "اچھا ہونا” ہے۔ ناقابل بھروسہ کنیکٹیویٹی والی مارکیٹوں میں، بشمول دنیا کی سب سے تیزی سے ترقی کرنے والی بہت سی موبائل مارکیٹیں، ایک ایسی ایپ جو نیٹ ورک کے بند ہونے پر کچھ نہیں دکھاتی ہے وہ ٹوٹی ہوئی ایپ ہے۔

انجینئرز جو ان اصولوں کو سمجھتے ہیں اور انٹرویو کے دباؤ میں بلند آواز میں ان کی وضاحت کر سکتے ہیں ان کی خدمات لاکھوں لوگوں کے زیر استعمال نظام بنانے کے لیے رکھی جاتی ہیں۔