API انٹیگریشن پیٹرنز: انٹرپرائز آرکیٹیکچر بہترین پریکٹسز

جدید کاروبار انضمام پر چلتے ہیں۔ اوسط مڈ مارکیٹ کمپنی 110+ سافٹ ویئر ایپلی کیشنز استعمال کرتی ہے، اور ہر ایک کو قدر فراہم کرنے کے لیے دوسروں کے ساتھ ڈیٹا کا تبادلہ کرنے کی ضرورت ہوتی ہے۔ آپ کے ای کامرس پلیٹ فارم کو آپ کے ERP سے بات کرنے کی ضرورت ہے۔ آپ کے ERP کو ​​آپ کے گودام مینجمنٹ سسٹم سے بات کرنے کی ضرورت ہے۔ آپ کی مارکیٹنگ آٹومیشن کو آپ کے CRM سے کسٹمر ڈیٹا کی ضرورت ہے۔ آپ کے اکاؤنٹنگ سسٹم کو آپ کے ادائیگی کے پروسیسر سے لین دین کے ڈیٹا کی ضرورت ہے۔ ہر کنکشن ایک انضمام ہے، اور ہر انضمام ایک API گفتگو ہے۔

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

اہم ٹیک ویز

• بیرونی انضمام کے لیے REST غالب API سٹائل ہے، لیکن GraphQL اور gRPC ہر ایک مخصوص استعمال کے معاملات کو بہتر طریقے سے پیش کرتا ہے۔
• ایونٹ سے چلنے والا فن تعمیر (ویب ہکس، میسج کیو) سسٹم کو ڈیکپل کرتا ہے اور پولنگ کو ختم کرتا ہے، انضمام کی تاخیر کو منٹ سے سیکنڈ تک کم کرتا ہے۔
• ساگا پیٹرن تقسیم شدہ تالے کے بغیر متعدد خدمات میں تقسیم شدہ لین دین کا انتظام کرتا ہے - آرڈر کی تکمیل جیسے کاموں کے لیے ضروری ہے جو ERP، ادائیگی اور گودام کے نظام پر محیط ہے۔
• API گیٹ ویز کراس کٹنگ خدشات کو مرکزی بناتے ہیں (تصدیق، شرح کی حد بندی، نگرانی) اور فی انٹیگریشن اوور ہیڈ کو 40-60% تک کم کرتے ہیں۔
• شرح کو محدود کرنا صرف شائستگی نہیں ہے - یہ آپ کے سسٹمز اور ان سسٹمز دونوں کی حفاظت کرتا ہے جن کے ساتھ آپ انضمام کرتے ہیں جھڑپوں کی ناکامیوں سے
• API ورژن بنانے کی حکمت عملی آپ کے پہلے صارف سے پہلے طے کی جانی چاہیے، تبدیلیوں کو توڑنے کے بعد بات چیت کو مجبور کرنے کے بعد نہیں۔
• انضمام کی پرت زیادہ تر انٹرپرائز آرکیٹیکچرز کا سب سے نازک حصہ ہے — نگرانی، غلطی سے نمٹنے، اور پہلے دن سے منطق کی دوبارہ کوشش میں سرمایہ کاری کریں۔

---

جب آرام کرنا صحیح انتخاب ہے:

• بیرونی ڈویلپرز کے ذریعہ استعمال کردہ عوامی APIs
• کاروباری اداروں پر معیاری CRUD آپریشنز
• انضمام جہاں سادگی اور وسیع ٹولنگ سپورٹ اہم ہے۔
• APIs جو بہت سے مختلف کلائنٹس (ویب، موبائل، پارٹنرز) استعمال کریں گے۔

انٹرپرائز کے لیے باقی بہترین طریقے:

1. وسائل کے لیے اسم استعمال کریں، اعمال کے لیے HTTP طریقے: GET /orders/123 نہیں GET /getOrder?id=123
2. مسلسل جوابی شکل: ہمیشہ وہی لفافہ ڈھانچہ واپس کریں ({ data, meta, errors })
3. مجموعوں کے لیے صفحہ بندی: بڑے ڈیٹاسیٹس کے لیے کرسر پر مبنی صفحہ بندی (?cursor=abc123&limit=50) کا استعمال کریں، نہ کہ آفسیٹ پر مبنی (?page=5&per_page=50) جو کہ اعلی آفسیٹس پر سست ہوجاتا ہے۔
4. HATEOAS for Discoverability: جوابات میں متعلقہ وسائل کے لنکس شامل کریں ({ "order": { ..., "links": { "customer": "/customers/456", "invoices": "/orders/123/invoices" }}})
5. مسلسل ایرر فارمیٹ: مشین کے پڑھنے کے قابل کوڈز، انسانی پڑھنے کے قابل پیغامات، اور دستاویزات کے لنکس کے ساتھ ساختی غلطیوں کو لوٹائیں

