JSON-RPC؟ مشکل REST لیں۔

مجھے یقین ہے کہ سرخی نے ایک صحت مند ردعمل کا سبب بنایا - "اچھا، یہ دوبارہ شروع ہو گیا ہے..." لیکن مجھے 5-10 منٹ کے لیے آپ کی توجہ حاصل کرنے دیں، اور میں آپ کی توقعات کو مایوس نہ کرنے کی کوشش کروں گا۔

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

RPC کیا ہے اس کے بارے میں واضح ہونے کے لیے، میں معیار پر غور کرنے کی تجویز کرتا ہوں۔ JSON-RPC 2.0. REST کے ساتھ کوئی وضاحت نہیں ہے۔ اور ایسا نہیں ہونا چاہیے۔ ہر وہ چیز جو آپ کو REST کے بارے میں جاننے کی ضرورت ہے - اس سے الگ نہیں کیا جا سکتا HTTP.

RPC کی درخواستیں تیز اور زیادہ موثر ہیں کیونکہ وہ آپ کو بیچ کی درخواستیں کرنے کی اجازت دیتی ہیں۔

نقطہ یہ ہے کہ RPC میں آپ ایک درخواست میں ایک ساتھ کئی طریقہ کار کو کال کر سکتے ہیں۔ مثال کے طور پر، ایک صارف بنائیں، اس میں ایک اوتار شامل کریں اور اسی درخواست میں، اسے کچھ عنوانات پر سبسکرائب کریں۔ بس ایک درخواست، اور کتنا فائدہ!

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

نوٹ کریں کہ REST کے معاملے میں پہلی درخواست کو صارف کی شناخت واپس کرنی ہوگی تاکہ بعد میں درخواستیں کی جائیں۔ جس کا مجموعی نتیجہ پر بھی منفی اثر پڑتا ہے۔

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

اسی منظر نامے کے تحت انفراسٹرکچر سرگرمی کے چینلز کو سبز رنگ میں نشان زد کیا گیا ہے۔ نوٹ کریں کہ RPC اب کیسا برتاؤ کرتا ہے۔ درخواست میں بیلنسر سے پسدید تک صرف ایک ٹانگ پر انفراسٹرکچر کا استعمال کیا گیا ہے۔ اگرچہ REST اب بھی پہلی درخواست میں کھو دیتا ہے، لیکن یہ پورے انفراسٹرکچر کا استعمال کرتے ہوئے ضائع ہونے والے وقت کو پورا کرتا ہے۔

اسکرپٹ میں افزودگی کے لیے دو نہیں بلکہ پانچ یا دس درخواستیں داخل کرنا کافی ہے اور اس سوال کا جواب "اب کون جیتتا ہے؟" غیر واضح ہو جاتا ہے.

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

دیکھیں کہ کس طرح زیادہ بوجھ کے مطالبات کو پورا کرنے کے لیے RPC کے بنیادی ڈھانچے میں نمایاں بہتری آئی ہے۔ بات یہ ہے کہ REST RPC کے برعکس HTTP پروٹوکول کی پوری طاقت استعمال کرتا ہے۔ اوپر دیے گئے خاکے میں، اس طاقت کا ادراک درخواست کے طریقہ کار سے ہوتا ہے - GET۔

HTTP طریقوں میں، دوسری چیزوں کے علاوہ، کیشنگ کی حکمت عملی ہوتی ہے۔ آپ انہیں دستاویزات میں تلاش کر سکتے ہیں۔ HTTP. (ذرائع).

نتیجتاً، RPC انفراسٹرکچر کیچز کو مؤثر طریقے سے استعمال کرنے سے قاصر ہے۔ یہ سافٹ ویئر کیشز کو "درآمد" کرنے کی ضرورت کا باعث بنتا ہے۔ خاکہ Redis کو اس کردار میں دکھاتا ہے۔ سافٹ ویئر کیش، بدلے میں، ڈویلپر کو کوڈ کی ایک اضافی پرت اور فن تعمیر میں نمایاں تبدیلیاں شامل کرنے کی ضرورت ہوتی ہے۔

آئیے اب گنتے ہیں REST اور RPC نے زیر غور انفراسٹرکچر میں کتنی درخواستوں کو "جنم" دیا؟

درخواستوں
ان باکس
پسدید کو
DBMS کو
نرم کیشے میں (Redis)
TOTAL

باقی
1 / 32 *
1
1
0
3 / 35

آر پی سی
32
32
1
31
96

[*] بہترین صورت میں (اگر مقامی کیش استعمال کیا جاتا ہے) 1 درخواست (ایک!)، بدترین صورت میں 32 آنے والی درخواستیں۔

پہلی اسکیم کے مقابلے میں، فرق حیران کن ہے۔ اب REST کا فائدہ واضح ہو جاتا ہے۔ لیکن میں وہاں نہ رکنے کا مشورہ دیتا ہوں۔ ترقی یافتہ بنیادی ڈھانچے میں ایک CDN شامل ہے۔ اکثر یہ DDoS اور DoS حملوں کا مقابلہ کرنے کے مسئلے کو بھی حل کرتا ہے۔ ہم حاصل:

یہ وہ جگہ ہے جہاں RPC کے لئے چیزیں واقعی خراب ہوجاتی ہیں۔ RPC کام کا بوجھ CDN کو سونپنے کے قابل نہیں ہے۔ ہم حملوں کا مقابلہ کرنے کے لیے صرف نظام پر انحصار کر سکتے ہیں۔

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

