العودة إلى المدونة
Framework Dec 27, 2025 7 دقائق دقيقة قراءة

لماذا نُولِّد REST APIs بدلاً من GraphQL لهجرات Oracle Forms

آخر تحديث Jan 5, 2026

ملخص

يتفوق REST على GraphQL لهجرات Oracle Forms لأن أنماط الوصول إلى Forms ضيقة ومتوقعة، وليست رسوماً بيانية اعتباطية. تتطابق نقاط نهاية REST مباشرة مع الكتل وLOVs، وتُخزَّن مؤقتاً في طبقة CDN، ويمكن للمدققين استعراض مواصفات OpenAPI في يوم واحد.

السؤال الذي نحصل عليه في كل انطلاقة

“افترضنا أن طبقة API الجديدة ستكون GraphQL. كل من تحدثنا إليه روّج لـ GraphQL. أنت أول بائع يخبرنا أن REST هو الإجابة الصحيحة، ونريد أن نفهم السبب قبل أن نوافق،” قال لنا مهندس منصة في إحدى أكبر 5 شركات تأمين أوروبية عند الانطلاق الفصل الماضي. يصل سؤاله في الساعة الأولى في 23 من آخر 30 مهمة هجرة لنا. الإجابة هي نفسها دائماً: GraphQL يُناسب بعض المشاكل. هجرة Oracle Forms ليست واحدة منها.

يُوضح هذا المنشور السبب، بناءً على ما قسناه عبر 14 نشراً إنتاجياً.

أتذكر مشروعاً في عام 2013 حيث ورثنا طبقة SOA نصف منتهية كانت قد لفّتها شركة استشارية خارجية حول خلفية Oracle Forms — مغلفات SOAP تحمل أجزاء XML تم تشكيلها يدوياً لتعكس كتل النموذج. في اليوم الذي حاولنا فيه إضافة حقل واحد جديد إلى بند طلب، وجدنا 11 XSD وأربعة WSDLs وناقل خدمات Java تحتاج جميعها إلى تغييرات مُنسَّقة. استغرق الأمر منا ستة أسابيع للتراجع، وأكد قاعدة احتفظت بها منذ ذلك الحين: يجب أن يتبع شكل API المجال، وليس أحدث موضة معمارية.

كيف يبدو النظام المصدر فعلاً

تطبيق Oracle Forms هو مجموعة من الشاشات، كل منها مرتبط بعدد صغير من كتل قاعدة البيانات. تتطابق الكتلة مع جدول أو عرض. الاستعلامات مُعلَمة، ومجموعات النتائج محدودة، والتنقل بين الشاشات يُمرر حفنة من المفاتيح. نمط الوصول ضيق، ومتوقع، وموصوف بالفعل بواسطة ملفات .fmb الأصلية.

الشاشة المتوسطة في عينتنا تتحدث مع 2.3 جدول وتُجري 4 استعلامات مميزة. يصل الشريحة الـ95 إلى 11 جدولاً و19 استعلاماً. هذا ليس مجالاً يحتاج فيه العملاء إلى تأليف رسوم بيانية اعتباطية على الطاير.

REST يتطابق مع الشكل الحالي

كل كتلة ومحفز وLOV في نموذج مُهاجَر له مُكافئ REST مباشر:

GET    /api/orders?status=open&region=EU
GET    /api/orders/{id}
POST   /api/orders
PATCH  /api/orders/{id}
POST   /api/orders/{id}/approve
GET    /api/lov/customers?q=acm

يُنتج المولد نقطة نهاية واحدة لكل استعلام كتلة، وواحدة لكل LOV، وواحدة لكل إجراء PL/SQL مُسمَّى. تنبثق مواصفات OpenAPI من واصف JSON تلقائياً. كل نقطة نهاية مُكتَّبة من طرف إلى طرف لأن الأنواع تأتي من مخطط قاعدة البيانات الأصلي، وليس من طبقة محلل مكتوبة يدوياً. يتبع النمط المعماري الأساسي أطروحة REST الأصلية لـ Roy Fielding، وهذا أيضاً سبب كون دلالات التخزين المؤقت وعدم الاحتفاظ بالحالة خصائص يمكننا الاعتماد عليها فعلاً.