گراف کیو ایل

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

جب گراف کیو ایل صحیح انتخاب ہے:

• موبائل ایپلیکیشنز جہاں بینڈوڈتھ محدود ہے۔
• فرنٹ اینڈ ایپلی کیشنز جن کو ایک درخواست میں متعدد متعلقہ اداروں سے لچکدار ڈیٹا کی ضرورت ہوتی ہے۔
• APIs جہاں مختلف صارفین کو ایک ہی ڈیٹا کے مختلف ذیلی سیٹوں کی ضرورت ہوتی ہے۔
• تیز فرنٹ اینڈ ڈیولپمنٹ جہاں API معاہدہ UI کو محدود نہیں کرنا چاہئے۔

جب گراف کیو ایل غلط انتخاب ہے:

• متوقع رسائی کے نمونوں کے ساتھ سادہ CRUD APIs
• سرور سے سرور انضمام جہاں ردعمل کی شکل طے کی گئی ہے۔
• APIs جن کو جارحانہ کیشنگ کی ضرورت ہے (REST کی URL پر مبنی کیشنگ آسان ہے)
• گراف کیو ایل کی مہارت کے بغیر ٹیمیں (سیکھنے کا وکر REST سے زیادہ تیز ہے)

گراف کیو ایل انٹرپرائز کے تحفظات:

• آتھورائزیشن کی پیچیدگی: فیلڈ لیول کی اجازت درکار ہے — ایک گاہک کو user { creditCardNumber } صرف اس لیے استفسار کرنے کے قابل نہیں ہونا چاہیے کیونکہ اسکیما اسے بے نقاب کرتا ہے۔
• سوال کی لاگت کا تجزیہ: گہرائی اور پیچیدگی کی حدود کے بغیر، ایک گراف کیو ایل سوال سرور کے بہت زیادہ وسائل استعمال کر سکتا ہے۔ استفسار کی لاگت کا تخمینہ لاگو کریں اور مہنگے سوالات کو مسترد کریں۔
• N+1 مسئلہ: سادہ گراف کیو ایل حل کرنے والے فی فیلڈ فی آئٹم کے لیے ایک ڈیٹا بیس استفسار تیار کرتے ہیں۔ بیچنگ کے لیے ڈیٹا لوڈر پیٹرن استعمال کریں۔
• کیچنگ: گراف کیو ایل کا واحد اختتامی نقطہ HTTP کیچنگ کو غیر موثر بنا دیتا ہے۔ ایپلیکیشن لیول کیشنگ (Redis) یا مستقل سوالات کا استعمال کریں۔

جی آر پی سی

gRPC اسکیما تعریف اور بائنری سیریلائزیشن کے لیے پروٹوکول بفرز کا استعمال کرتا ہے، نقل و حمل کے لیے HTTP/2 کے ساتھ۔ یہ اعلی حجم، کم تاخیر والی مواصلات کے لیے REST سے نمایاں طور پر تیز ہے۔

جب gRPC صحیح انتخاب ہے:

• مائیکرو سروسز آرکیٹیکچرز میں اندرونی سروس ٹو سروس مواصلات
• ہائی تھرو پٹ، کم تاخیر کے تقاضے (10,000+ درخواستیں/سیکنڈ)
• اسٹریمنگ ڈیٹا (ریئل ٹائم اپ ڈیٹس کے لیے دو طرفہ اسٹریمنگ)
• پولی گلوٹ ماحول جہاں خدمات مختلف زبانوں میں لکھی جاتی ہیں (gRPC ایک ہی پروٹو تعریف سے 10+ زبانوں کے لیے کلائنٹ کوڈ تیار کرتا ہے)

جب gRPC موزوں نہیں ہے:

• عوامی APIs (براؤزر سپورٹ محدود ہے، ٹولنگ کم قابل رسائی ہے)
• سادہ انضمام جہاں REST کی سادگی gRPC کی کارکردگی سے زیادہ ہے۔
• ایسے ماحول جہاں معیاری HTTP ٹولز (کرل، پوسٹ مین) کے ساتھ ڈیبگ کرنا ضروری ہے۔

