𝗛𝗼𝘄 𝗜 𝗕𝘂𝗶𝗹𝘁 𝗮 𝗦𝗲𝘁 𝗜𝘁 𝗮𝗻𝗱 𝗙𝗼𝗿𝗴𝗲𝘁 𝗜𝘁 𝗦𝘆𝗻𝗰 𝗦𝘆𝘀𝘁𝗲𝗺
مصنوعات کی قیمتیں کئی جگہوں پر تبدیل ہوتی ہیں۔ وہ ایڈمن پینل میں، بلک امپورٹس کے ذریعے، یا API webhooks کے ذریعے تبدیل ہوتی ہیں۔
اگر آپ ان تبدیلیوں کو کسی بیرونی مارکیٹ پلیس کے ساتھ سنک (sync) کرنا چاہتے ہیں، تو آپ کو ایک مسئلے کا سامنا کرنا پڑتا ہے۔ ہر ایک کوڈ پاتھ میں سنک کال شامل کرنا ایک غلطی ہے۔ آپ کوئی ایک بھول جائیں گے۔ آپ کسی ایک کو خراب کر دیں گے۔ دیکھ بھال (maintenance) ایک ڈراؤنا خواب بن جائے گی۔
Django signals اس کا حل پیش کرتے ہیں۔ آپ ماڈل کے save event کے ساتھ جڑ جاتے ہیں۔ یہ ہر تبدیلی کو ایک ہی جگہ پر پکڑ لیتا ہے۔
لیکن signals میں ایک خامی ہے۔ اگر آپ ایک ساتھ 100 قیمتیں اپ ڈیٹ کرتے ہیں، تو signal 100 بار فائر ہوتا ہے۔ اس سے 100 API calls ٹرگر ہوتی ہیں۔ آپ rate limits کا شکار ہو جائیں گے یا وسائل ضائع کریں گے۔
میں اسے ٹھیک کرنے کے لیے تین حصوں پر مشتمل ایک پیٹرن استعمال کرتا ہوں:
• ایک signal handler جو فوری کارروائی کرنے کے بجائے IDs کو جمع کرتا ہے۔
• ڈپلیکیٹس کو ختم کرنے کے لیے ایک per-thread set۔
• سب کچھ ایک ساتھ پروسیس کرنے کے لیے transaction.on_commit کا استعمال کرتے ہوئے ایک flush callback۔
یہ کیسے کام کرتا ہے، یہاں دیکھیں:
threading.local()کا استعمال کریں گلوبل ویری ایبل (global variable) استعمال نہ کریں۔ گلوبل ویری ایبلز تمام requests کے درمیان اسٹیٹ شیئر کرتے ہیں۔ اس سے ڈیٹا لیک ہونے کا خطرہ ہوتا ہے۔threading.local()ڈیٹا کو ایک ہی تھریڈ تک محدود رکھتا ہے۔ریکارڈ کریں، کارروائی نہ کریں Signal handler محض پروڈکٹ ID کو ایک set میں شامل کر دیتا ہے۔ پھر یہ Django کو بتاتا ہے کہ flush function صرف اس وقت چلائے جب ڈیٹا بیس ٹرانزیکشن (transaction) کامیاب ہو جائے۔ یہ اس ڈیٹا کو سنک کرنے سے روکتا ہے جو محفوظ ہونے میں ناکام رہا ہو۔
کام کو بیچ (batch) میں تقسیم کریں جب ٹرانزیکشن کمٹ (commit) ہوتی ہے، تو flush function چلتا ہے۔ یہ set کی کاپی بناتا ہے اور اسے صاف کر دیتا ہے۔ پھر یہ تمام IDs کی فہرست سروس لیئر (service layer) کو بھیج دیتا ہے۔
سروس لیئر تمام مصنوعات کو حاصل کرنے کے لیے ایک ہی بلک کوئری (bulk query) کرتی ہے۔ یہ انہیں اسٹور کے لحاظ سے گروپ کرتی ہے۔ آخر میں، یہ ہر اسٹور کے لیے Celery کو ایک ہی ٹاسک بھیجتی ہے۔
اس کے فوائد واضح ہیں:
- ڈپلیکیشن کا خاتمہ خودکار ہے۔ ایک set یہ کام آپ کے لیے کر دیتا ہے۔
- ٹرانزیکشن کی حفاظت پہلے سے موجود ہے۔ آپ کبھی بھی رول بیک (rolled-back) شدہ ڈیٹا کو سنک نہیں کرتے۔
- کارکردگی (efficiency) زیادہ ہے۔ آپ N+1 query کے مسائل سے بچ جاتے ہیں۔
- قابل اعتماد ہے۔ اگر API فیل ہو جائے تو Celery خودکار طور پر دوبارہ کوشش (retries) کرتا ہے۔
آپ سسٹم کو ایک بار بناتے ہیں۔ بعد میں آپ جو بھی نیا فیچر شامل کرتے ہیں، وہ خود بخود سنک سسٹم کے ساتھ کام کرتا ہے۔
آپ Django میں بیرونی API syncs کو کیسے ہینڈل کرتے ہیں؟ کیا آپ signals استعمال کرتے ہیں یا کوئی اور پیٹرن؟
Source: https://dev.to/acel/how-i-built-a-set-it-and-forget-it-sync-system-with-django-signals-2ld7