تكلفة GraphQL التي لا يتحدث عنها أحد

جاذبية GraphQL، وفقاً للمواصفات الرسمية، هي المرونة. يطلب العملاء الحقول التي يحتاجونها بالضبط، وتحدث الاتصالات من جانب الخادم، ويختفي الجلب المفرط. للهجرة، تظهر هذه الفوائد كتكاليف:

  • حل N+1. تُصدر شاشات Forms اتصالات قابلة للتنبؤ. يتعين على حلول GraphQL إعادة بناء هذه الاتصالات في وقت التشغيل، وتضيف تجميعات DataLoader طبقة لم تكن موجودة في النظام المصدر.
  • سطح التفويض. تحتاج التطبيقات ضمن نطاق SOX إلى التحكم في الوصول على مستوى الحقل. تُشفر نقاط نهاية REST الأذونات على مستوى المسار؛ يدفعها GraphQL إلى كل محلل. قسنا زيادة 3.2x في الكود المتعلق بالمصادقة في نموذج أولي لنقل GraphQL.
  • حدود تعقيد الاستعلام. تحتاج خوادم GraphQL الإنتاجية إلى حدود عمق، وتحليل تكلفة، واستعلامات ثابتة لمنع الإساءة. لا شيء من هذا مطلوب لمجموعة معروفة من الشاشات المُهاجَرة.
  • التخزين المؤقت. تُخزَّن استجابات REST مؤقتاً بسلاسة في طبقة CDN والمتصفح. أجسام GraphQL POST لا.

حجة التدقيق

هجرات Oracle Forms غالباً ما تكون ضمن نطاق SOX أو HIPAA أو أنظمة مماثلة. يراجع المدققون أسطح API. يستغرق REST API يحتوي على 240 نقطة نهاية ووثيقة OpenAPI منشورة يوماً واحداً لاستعراضها. يستغرق مخطط GraphQL يحتوي على 80 نوعاً وتأليف استعلام اعتباطي أسبوعاً — ولا يزال لدى المدقق أسئلة حول استعلامات العميل الممكنة فعلاً في الإنتاج.

في هجرة مرافق واحدة، طلب فريق التدقيق صراحةً REST لأن مصفوفة التحكم الحالية كانت مبنية حول أفعال HTTP وأنماط URL. إعادة بنائها لـ GraphQL كانت ستدفع توقيع SOX بفصل كامل.

حيث يكون GraphQL منطقياً

لسنا متعصبين بشأن هذا. GraphQL مناسب عندما يكون العملاء متنوعين، والمخطط واسع، وأشكال الاستعلام غير متوقعة — تطبيقات الجوال التي تسحب من كتالوج المنتجات، على سبيل المثال. هجرات Oracle Forms ليست أياً من ذلك. العملاء معروفون (الشاشات المُهاجَرة)، والمخطط محدود (قاعدة البيانات التي يستخدمها تطبيق Forms بالفعل)، والاستعلامات معددة في ملفات .fmb نفسها.

اختيار REST هنا ليس محافظة. إنه مطابقة الأداة لشكل المشكلة.

الخلاصة

كل نقطة نهاية في منصتنا المُولَّدة هي REST، موثقة في OpenAPI، ومشتقة مباشرة من بيانات Forms الأصلية. القرار لا يتعلق بأي أسلوب API أفضل في المُجرَّد. يتعلق بأي واحد يتطابق بسلاسة مع 30 عاماً من الوصول إلى قاعدة البيانات المرتبط بالشاشة، وأي واحد يمكن للمدققين الموافقة عليه قبل أن تعمل أول شاشة.