موازنہ کا خلاصہ

---

واقعہ سے چلنے والا فن تعمیر

Request-response APIs (REST, GraphQL, gRPC) صارفین سے معلومات طلب کرنے کا تقاضا کرتے ہیں۔ واقعہ سے چلنے والا فن تعمیر اس کو الٹ دیتا ہے — پروڈیوسرز واقعات شائع کرتے ہیں جب ریاست میں تبدیلیاں رونما ہوتی ہیں، اور دلچسپی رکھنے والے صارفین ان واقعات پر ردعمل ظاہر کرتے ہیں۔ یہ بنیادی تبدیلی پولنگ کو ختم کرتی ہے، جوڑے کو کم کرتی ہے، اور سسٹمز میں ریئل ٹائم ڈیٹا کے بہاؤ کو قابل بناتی ہے۔

ویب ہکس

ویب ہکس ایونٹ پر مبنی انضمام کی سب سے آسان شکل ہیں۔ جب سسٹم A میں کوئی واقعہ پیش آتا ہے، تو یہ سسٹم B کے ذریعے رجسٹرڈ URL کو HTTP POST کی درخواست کرتا ہے۔

عام ای کامرس ویب ہک منظرنامے:

• پٹی آپ کی آرڈر مینجمنٹ سروس کو payment_intent.succeeded بھیجتی ہے۔
• Shopify تکمیل کی کارروائی کے لیے آپ کے ERP کو orders/create بھیجتا ہے۔
• Odoo آپ کے گودام مینجمنٹ سسٹم کو stock.move/confirmed بھیجتا ہے۔
• آپ کا CRM انوائس بنانے کے لیے آپ کے اکاؤنٹنگ سسٹم کو deal.won بھیجتا ہے۔

ویب ہُک کے بہترین طریقے:

1. ویب ہک کے دستخطوں کی تصدیق کریں: ہر ویب ہک فراہم کنندہ میں ایک دستخطی ہیڈر (HMAC-SHA256 ہیش) شامل ہوتا ہے۔ جعلی ویب ہکس کو روکنے کے لیے پروسیسنگ سے پہلے اس کی تصدیق کریں۔
2. فوری جواب دیں، بعد میں کارروائی کریں: فوری طور پر 200 واپس کریں، پھر ویب ہک پے لوڈ پر غیر مطابقت پذیر طریقے سے کارروائی کریں۔ طویل عرصے سے چلنے والی پروسیسنگ کا وقت ختم ہونے کا خطرہ ہے، اور بھیجنے والا دوبارہ کوشش کرے گا (ڈپلیکیٹس کی وجہ سے)
3. Idempotency: ویب ہکس متعدد بار ڈیلیور کیے جا سکتے ہیں (فراہم کنندہ نیٹ ورک کی ناکامی پر دوبارہ کوشش کرتا ہے)۔ اپنے ہینڈلرز کو کمزور ہونے کے لیے ڈیزائن کریں — ایک ہی ویب ہک کو دو بار پروسیس کرنے سے ڈپلیکیٹ ریکارڈ نہیں بننا چاہیے۔
4. دوبارہ ہینڈلنگ کی کوشش کریں: آنے والے ویب ہکس کو ان کی پروسیسنگ اسٹیٹس کے ساتھ اسٹور کریں۔ اگر پروسیسنگ ناکام ہو جاتی ہے، تو فراہم کنندہ کے دوبارہ کوشش کے شیڈول پر انحصار کرنے کے بجائے اپنا دوبارہ کوشش کرنے کا طریقہ کار نافذ کریں۔
5. ڈیڈ لیٹر قطار: زیادہ سے زیادہ کوششوں کے بعد، ناکام ویب ہکس کو خاموشی سے چھوڑنے کے بجائے دستی تحقیقات کے لیے ڈیڈ لیٹر کی قطار میں منتقل کریں۔

پیغام کی قطاریں۔

زیادہ والیوم ایونٹ کے بہاؤ اور گارنٹیڈ ڈیلیوری کی ضرورت والے منظرناموں کے لیے، پیغام کی قطاریں (RabbitMQ، Apache Kafka، AWS SQS/SNS، Google Pub/Sub) ایونٹ کی مضبوط تقسیم فراہم کرتی ہیں۔

** ویب ہکس پر پیغام کی قطاروں کا استعمال کب کرنا ہے:**

