انجینئرنگ ٹیمیں اب بھی اس بات پر بحث کرنے میں پوری دوپہریں ضائع کر دیتی ہیں کہ کیا REST ختم ہو چکا ہے یا کیا gRPC نے باقی سب کو غیر ضروری بنا دیا ہے۔ یہ بحث اصل مقصد سے ہٹ کر ہے۔ آپ بہترین پروٹوکول کا انتخاب نہیں کر رہے ہوتے، بلکہ آپ صحیح باؤنڈری (boundary) کا انتخاب کر رہے ہوتے ہیں۔ ایک ایسا پروٹوکول جو آپ کے Kubernetes کلسٹر کے اندر بہترین کام کرے گا، وہ اس وقت دم توڑ دے گا جب آپ اسے ہزاروں بیرونی ڈویلپرز کے حوالے کریں گے۔ ایک ایسا پروٹوکول جو آپ کی موبائل ایپ کی قیمتی بینڈوتھ بچاتا ہے، وہ آپ کے انفراسٹرکچر کو دیوالیہ کر دے گا اگر آپ اسے بلا روک ٹوک عوامی کوئریز (public queries) کے لیے کھول دیں۔ اگر آپ اس فیصلے کو ٹیکنالوجی کے مقبولیت کے مقابلے کی طرح لیں گے، تو آپ ایسا آرکیٹیکچرل ڈیٹ (architectural debt) پیدا کر دیں گے جو آپ کی ٹیم کے موجودہ ہر رکن کے جانے کے بعد بھی برقرار رہے گا۔

The Boundary Principle

آرکیٹیکچر سمجھوتوں (trade-offs) کے بارے میں ہے، کسی فاتح کے بارے میں نہیں۔ صحیح سوال کبھی یہ نہیں ہوتا کہ "کون سا تیز ترین ہے؟" یا "کون سا نیا ہے؟" بلکہ یہ ہے کہ "دوسری طرف کون ہے، اور ان کا کنٹرول کتنا ہے؟" پروٹوکولز باؤنڈری آبجیکٹس ہیں۔ غلط انتخاب صرف آپ کی رفتار کم نہیں کرتا، بلکہ یہ برسوں کے لیے آپ کے سسٹم میں غلطیوں کو مستقل طور پر شامل کر دیتا ہے۔

Public APIs: REST Is Not Boring, It Is Responsible

جب آپ کا صارف ایک بیرونی ڈویلپر ہو جسے آپ کبھی نہیں ملے، تو آپ کی API محض ایک انٹرفیس نہیں بلکہ ایک پروڈکٹ ہے۔ وہ ڈویلپر رات کے دو بجے صرف curl اور Postman collection کے ذریعے ڈی بگنگ کر رہا ہوتا ہے۔ اگر اسے اپنی پہلی کامیاب کال سے پہلے کوئی کسٹم کلائنٹ لائبریری انسٹال کرنی پڑے یا کوئی اسکیمہ لینگویج سیکھنی پڑے، تو آپ اسے پہلے ہی کھو چکے ہیں۔

REST یہاں اس لیے زندہ ہے کیونکہ یہ خود ویب ہے۔ HTTP میتھڈز، اسٹیٹس کوڈز، اور JSON ایک مشترکہ زبان ہیں۔ کیشنگ (Caching) کوئی بعد کا خیال نہیں ہے؛ یہ ایک ایسا انفراسٹرکچر ہے جو پہلے سے موجود ہے۔ براؤزرز، CDNs، اور ایج کیشز Cache-Control ہیڈرز اور ETag ویلیڈیشن کو قدرتی طور پر سمجھتے ہیں۔ آپ ایک اسٹینڈرڈ CDN کے پیچھے REST API رکھ سکتے ہیں اور کیشنگ لاجک کی ایک بھی لائن لکھے بغیر فوری طور پر بینڈوتھ کی بچت حاصل کر سکتے ہیں۔ یہ اس وقت اہمیت رکھتا ہے جب پبلک ٹریفک غیر متوقع ہو اور آپ اپنے کلاؤڈ سے نکلنے والے ہر گیگا بائٹ کے پیسے دے رہے ہوں۔