تو یہ افسانہ کیوں ہے کہ بیچ کی درخواستیں (RPC) اتنی تیز ہیں؟ ذاتی طور پر، مجھے ایسا لگتا ہے کہ زیادہ تر منصوبے ترقی کی اس سطح تک نہیں پہنچ پاتے جہاں REST اپنی طاقت دکھانے کے قابل ہو۔ اس کے علاوہ، چھوٹے منصوبوں میں، وہ اپنی کمزوریوں کو ظاہر کرنے کے لئے زیادہ تیار ہے.

REST یا RPC کا انتخاب کسی پروجیکٹ میں کسی فرد کا اپنی مرضی کا انتخاب نہیں ہے۔ اس انتخاب کو پروجیکٹ کی ضروریات کو پورا کرنا ہوگا۔ اگر کوئی پروجیکٹ ہر وہ چیز نچوڑ سکتا ہے جو وہ واقعی REST سے باہر کر سکتا ہے، اور اسے واقعی اس کی ضرورت ہے، تو REST ایک بہترین انتخاب ہوگا۔

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

RPC کی درخواستیں زیادہ قابل اعتماد ہیں کیونکہ وہ ایک ہی لین دین کے اندر بیچ کی درخواستوں کو انجام دے سکتی ہیں۔

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

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

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

آئیے خاکے کو دیکھتے ہیں۔ یہ اعلی دستیابی کے عناصر کے ساتھ ایک بنیادی ڈھانچہ پیش کرتا ہے۔ SMS گیٹ ویز کے ساتھ دو آزاد مواصلاتی چینلز ہیں۔ لیکن... ہم کیا دیکھتے ہیں؟ ایس ایم ایس بھیجتے وقت، ایک خرابی 503 ہوتی ہے - سروس عارضی طور پر دستیاب نہیں ہے۔ کیونکہ ایس ایم ایس بھیجنا ایک بیچ کی درخواست میں پیک کیا جاتا ہے، پھر پوری درخواست کو رول بیک کرنا ضروری ہے۔ DBMS میں کارروائیاں منسوخ کر دی گئی ہیں۔ کلائنٹ کو ایک غلطی موصول ہوتی ہے۔

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

ٹھیک ہے، آئیے تصور کریں کہ ہم نے خود کو دبایا ہے (!) اور آپشن کے ذریعے سوچا کہ جب درخواست کو جزوی طور پر کامیابی سے مکمل کیا جا سکتا ہے۔ اور ہم کچھ وقت کے وقفے کے بعد باقی کو دوبارہ مکمل کرنے کی کوشش کریں گے (کون سا؟ کیا سامنے والا فیصلہ کرتا ہے؟)۔ لیکن لاٹری وہی رہی۔ SMS بھیجنے کی درخواست کے دوبارہ ناکام ہونے کا 50/50 امکان ہے۔

متفق ہوں، کلائنٹ کی طرف سے، سروس اتنی قابل اعتماد نہیں لگتی جتنی ہم چاہتے ہیں... REST کا کیا ہوگا؟

REST دوبارہ HTTP کا جادو استعمال کرتا ہے، لیکن اب جوابی کوڈز کے ساتھ۔ جب ایس ایم ایس گیٹ وے پر کوئی ایرر 503 ہوتا ہے تو بیک اینڈ اس ایرر کو بیلنسر پر براڈکاسٹ کرتا ہے۔ بیلنسر کو یہ غلطی موصول ہوتی ہے اور کلائنٹ کے ساتھ کنکشن کو توڑے بغیر، درخواست کو دوسرے نوڈ کو بھیجتا ہے، جو درخواست پر کامیابی سے کارروائی کرتا ہے۔ وہ. کلائنٹ کو متوقع نتیجہ ملتا ہے، اور انفراسٹرکچر اس کے "انتہائی قابل رسائی" کے اعلی عنوان کی تصدیق کرتا ہے۔ صارف خوش ہے۔

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

جیسا کہ ہم دیکھ سکتے ہیں، JSON-RPC کی وشوسنییتا حد سے زیادہ ہے۔ درحقیقت، ڈیٹا بیس میں مستقل مزاجی کو منظم کرنا آسان ہے۔ لیکن قربانی، اس صورت میں، مجموعی طور پر نظام کی وشوسنییتا ہوگی۔

نتیجہ بڑی حد تک پچھلے سے ملتا جلتا ہے۔ جب بنیادی ڈھانچہ آسان ہے، JSON-RPC کی واضحیت یقینی طور پر ایک پلس ہے۔ اگر پروجیکٹ میں زیادہ بوجھ کے ساتھ اعلی دستیابی شامل ہے، REST زیادہ درست لگتا ہے، اگرچہ زیادہ پیچیدہ، حل ہے۔

REST میں داخلے کی حد کم ہے۔

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

تو کیوں بہت سے لوگ سوچتے ہیں کہ REST آسان ہو جائے گا؟ میری ذاتی رائے یہ ہے کہ یہ ظاہری سادگی خود REST سے ظاہر ہوتی ہے۔ وہ. REST کوئی پروٹوکول نہیں بلکہ ایک تصور ہے... REST کا کوئی معیار نہیں ہے، کچھ رہنما اصول ہیں... REST HTTP سے زیادہ پیچیدہ نہیں ہے۔ ظاہری آزادی اور انارکی "آزاد فنکاروں" کو راغب کرتی ہے۔

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

لیکن RPC کے بارے میں - آپ کر سکتے ہیں۔ اس کی تصریح لینا کافی ہے۔ تو آپ کو ضرورت ہے؟ بیوقوف JSON-RPC? یا یہ اب بھی مشکل REST ہے؟ تم فیصلہ کرو.

مجھے پوری امید ہے کہ میں نے آپ کا وقت ضائع نہیں کیا ہے۔

ماخذ: www.habr.com