• اندرونی سروس سے سروس مواصلات (ویب ہکس بیرونی فراہم کنندہ کے انضمام کے لئے بہتر ہیں)
• اعلی ایونٹ والیوم (1,000+ ایونٹس/منٹ)
• قابل ترتیب دوبارہ کوشش کی پالیسیوں کے ساتھ ضمانت شدہ ترسیل کی ضرورت
• فین آؤٹ منظرنامے جہاں ایک واقعہ متعدد صارفین میں کارروائیوں کو متحرک کرتا ہے۔
• ایونٹ کو دوبارہ چلانے کی صلاحیت (کافکا واقعات کو برقرار رکھتا ہے اور صارفین کو کسی بھی مقام سے دوبارہ چلانے کی اجازت دیتا ہے)

پیغام کی قطار کے پیٹرن:

پوائنٹ ٹو پوائنٹ (قطار): ایک پروڈیوسر، ایک صارف۔ استعمال کیا جاتا ہے جب بالکل ایک سروس ہر ایونٹ پر کارروائی کرے۔ مثال: آرڈر بنایا گیا → تکمیل سروس کے عمل (فی آرڈر صرف ایک تکمیلی کارروائی)۔

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

مثال فن تعمیر: آرڈر کی تکمیل

┌──────────┐     order.created      ┌──────────────┐
│ Commerce │ ──────────────────────► │ Message Bus  │
│ Service  │                        │ (Kafka/SQS)  │
└──────────┘                        └──────┬───────┘
                                           │
                    ┌──────────────────────┬┴──────────────────┐
                    │                      │                    │
              ┌─────▼──────┐      ┌───────▼──────┐    ┌──────▼───────┐
              │ Inventory  │      │   Payment    │    │    Email     │
              │  Service   │      │   Service    │    │   Service    │
              │ (reserve)  │      │  (capture)   │    │(confirmation)│
              └────────────┘      └──────────────┘    └──────────────┘

ایونٹ اسکیما ڈیزائن

آپ کی تنظیم میں مسلسل ایونٹ اسکیمے انضمام کی رگڑ کو کم کرتے ہیں:

{
  "event_id": "evt_abc123xyz",
  "event_type": "order.created",
  "timestamp": "2026-03-23T14:30:00Z",
  "version": "2.0",
  "source": "commerce-service",
  "data": {
    "order_id": "ORD-2026-00142",
    "customer_id": "CUST-789",
    "total_amount": 249.99,
    "currency": "USD",
    "line_items": [...]
  },
  "metadata": {
    "correlation_id": "req_xyz789",
    "trace_id": "trace_abc456"
  }
}

کلیدی عناصر:

• ایونٹ_آئی ڈی: آئیڈیمپوٹینسی چیکنگ کے لیے منفرد شناخت کنندہ
• واقعہ_قسم: {entity}.{action} کنونشن کے بعد ڈاٹ نوٹ شدہ قسم
• ورژن: پسماندہ مطابقت کے لیے اسکیما ورژن
• ذریعہ: سروس شناخت کنندہ تیار کرنا
• correlation_id: ڈیبگنگ کے لیے تمام سروسز سے متعلقہ واقعات کو لنک کرتا ہے۔

---

تقسیم شدہ لین دین کے لیے ساگا پیٹرن

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

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

کوریوگرافی ساگا

ہر سروس واقعات کو سنتی ہے اور فیصلہ کرتی ہے کہ آگے کیا کرنا ہے۔ کوئی مرکزی رابطہ کار نہیں ہے۔

مثال: آرڈر کی تکمیل کی کہانی (کوریوگرافی)

1. کامرس سروس آرڈر تخلیق کرتی ہے → شائع کرتی ہے order.created
2. انوینٹری سروس سنتا ہے order.created → ریزرو اسٹاک → شائع کرتا ہے stock.reserved
3. ادائیگی کی خدمت سنتی ہے stock.reserved → کیپچر ادائیگی → شائع کرتی ہے payment.captured
4. فللمنٹ سروس سنتا ہے payment.captured → شپمنٹ تخلیق کرتا ہے → شائع کرتا ہے shipment.created