اس کے برعکس، GraphQL پبلک باؤنڈری پر ایک بھاری ٹیک (tax) لاتا ہے۔ پبلک GraphQL اینڈ پوائنٹس کو کوئری کاسٹ اینالیسس (query cost analysis)، ڈیپتھ لمٹنگ (depth limiting)، اور کمپلیکسٹی اسکورنگ کی ضرورت ہوتی ہے تاکہ کوئی ایک لاپرواہ یا بدنیتی پر مبنی کوئری آپ کے ڈیٹا بیس کو تباہ نہ کر دے۔ آپ صرف ایک API نہیں بھیج رہے؛ آپ ایک کوئری ایگزیکیوشن انجن، ریٹ لمٹنگ اسٹریٹجی، اور کمپیوٹ بلنگ ماڈل بنا رہے ہیں۔ جب تک آپ کے پاس بڑے پلیٹ فارمز جیسی آپریشنل طاقت نہ ہو، پبلک سطح کے لیے یہ اضافی بوجھ (overhead) غیر ذمہ دارانہ ہے۔ REST ڈیفالٹ کے طور پر حفاظتی حدود (guardrails) مقرر کرتا ہے۔ ہر اینڈ پوائنٹ ایک کام کرتا ہے۔ صارفین صرف وہی حاصل کرتے ہیں جو آپ پیش کرتے ہیں، نہ کہ وہ جو وہ سوچ سکتے ہیں۔

Internal Services: Own the Whole Pipe

اپنی تنظیم کے اندر، گفتگو بدل جاتی ہے۔ آپ کلائنٹ اور سرور دونوں کو کنٹرول کرتے ہیں۔ آپ کال چین میں موجود ہر سروس کے لیے ٹیکنالوجی اسٹیک کا فیصلہ کر سکتے ہیں۔ یہ وہ جگہ ہے جہاں gRPC اپنی اہمیت ثابت کرتا ہے۔

سب سے پہلے، JSON کو مقدس سمجھنا چھوڑ دیں۔ Protocol Buffers، JSON کے مقابلے میں تقریباً تین گنا زیادہ تیزی سے سیریلائز (serialize) ہوتے ہیں۔ پی لوڈز (payloads) چھوٹے ہوتے ہیں کیونکہ فارمیٹ بائنری ہوتا ہے۔ ایک مصروف انٹرنل نیٹ ورک پر، وہ ملی سیکنڈز اور میگا بائٹس اصل رقم میں بدل جاتے ہیں اور لیٹینسی (latency) کو کم کرتے ہیں۔ اس سے بھی اہم بات یہ ہے کہ Protobuf آپ کو ایک سخت معاہدہ (strict contract) دیتا ہے۔ جب آپ کسی فیلڈ کی قسم تبدیل کرتے ہیں یا میسج کا نام بدلتے ہیں، تو خرابی کمپائل ٹائم پر ہی سامنے آ جاتی ہے، نہ کہ رات کے تین بجے پروڈکشن میں جب کوئی ڈاؤن اسٹریم سروس پارس ایکسیپشنز (parse exceptions) پھینکنا شروع کر دیتی ہے۔

gRPC، HTTP/2 پر چلتا ہے، اس لیے آپ کو ہیڈر کمپریشن، ملٹی پلیکسڈ اسٹریمز، اور حقیقی اسٹریمنگ کے فوائد ملتے ہیں۔ اگر آپ سروسز کے درمیان ہائی تھرو پٹ ایونٹس منتقل کر رہے ہیں یا ریئل ٹائم اپ ڈیٹس بھیج رہے ہیں، تو سرور سائیڈ اور بائی ڈائریکشنل اسٹریمنگ قدرتی فیچرز ہیں، نہ کہ کسی ریکوئسٹ-رسپانس فریم ورک پر زبردستی لگائے گئے ورک اراؤنڈز۔

ایک مشکل رکاوٹ ہے: gRPC کو براہ راست براؤزر کی طرف نہ موڑیں۔ براؤزر نیٹ ورکنگ ماڈلز اس طرح HTTP/2 کو نہیں سمجھتے جیسے gRPC توقع کرتا ہے۔ آپ کو براؤزر کو بیک اینڈ سے بات کروانے کے لیے اپنے اسٹیک پر grpc-web اور Envoy جیسا پراکسی لگانا پڑے گا۔ یہ کوئی بگ نہیں ہے؛ یہ ایک باؤنڈری سگنل ہے۔ gRPC کو اپنے فائر وال کے پیچھے، ایک دوسرے پر بھروسہ کرنے والی سروسز کے درمیان رکھیں، اور اس کی ڈی بگنگ کی پیچیدگی کو رفتار کی قیمت کے طور پر قبول کریں۔ بائنری پی لوڈز کو لاگ فائل میں دیکھنا اتنا آسان نہیں ہوتا جتنا JSON کو ہوتا ہے۔

Complex UIs and Mobile: GraphQL's Niche

جدید موبائل اسکرینز مختلف حصوں کا مجموعہ ہوتی ہیں۔ ایک ویو کو شاید یوزر پروفائل کی ضرورت ہو،