اگر ادائیگی ناکام ہوجاتی ہے: 3. ادائیگی کی خدمت سنتی ہے stock.reserved → ادائیگی ناکام ہوجاتی ہے → شائع کرتی ہے payment.failed 4. انوینٹری سروس سنتا ہے payment.failed → محفوظ اسٹاک جاری کرتا ہے (معاوضہ لین دین) 5. کامرس سروس سنتا ہے payment.failed → آرڈر کو ناکام کے طور پر نشان زد کرتا ہے → صارف کو مطلع کرتا ہے

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

آرکیسٹریشن ساگا

ایک مرکزی آرکیسٹریٹر سروس کہانی کے مراحل کو مربوط کرتی ہے، ہر سروس کو کمانڈ بھیجتی ہے اور جوابات کو سنبھالتی ہے۔

مثال: آرڈر کی تکمیل کی کہانی (آرکیسٹریشن)

┌──────────────────────────────┐
│    Order Orchestrator         │
│                              │
│  1. Reserve inventory ───────┼──► Inventory Service
│     ◄── stock.reserved ──────┤
│                              │
│  2. Capture payment ─────────┼──► Payment Service
│     ◄── payment.captured ────┤
│                              │
│  3. Create shipment ─────────┼──► Fulfillment Service
│     ◄── shipment.created ────┤
│                              │
│  On any failure:             │
│  - Compensate previous steps │
│  - Update order status       │
│  - Notify customer           │
└──────────────────────────────┘

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

تجویز: پیچیدہ ساگاس (5+ قدم، ایک سے زیادہ مشروط راستے) کے لیے آرکیسٹریشن اور سادہ ساگاس (2-3 قدم، لکیری بہاؤ) کے لیے کوریوگرافی کا استعمال کریں۔

---

API گیٹ وے آرکیٹیکچر

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

گیٹ وے کی ذمہ داریاں

توثیق اور اجازت: ہر بیک اینڈ سروس کی بجائے گیٹ وے پر ایک بار JWT ٹوکنز، API کیز، یا OAuth ٹوکنز کی تصدیق کریں۔ گیٹ وے آگے بھیجی گئی درخواستوں میں تصدیق شدہ شناختی معلومات شامل کرتا ہے۔

ریٹ محدود کرنا: فی صارف ریٹ کی حدیں نافذ کرکے بیک اینڈ سروسز کو اوورلوڈ سے بچائیں۔ مختلف صارفین (اندرونی خدمات، شراکت دار، عوامی ڈویلپرز) مختلف شرح کی حدیں حاصل کرتے ہیں۔

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

رسپانس کیشنگ: اکثر درخواست کردہ، آہستہ آہستہ ڈیٹا کو تبدیل کرنے کے لیے کیشے کے جوابات (پروڈکٹ کیٹلاگ، کنفیگریشن)۔ پسدید لوڈ کو کم کرتا ہے اور جوابی وقت کو بہتر بناتا ہے۔

درخواست/جواب کی تبدیلی: عوامی API فارمیٹس اور اندرونی سروس فارمیٹس کے درمیان ترجمہ کریں۔ عوامی API اس وقت بھی مستحکم رہ سکتا ہے جب اندرونی سروس APIs میں تبدیلی ہو۔

مانیٹرنگ اور لاگنگ: ڈیبگنگ، اینالیٹکس اور تعمیل کے لیے تمام API ٹریفک کی مرکزی لاگنگ۔

گیٹ وے کے اختیارات

بیک اینڈ فار فرنٹ اینڈ (BFF) پیٹرن

API گیٹ وے کی ایک خصوصی شکل جہاں ہر فرنٹ اینڈ ایپلیکیشن (ویب، موبائل، پارٹنر پورٹل) کو اپنی مخصوص گیٹ وے سروس ملتی ہے۔ BFF متعدد بیک اینڈ سروسز پر کالز کو جمع کرتا ہے اور بالکل وہی ڈیٹا واپس کرتا ہے جس کی فرنٹ اینڈ کی ضرورت ہوتی ہے۔

ایک ہی گیٹ وے پر BFF کیوں:

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

یہ وہ پیٹرن ہے ECOSIRE ہیڈ لیس ERP کے نفاذ کے لیے استعمال کرتا ہے — ایک NestJS BFF پرت جو Odoo API کالز کو اکٹھا کرتی ہے اور ہر صفحہ کے اجزاء کو درکار ڈیٹا کے ساتھ ایک Next.js فرنٹ اینڈ پیش کرتی ہے۔

---

شرح کو محدود کرنے کی حکمت عملی

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

شرح کو محدود کرنے والے الگورتھم

فکسڈ ونڈو: فکسڈ ٹائم ونڈوز میں درخواستوں کو شمار کریں (مثلاً 100 درخواستیں فی منٹ)۔ سادہ لیکن ونڈو کی حدود میں پھٹنے کی اجازت دیتا ہے (ونڈو کی حدود میں پھیلے ہوئے 2 سیکنڈ میں 200 درخواستیں)۔

سلائیڈنگ ونڈو: موجودہ اور پچھلی ونڈو شماروں کا وزنی اوسط۔ مقررہ ونڈو کے مقابلے میں ہموار شرح کا نفاذ۔

ٹوکن بالٹی: ٹوکن ایک مقررہ شرح پر جمع ہوتے ہیں (جیسے، 10 ٹوکن/سیکنڈ)۔ ہر درخواست میں ایک ٹوکن استعمال ہوتا ہے۔ اوسط شرح کو نافذ کرتے ہوئے کنٹرولڈ برسٹ (بالٹی کی گنجائش تک) کی اجازت دیتا ہے۔ سب سے عام نفاذ۔

لیکی بالٹی: درخواستیں ایک مقررہ شرح پر کارروائی کی گئی قطار میں داخل ہوتی ہیں۔ ضرورت سے زیادہ درخواستیں مسترد کر دی جاتی ہیں۔ سب سے ہموار آؤٹ پٹ ریٹ فراہم کرتا ہے لیکن تاخیر کا اضافہ کرتا ہے۔

شرح کی حد کی ترتیب

شرح کی حد جوابی ہیڈرز

رسپانس ہیڈر میں شرح کی حد کی معلومات شامل کریں تاکہ صارفین خود کو تھروٹل کر سکیں:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1711209600
Retry-After: 30

جب شرح محدود ہو تو، Retry-After ہیڈر کے ساتھ HTTP 429 (بہت زیادہ درخواستیں) لوٹائیں جو یہ بتاتا ہے کہ صارف کب دوبارہ کوشش کر سکتا ہے۔

---

API ورژننگ

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

ورژن بنانے کی حکمت عملی

URL پاتھ ورژننگ (/v1/orders, /v2/orders): سب سے واضح، صارفین کے لیے سمجھنے اور لاگو کرنے کے لیے سب سے آسان۔ زیادہ تر APIs کے لیے تجویز کردہ طریقہ۔

ہیڈر ورژننگ (Accept: application/vnd.company.v2+json): کلینر URLs لیکن کم قابل دریافت۔ براؤزر میں یا آسان ٹولز سے جانچنا مشکل ہے۔

استفسار پیرامیٹر ورژننگ (/orders?version=2): لاگو کرنا آسان ہے لیکن استفسار کے اسٹرنگ کو آلودہ کرتا ہے اور کیشنگ سے متصادم ہوتا ہے۔

بریکنگ بمقابلہ نان بریکنگ تبدیلیاں

غیر توڑنے والا (پسماندہ ہم آہنگ):

• جوابات میں نئے اختیاری فیلڈز شامل کرنا
• درخواستوں میں نئے اختیاری پیرامیٹرز شامل کرنا
• نئے اختتامی نکات شامل کرنا
• نئی اینوم اقدار شامل کرنا (اگر صارفین نامعلوم اقدار کو احسن طریقے سے سنبھالتے ہیں)

بریکنگ:

• کھیتوں کو ہٹانا یا نام تبدیل کرنا
• فیلڈ کی اقسام کو تبدیل کرنا
• موجودہ شعبوں کے معنی کو تبدیل کرنا
• اختیاری پیرامیٹرز کی ضرورت ہے۔
• URL کے راستے یا HTTP طریقوں کو تبدیل کرنا
• تصدیق کی ضروریات میں ترمیم کرنا

ورژن سازی کے بہترین عمل

1. پہلے دن سے ورژن کے ساتھ شروع کریں: بعد میں ورژن شامل کرنا موجودہ صارفین کے لیے تکلیف دہ ہے۔
2. زیادہ سے زیادہ 2 فعال ورژنز کو برقرار رکھیں: ہر اضافی ورژن دیکھ بھال کے بوجھ کو بڑھا دیتا ہے
3. فرسودگی ٹائم لائن: کسی ورژن کو ہٹانے سے 6+ ماہ قبل فرسودگی کا اعلان کریں۔ جوابی ہیڈر میں فرسودگی کے نوٹس شامل کریں (Sunset: 2027-01-01)
4. معاہدے کا ورژن، عمل درآمد نہیں: تمام ورژن ایک ہی بیک اینڈ کوڈ کو رسپانس ٹرانسفارمیشن لیئرز کے ساتھ شیئر کر سکتے ہیں
5. دستاویزی منتقلی کے رہنما: ہر ورژن کے ٹکرانے کے لیے، ایک تفصیلی گائیڈ فراہم کریں جس میں بتایا جائے کہ کیا بدلا ہے اور کیسے اپ ڈیٹ کیا جائے

---

خرابی سے نمٹنے اور پیٹرن کی دوبارہ کوشش کریں۔

ساختی خرابی کے جوابات

ہر API غلطی کے جواب میں شامل ہونا چاہئے:

{
  "error": {
    "code": "INSUFFICIENT_INVENTORY",
    "message": "Requested quantity (10) exceeds available stock (3) for product SKU-12345",
    "status": 422,
    "details": {
      "product_id": "SKU-12345",
      "requested": 10,
      "available": 3
    },
    "documentation_url": "https://api.example.com/docs/errors#INSUFFICIENT_INVENTORY",
    "request_id": "req_abc123"
  }
}

ایکسپونینشل بیک آف کے ساتھ دوبارہ کوشش کریں۔

عارضی ناکامیوں کے لیے (نیٹ ورک کی غلطیاں، 503 سروس دستیاب نہیں، 429 بہت ساری درخواستیں)، ایکسپونینشل بیک آف اور جٹر کے ساتھ دوبارہ کوشش کو نافذ کریں:

** وقفوں کی دوبارہ کوشش کریں**: 1s, 2s, 4s, 8s, 16s (exponential) + random jitter (0-1s) گرجنے والے ریوڑ کو روکنے کے لیے

زیادہ سے زیادہ کوششیں: API کالز کے لیے 5 کوششیں، ویب ہک ڈیلیوری کے لیے 10 کوششیں

سرکٹ بریکر: لگاتار ناکامیوں کے حد سے تجاوز کرنے کے بعد (جیسے، 1 منٹ میں 5 ناکامیاں)، دوبارہ کوشش کرنا بند کریں اور دوبارہ کوشش کرنے سے پہلے 30 سیکنڈ تک تیزی سے ناکام ہوجائیں۔ یہ پہلے سے ہی جدوجہد کرنے والی سروس کو زبردستی روکتا ہے۔

مردہ خطوط کی قطاریں۔

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

• مسلسل ناکامیوں کی دستی تحقیقات
• بنیادی مسئلہ حل ہونے کے بعد بلک ری پلے
• مردہ خط کی قطار کی گہرائی پر انتباہ (انضمام کے مسائل کی ابتدائی انتباہ)

---

اکثر پوچھے گئے سوالات

کیا مجھے اپنے API کے لیے REST یا GraphQL استعمال کرنا چاہیے؟

عوامی APIs، سادہ CRUD آپریشنز، اور سرور سے سرور کے انضمام کے لیے REST کا استعمال کریں جہاں ردعمل کی شکلیں متوقع ہیں۔ GraphQL استعمال کریں جب آپ کے پاس متعدد فرنٹ اینڈ صارفین ہوں جنہیں ایک ہی API سے مختلف ڈیٹا سبسیٹ کی ضرورت ہو، یا جب HTTP راؤنڈ ٹرپس کو کم کرنا اہم ہو (موبائل ایپلی کیشنز)۔ بہت سی تنظیمیں دونوں استعمال کرتی ہیں — بیرونی APIs کے لیے REST اور اندرونی فرنٹ اینڈ ٹو بیک اینڈ مواصلت کے لیے GraphQL۔

میں Odoo کو دوسرے کاروباری نظاموں کے ساتھ کیسے ضم کروں؟

Odoo انضمام کے لیے JSON-RPC، XML-RPC، اور REST APIs (Odoo 17+) فراہم کرتا ہے۔ ریئل ٹائم انضمام کے لیے، ایک مڈل ویئر پرت (NestJS, FastAPI) بنائیں جو Odoo کے APIs کو استعمال کرتی ہے اور انہیں دوسرے سسٹمز کے سامنے لاتی ہے۔ ایونٹ پر مبنی انضمام کے لیے، ریکارڈ تبدیل ہونے پر ویب ہکس کو متحرک کرنے کے لیے Odoo کی خودکار کارروائیوں کا استعمال کریں۔ ECOSIRE Odoo انٹیگریشن آرکیٹیکچر میں مہارت رکھتا ہے — ہماری انٹیگریشن سروسز دیکھیں۔

ویب ہکس اور میسج کیو میں کیا فرق ہے؟

ویب ہکس HTTP کال بیکس ہیں — جب کوئی واقعہ پیش آتا ہے تو سسٹم A سسٹم B کو HTTP POST کرتا ہے۔ وہ سادہ اور وسیع پیمانے پر تعاون یافتہ ہیں لیکن ضمانت کی فراہمی کی کمی ہے۔ پیغامات کی قطاریں (RabbitMQ، Kafka، SQS) واقعات کو مستقل طور پر اسٹور کرتی ہیں اور انہیں دوبارہ ترتیب دینے، ترتیب دینے، اور فین آؤٹ گارنٹی کے ساتھ فراہم کرتی ہیں۔ بیرونی فراہم کنندہ کے انضمام کے لیے ویب ہکس کا استعمال کریں (سٹرائپ، شاپائف)؛ داخلی خدمت سے سروس مواصلات کے لیے پیغام کی قطاروں کا استعمال کریں۔

میں فریق ثالث فراہم کنندگان سے API کی شرح کی حدود کو کیسے ہینڈل کروں؟

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

کیا مجھے ایک حسب ضرورت API گیٹ وے بنانا چاہیے یا ایک منظم سروس استعمال کرنی چاہیے؟

زیادہ تر کاروباروں کے لیے، ایک منظم API گیٹ وے (AWS API گیٹ وے، Cloudflare Workers، Azure APIM) صحیح انتخاب ہے — کم آپریشنل اوور ہیڈ، بلٹ ان اسکیلنگ، اور تصدیق، شرح کو محدود کرنے، اور نگرانی کے لیے پہلے سے تیار کردہ خصوصیات۔ ایک حسب ضرورت گیٹ وے صرف اس صورت میں بنائیں جب آپ کے پاس مخصوص تقاضے ہوں جو منظم خدمات پوری نہیں کر سکتیں (حسب ضرورت تصدیقی پروٹوکول، پیچیدہ درخواست کی تبدیلی، یا سخت ڈیٹا رہائش کے تقاضے)۔

میں موجودہ انضمام کو توڑے بغیر APIs کا ورژن کیسے بناؤں؟

URL پاتھ ورژننگ (/v1/, /v2/) کا استعمال کریں اور ورژن کے اندر پسماندہ مطابقت برقرار رکھیں۔ ورژن میں اضافہ کیے بغیر اضافی تبدیلیاں کریں (نئی فیلڈز، نئے اینڈ پوائنٹس)۔ صرف تب ہی نیا ورژن بنائیں جب تبدیلیاں ناگزیر ہوں۔ فرسودگی کی ٹائم لائنز (6+ ماہ) پہلے سے اچھی طرح سے بات کریں اور نقل مکانی کی دستاویزات فراہم کریں۔

API انضمام کے لیے مجھے کیا نگرانی کرنی چاہیے؟

پانچ کلیدی میٹرکس کی نگرانی کریں: خرابی کی شرح (4xx/5xx ردعمل کا فیصد)، تاخیر (p50, p95, p99)، تھرو پٹ (درخواستیں فی سیکنڈ)، دستیابی (اپ ٹائم فیصد)، اور سنترپتی (آپ حد یا صلاحیت کی درجہ بندی کے کتنے قریب ہیں)۔ خرابی کی شرح میں اضافے، لیٹنسی بیس لائن کے اوپر بڑھنے اور ڈیڈ لیٹر قطار کی گہرائی پر الرٹس سیٹ کریں۔ تقسیم شدہ ٹریسنگ (OpenTelemetry، Jaeger) متعدد خدمات پر محیط مسائل کو ڈیبگ کرنے کے لیے ضروری ہے۔

---

لچکدار انضمام کی تعمیر

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

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

ECOSIRE کی انٹیگریشن سروسز کاروباری اداروں کو انٹرپرائز انٹیگریشن آرکیٹیکچرز کو ڈیزائن اور لاگو کرنے میں مدد کرتی ہے — Odoo ERP، Shopify کامرس، ادائیگی کے پروسیسرز، اور فریق ثالث کی خدمات کو پیمانوں کے ساتھ جوڑنا۔ اپنے انضمام کے فن تعمیر پر بات کرنے کے لیے ہم سے رابطہ کریں۔