شرح واضح لـ RPC و REST و GraphQL

في مجال تطوير البرمجيات الحديث، نادرًا ما توجد التطبيقات بمعزل عن غيرها. فهي تتواصل وتتبادل البيانات وتشغل الإجراءات في بعضها البعض، لتشكل أنظمة بيئية مترابطة وواسعة. يتم تنسيق هذا الاتصال بواسطة واجهات برمجة التطبيقات (APIs)، التي تحدد القواعد والبروتوكولات لكيفية تفاعل مكونات البرامج المختلفة. على مر العقود، ظهرت العديد من الأنماط المعمارية والبروتوكولات لتسهيل هذا الاتصال بين الخدمات. من أبرز هذه الأنماط استدعاء الإجراءات عن بعد (RPC)، ونقل الحالة التمثيلية (REST)، وGraphQL.

يعد فهم هذه النماذج الثلاثة أمرًا بالغ الأهمية لأي مطور أو مهندس معماري يقوم بتصميم أنظمة موزعة. يأتي كل منها بفلسفته الخاصة، ونقاط قوته وضعفه، وحالات الاستخدام المثالية. يهدف هذا المقال إلى شرح RPC وREST وGraphQL بوضوح، والتعمق في مفاهيمها الأساسية، وآليات عملها، وفوائدها، وعيوبها، والسيناريوهات التي يتألق فيها كل منها.

الأساس: اتصال العميل بالخادم

قبل الغوص في التفاصيل، من الضروري فهم النموذج الأساسي الذي تخدمه جميعها: اتصال العميل بالخادم. في هذا النموذج، يحتاج **العميل** (مثل متصفح الويب، تطبيق الهاتف المحمول، خادم آخر) إلى بعض البيانات أو يريد تنفيذ إجراء. في الوقت نفسه، يستضيف **الخادم** (جهاز أو عملية بعيدة) البيانات أو المنطق اللازم لتنفيذ الإجراء. يرسل العميل **طلبًا** إلى الخادم، ويرسل الخادم **استجابة** مرة أخرى. الآليات التي سنتناولها - RPC وREST وGraphQL - هي طرق مختلفة لهيكلة هذه الطلبات والاستجابات.

RPC: استدعاء الدوال عبر الشبكات

ما هو RPC؟

يمثل استدعاء الإجراءات عن بعد (Remote Procedure Call) أحد أقدم النماذج وأكثرها مباشرة للاتصال بين العمليات. الفكرة الأساسية هي جعل الطلب إلى خادم بعيد يظهر ويعمل بشكل مشابه جدًا لاستدعاء دالة أو إجراء محلي. يقوم تطبيق العميل باستدعاء ما يبدو أنه دالة محلية ("الإجراء")، ولكن تنفيذ هذه الدالة يحدث فعليًا على خادم بعيد. يتم تجريد تعقيدات الاتصال الشبكي بعناية، مما يمنح البرمجة الموزعة جوًا من البساطة يشبه البرمجة التقليدية على جهاز واحد.

كيف يعمل RPC:

تتكشف عملية RPC من خلال سلسلة من الخطوات المنسقة، المصممة لجعل التنفيذ عن بعد شفافًا. في البداية، يمتلك العميل "stub" أو "proxy" للإجراء عن بعد. هذا الـ stub يعكس توقيع الإجراء الفعلي عن بعد. عندما يستدعي تطبيق العميل هذا الـ stub، لا يتم تنفيذ المنطق محليًا. بدلاً من ذلك، يأخذ الـ stub الخاص بالعميل المعلمات التي تم تمريرها إلى الدالة ويقوم بـ "marshalling" أو "serializing" لها. هذه الخطوة الحاسمة تحول المعلمات من تمثيلها في الذاكرة إلى تنسيق مناسب للإرسال عبر الشبكة، مثل الثنائي (binary) أو XML أو JSON.

بعد الـ marshalling، يتم إرسال هذه المعلمات المتسلسلة، مصحوبة بمعرف للإجراء المحدد الذي سيتم استدعاؤه، عبر الشبكة إلى الخادم. على جانب الخادم، ينتظر "skeleton" أو الـ stub الخاص بالخادم ويستقبل الطلب الوارد. يقوم هذا الـ skeleton الخاص بالخادم بعد ذلك بمهمة "unmarshalling" أو "deserializing" للبيانات المستلمة، وتحويلها مرة أخرى إلى المعلمات التي يتوقعها الإجراء الفعلي على الخادم.

مع إعادة بناء المعلمات بنجاح، يستدعي الـ skeleton الخاص بالخادم الإجراء المعين على الخادم، ويمرر له المعلمات التي تم فك تسلسلها. بمجرد أن يكمل الإجراء تنفيذه، يتم تسلسل قيمة الإرجاع الخاصة به، بالإضافة إلى أي استثناءات تمت مواجهتها، بواسطة الـ skeleton الخاص بالخادم. يتم بعد ذلك إرسال هذه الاستجابة المتسلسلة مرة أخرى عبر الشبكة إلى الـ stub الخاص بالعميل. عند تلقي الاستجابة، يقوم الـ stub الخاص بالعميل بفك تسلسلها، وتحويل البيانات مرة أخرى إلى قيمة إرجاع يمكن لتطبيق العميل فهمها بسهولة. أخيرًا، يقوم الـ stub الخاص بالعميل بإرجاع هذه القيمة إلى الكود الأصلي الذي قام بالاستدعاء، وبالتالي يكمل وهم أن استدعاء دالة محلية قد تم تنفيذه.

الخصائص الرئيسية لـ RPC:

عادة ما تكون واجهات برمجة تطبيقات RPC **موجّهة نحو الإجراءات**. يتم تصميمها حول الأفعال أو الأوامر، مثل addUser(userDetails) أو calculatePrice(itemId, quantity). التركيز الأساسي هو على "الإجراءات التي يمكنك تنفيذها".

تقليديًا، يُظهر العملاء والخوادم في أنظمة RPC **اقترانًا محكمًا**. غالبًا ما يحتاج العميل إلى معرفة صريحة بأسماء الدوال المحددة وتوقيعات المعلمات الدقيقة المتاحة على الخادم. وبالتالي، فإن التعديلات على جانب الخادم غالبًا ما تتطلب تغييرات مقابلة على جانب العميل.

توفر أطر عمل RPC عادة أدوات لإنشاء stubs للعميل وskeletons للخادم بلغات برمجة مختلفة من **لغة تعريف الواجهة المشتركة (IDL)**. تتضمن أمثلة IDLs: CORBA IDL، Protocol Buffers (.proto files)، أو Apache Thrift IDL. تسهل إمكانية إنشاء الكود هذه قابلية التشغيل البيني.

فيما يتعلق **بالكفاءة**، تم تصميم العديد من بروتوكولات RPC، وخاصة تلك التي تستخدم تنسيقات ثنائية، لتحقيق الأداء الأمثل من حيث حجم البيانات وسرعة المعالجة.

التطور: gRPC

بينما كان لدى تطبيقات RPC السابقة مثل XML-RPC أو Java RMI بعض القيود، شهد نموذج RPC انتعاشًا كبيرًا مع ظهور أطر عمل حديثة مثل gRPC (Google RPC). يقدم gRPC تحسينات جوهرية. يستخدم بشكل أساسي **Protocol Buffers** كلغة IDL ولسلسلة الرسائل. توفر Protocol Buffers آلية لغة مستقلة، محايدة للمنصة، قابلة للتوسيع لسلسلة البيانات المهيكلة، وغالبًا ما توصف بأنها بديل أكثر إحكامًا وأسرع وأبسط لـ XML.

علاوة على ذلك، يعمل gRPC عبر **HTTP/2**، مما يتيح ميزات متقدمة مثل تعدد الإرسال (multiplexing) (السماح بطلبات واستجابات متعددة عبر اتصال واحد)، وإمكانيات دفع الخادم (server push)، وضغط الرأس (header compression). تساهم هذه الميزات مجتمعة في تحسين الأداء وتقليل زمن الاستجابة.

من نقاط القوة البارزة في gRPC دعمه لأنماط **البث (streaming)** المختلفة. تشمل هذه الأنماط: أحادي (unary) (نمط طلب-استجابة بسيط)، بث الخادم (server streaming) (حيث يرسل العميل طلبًا، ويرد الخادم بتيار من الرسائل)، بث العميل (client streaming) (حيث يرسل العميل تيارًا من الرسائل، ويصدر الخادم استجابة واحدة)، وبث ثنائي الاتجاه (bidirectional streaming) (حيث يمكن لكل من العميل والخادم إرسال تيار من الرسائل بشكل مستقل).

أخيرًا، يوفر gRPC أدوات قوية **لإنشاء الكود**، مما يتيح الإنشاء التلقائي لكود العميل والخادم في العديد من لغات البرمجة الشائعة.

إيجابيات RPC (خاصة RPC الحديث مثل gRPC):

• الأداء: يمكن أن يكون أداؤه استثنائيًا، خاصة عند استخدام بروتوكولات ثنائية مثل Protocol Buffers جنبًا إلى جنب مع HTTP/2. زمن الاستجابة المنخفض هو ميزة بارزة.
• البساطة (للمطورين): يمكن لتجريد الاستدعاء عن بعد كدالة محلية أن يبسط جهود التطوير بشكل كبير، خاصة بالنسبة للخدمات المصغرة الداخلية.
• عقود قوية النوع (Strongly Typed Contracts): تفرض IDLs عقدًا واضحًا وغير غامض بين العميل والخادم، مما يساعد في اكتشاف أخطاء التكامل أثناء وقت الترجمة.
• إمكانيات البث (Streaming Capabilities): يتفوق في السيناريوهات التي تتطلب تدفق بيانات في الوقت الفعلي أو نقل مجموعات بيانات كبيرة.
• إنشاء الكود (Code Generation): يقلل الإنشاء التلقائي لمكتبات العميل وstubs الخادم من كمية الكود النمطي الذي يحتاج المطورون لكتابته.

سلبيات RPC:

• الاقتران المحكم (Tight Coupling): حتى مع استخدام IDLs، غالبًا ما تتطلب التعديلات على توقيعات الإجراءات إعادة إنشاء ونشر كود العميل والخادم على حد سواء.
• قابلية الاكتشاف (Discoverability): على عكس REST، لا توجد طريقة موحدة لاكتشاف الإجراءات المتاحة أو هياكلها دون الوصول المسبق إلى IDL أو التوثيق المرتبط به.
• أقل ملاءمة للمتصفحات (تاريخيًا): لم تكن آليات RPC التقليدية سهلة الدمج مباشرة مع متصفحات الويب مقارنة بـ REST. بينما يهدف gRPC-Web إلى سد هذه الفجوة، فإنه يتطلب عادة طبقة وكيل (proxy).
• اجتياز جدران الحماية (Firewall Traversal): يمكن أن تواجه آليات RPC غير المستندة إلى HTTP أحيانًا صعوبات مع جدران الحماية التي تم تكوينها بشكل أساسي للسماح بحركة مرور HTTP. gRPC، باستخدام HTTP/2، يخفف إلى حد كبير من هذا القلق.

متى تستخدم RPC:

فكر في استخدام RPC للاتصال الداخلي بين الخدمات المصغرة حيث يكون الأداء العالي وزمن الاستجابة المنخفض أهدافًا تصميمية حاسمة. كما أنه مناسب تمامًا للتطبيقات التي تتطلب بثًا معقدًا وعالي الأداء للبيانات. إذا كان العقد المحدد بوضوح وقوي النوع بين الخدمات مرغوبًا فيه، فإن RPC يقدم مزايا كبيرة. البيئات متعددة اللغات (Polyglot environments)، حيث يمكن لإنشاء الكود للغات متعددة تبسيط التطوير، تستفيد أيضًا من RPC. أخيرًا، في البيئات ذات قيود الشبكة حيث تكون كفاءة حجم الرسالة أمرًا بالغ الأهمية، فإن RPC، وخاصة gRPC مع Protocol Buffers، هو مرشح قوي.

REST: الموارد والوسائط المتعددة

ما هو REST؟

REST، أو Representational State Transfer، ليس بروتوكولًا أو معيارًا صارمًا، بل هو نمط معماري لتصميم التطبيقات الشبكية. تم تعريفه بدقة من قبل روي فيلدينغ في أطروحته للدكتوراه عام 2000. يستفيد REST ببراعة من الميزات والبروتوكولات الموجودة في HTTP، مع التركيز على وضع اتصال لا يعتمد على الحالة (stateless)، من العميل إلى الخادم، وقابل للتخزين المؤقت (cacheable). يدور المفهوم المركزي حول الموارد (كيانات البيانات) التي يتم تعريفها بشكل فريد بواسطة عناوين URL، ويتم إجراء التفاعلات مع هذه الموارد باستخدام طرق HTTP القياسية.

المبادئ الأساسية لـ REST (القيود):

يتم تعريف نمط REST المعماري بواسطة عدة قيود توجيهية:

مبدأ أساسي هو **هندسة العميل والخادم**. هذا يفرض فصلًا واضحًا للمخاوف. العميل مسؤول عن واجهة المستخدم وجوانب تجربة المستخدم، بينما يدير الخادم تخزين البيانات، ومنطق الأعمال، وتوفير واجهة برمجة التطبيقات نفسها.

قيد حاسم آخر هو **عدم الحالة (Statelessness)**. يجب أن يغلف كل طلب يرسله العميل إلى الخادم جميع المعلومات المطلوبة لكي يفهم الخادم هذا الطلب ويعالجه. لا يحتفظ الخادم بأي سياق للعميل (حالة الجلسة) بين الطلبات الفردية. أي حالة تتعلق بجلسة يتم الاحتفاظ بها على جانب العميل.

تعتبر **قابلية التخزين المؤقت (Cacheability)** أيضًا مبدأ أساسيًا. يجب أن تحدد الاستجابات التي يولدها الخادم نفسها بشكل صريح بأنها قابلة للتخزين المؤقت أو غير قابلة للتخزين المؤقت. هذا يسمح للعملاء والأنظمة الوسيطة (مثل شبكات توصيل المحتوى أو CDNs) بتخزين الاستجابات مؤقتًا، مما يمكن أن يعزز الأداء وقابلية التوسع بشكل كبير.

تم تصميم أنظمة REST كنظام **طبقات (Layered System)**. هذا يعني أن العميل لا يمكنه عادة التأكد مما إذا كان متصلاً مباشرة بالخادم النهائي أو بوسيط (مثل موازن التحميل أو الوكيل) على طول مسار الاتصال. يمكن للخوادم الوسيطة تعزيز قابلية توسع النظام من خلال تسهيل موازنة التحميل وتوفير مخابئ مشتركة.

يُعد قيد الواجهة الموحدة (Uniform Interface) على الأرجح ما يميز REST ويساهم في تبسيط وفصل الهندسة المعمارية. ينقسم هذا القيد إلى عدة قيود فرعية.

أولاً، تحديد الموارد (Identification of Resources): يتم تحديد جميع الموارد المفاهيمية ضمن الطلبات باستخدام معرفات الموارد الموحدة (URIs)، وعادة ما تكون عناوين URL. على سبيل المثال، /users/123 يحدد بشكل فريد مورد مستخدم معين.

ثانياً، معالجة الموارد من خلال التمثيلات (Manipulation of Resources Through Representations): يتفاعل العملاء مع الموارد ليس عن طريق استدعاء الدوال عليها مباشرة، ولكن عن طريق تبادل تمثيلات لهذه الموارد. يمكن أن يكون التمثيل بتنسيقات مختلفة، مثل JSON أو XML أو HTML. يشير العميل إلى التنسيق (التنسيقات) المفضلة لديه باستخدام رؤوس Accept، بينما يحدد الخادم تنسيق التمثيل المرسل باستخدام رأس Content-Type.

ثالثاً، الرسائل ذاتية الوصف (Self-Descriptive Messages): يجب أن تحتوي كل رسالة يتم تبادلها على معلومات كافية لوصف كيفية معالجتها. على سبيل المثال، توفر رؤوس HTTP مثل Content-Type وContent-Length بيانات وصفية حول نص الرسالة، وتخبر رموز الحالة العميل بنتيجة طلبه.

رابعاً، الوسائط المتعددة كمحرك لحالة التطبيق (HATEOAS - Hypermedia as the Engine of Application State): هذا المبدأ، الذي غالبًا ما يعتبر الأكثر تعقيدًا وأحيانًا الأقل تطبيقًا في REST، يفرض أن استجابات الخادم يجب أن تتضمن روابط (وسائط متعددة). توجه هذه الروابط العميل من خلال الإشارة إلى الإجراءات التي يمكنه اتخاذها بعد ذلك أو الموارد ذات الصلة التي يمكنه الوصول إليها. هذا يسمح للعملاء بالتنقل في واجهة برمجة التطبيقات ديناميكيًا، بدلاً من الاعتماد على عناوين URI المكتوبة بشكل ثابت. على سبيل المثال، قد تتضمن استجابة لمورد مستخدم روابط لعرض طلباته أو تحديث تفاصيل ملفه الشخصي.

قيد اختياري هو **الكود عند الطلب (Code on Demand)**. هذا يسمح للخوادم بتوسيع أو تخصيص وظائف العميل مؤقتًا عن طريق نقل كود قابل للتنفيذ، مثل مقتطفات JavaScript.

كيف يعمل REST:

في نظام RESTful، يتم تصور كل شيء على أنه **مورد** (مثل مستخدم، منتج، طلب). يتم تحديد كل مورد بشكل فريد بواسطة **URI**. على سبيل المثال، GET /users قد يسترد قائمة بالمستخدمين، بينما GET /users/123 يسترد المستخدم المحدد الذي يحمل المعرف 123.

تُستخدم **طرق HTTP القياسية (الأفعال)** لتنفيذ الإجراءات على هذه الموارد. يُستخدم GET لاسترداد مورد. يُستخدم POST عادة لإنشاء مورد جديد أو يمكن استخدامه لتشغيل عملية، مع إرسال بيانات المورد الجديد في نص الطلب. يُستخدم PUT لتحديث مورد موجود، ويتطلب عادة استبدالًا كاملاً لبيانات المورد، وهو مُتطابق (idempotent) (الطلبات المتعددة المتطابقة لها نفس تأثير الطلب الواحد). يُستخدم DELETE لإزالة مورد. يسمح PATCH بالتحديثات الجزئية لمورد موجود. يسترد HEAD البيانات الوصفية حول مورد، مشابه لـ GET ولكن بدون نص الاستجابة. يُستخدم OPTIONS للحصول على معلومات حول خيارات الاتصال للمورد الهدف.

تُستخدم **رموز الحالة (Status Codes)**، وهي جزء من معيار HTTP، للإشارة إلى نتيجة الطلب. تتضمن الأمثلة 200 OK للنجاح، 201 Created للإنشاء الناجح، 400 Bad Request لأخطاء العميل، 404 Not Found عندما لا يوجد مورد، و 500 Internal Server Error لمشاكل جانب الخادم.

فيما يتعلق **بتنسيقات البيانات**، أصبح JSON (JavaScript Object Notation) هو التنسيق الأكثر شيوعًا لتبادل البيانات في واجهات برمجة تطبيقات REST نظرًا لطبيعته الخفيفة وسهولة تحليله. ومع ذلك، يمكن أيضًا استخدام XML أو HTML أو حتى نص عادي.

إيجابيات REST:

• البساطة والألفة: يستفيد من معايير HTTP المفهومة جيدًا، مما يجعله سهل التعلم والتنفيذ والاستهلاك نسبيًا.
• عدم الحالة (Statelessness): هذا يبسط تصميم الخادم ويعزز قابلية التوسع لأن الخوادم لا تحتاج إلى الاحتفاظ بمعلومات جلسة العميل بين الطلبات.
• قابلية التخزين المؤقت (Cacheability): يمكن استخدام آليات التخزين المؤقت لـ HTTP مباشرة وبشكل فعال لتحسين الأداء وتقليل حمل الخادم.
• الفصل (Decoupling): يتم فصل العميل والخادم. طالما أن URI المورد وعقد الطريقة يظلان متسقين، يمكن أن تتطور التطبيقات الأساسية على أي من الجانبين بشكل مستقل.
• قابلية الاكتشاف (مع HATEOAS): عند تطبيق HATEOAS بشكل صحيح، يمكن للعملاء اكتشاف الإجراءات المتاحة ديناميكيًا والتنقل عبر الموارد، مما يجعل واجهة برمجة التطبيقات أكثر مرونة وقابلية للتطور.
• الاعتماد الواسع والأدوات: يوجد نظام بيئي واسع من الأدوات والمكتبات وحزم تطوير العميل (SDKs) والبوابات (gateways) التي تدعم واجهات برمجة تطبيقات RESTful. إنه ملائم بطبيعته للمتصفحات.
• قابلية القراءة البشرية: غالبًا ما يتم تصميم عناوين URI لتكون قابلة للقراءة البشرية، وتنسيقات البيانات الشائعة مثل JSON سهلة للمطورين للفحص وتصحيح الأخطاء.

سلبيات REST:

• الإفراط في الجلب (Over-fetching) ونقص الجلب (Under-fetching): هذه مشاكل شائعة.
• يحدث **الإفراط في الجلب** عندما يعيد نقطة نهاية (endpoint) بيانات أكثر مما يحتاجه العميل فعليًا لمهمة معينة. على سبيل المثال، لعرض قائمة بأسماء المستخدمين، قد تعيد نقطة النهاية /users كائنات مستخدم كاملة تتضمن عناوين وأرقام هواتف وتفاصيل أخرى لكل مستخدم، معظمها قد لا يتم استخدامه.
• يحدث **نقص الجلب** عندما يحتاج العميل إلى إجراء طلبات متعددة إلى نقاط نهاية مختلفة لجمع جميع البيانات التي يحتاجها لعرض كامل. على سبيل المثال، للحصول على تفاصيل مستخدم ومنشوراته الأخيرة، قد يحتاج العميل أولاً إلى استدعاء /users/{id} ثم إجراء استدعاء منفصل إلى /users/{id}/posts.
• جولات ذهاب وعودة متعددة (Multiple Round Trips): غالبًا ما تؤدي مشكلة نقص الجلب إلى جولات ذهاب وعودة متعددة عبر الشبكة، مما قد يزيد من زمن الاستجابة ويؤثر سلبًا على تجربة المستخدم، خاصة على شبكات الهاتف المحمول أو الشبكات غير الموثوقة.
• تحديات الإصدار (Versioning Challenges): قد يكون تطوير واجهات برمجة تطبيقات REST دون كسر العملاء الحاليين أمرًا صعبًا. تتضمن الاستراتيجيات الشائعة إصدار URI (مثل /v1/users)، أو استخدام رؤوس طلب مخصصة للإصدار، أو استخدام إصدار نوع الوسائط (عبر رؤوس Accept). كل نهج له مجموعة من التعقيدات والمقايضات الخاصة به.
• HATEOAS غالبًا ما يتم إهماله: على الرغم من كونه مبدأ أساسيًا في REST، غالبًا ما لا يتم تطبيق HATEOAS بشكل كامل. هذا يحد من قابلية الاكتشاف الحقيقية والقابلية للتطور الديناميكي التي يهدف REST إلى توفيرها.
• لا يوجد تحديد قوي للنوع (Strong Typing) خارج الصندوق: على عكس أنظمة RPC التي تستخدم IDLs، يعتمد REST على الاتفاقيات والتوثيق الخارجي (مثل مواصفات OpenAPI/Swagger) لتحديد عقود واجهة برمجة التطبيقات. لا يتم فرض هذه العقود دائمًا في وقت الترجمة، مما قد يؤدي إلى مشاكل تكامل.

متى تستخدم REST:

REST هو خيار ممتاز لواجهات برمجة التطبيقات الموجهة للجمهور حيث يكون الاعتماد الواسع، وسهولة التكامل، وقابلية التشغيل البيني مهمة. إنه مناسب تمامًا للتطبيقات التي تركز على الموارد حيث تشكل عمليات CRUD القياسية (الإنشاء، القراءة، التحديث، الحذف) على الكيانات الوضع الأساسي للتفاعل. إذا كان الاستفادة من التخزين المؤقت لـ HTTP أمرًا حاسمًا للأداء وقابلية التوسع، فإن توافق REST مع معايير HTTP هو ميزة كبيرة. الحالات التي تتطلب عدم الحالة وقابلية التوسع الأفقي تستفيد أيضًا بشكل كبير من نمط RESTful المعماري. علاوة على ذلك، عندما تكون قابلية الاكتشاف من خلال الوسائط المتعددة (HATEOAS) مرغوبة للسماح للعملاء بالتنقل ديناميكيًا في واجهة برمجة التطبيقات، يوفر REST الإطار لذلك.

GraphQL: لغة استعلام لواجهة برمجة التطبيقات الخاصة بك

ما هو GraphQL؟

GraphQL هي لغة استعلام مصممة خصيصًا لواجهات برمجة التطبيقات، كما أنها تشمل وقت تشغيل (runtime) على جانب الخادم لتنفيذ هذه الاستعلامات باستخدام نظام أنواع (type system) تقوم بتعريفه لبياناتك. تم تطويرها في الأصل بواسطة فيسبوك وتم فتح مصدرها لاحقًا في عام 2015، تم تصميم GraphQL لمعالجة بعض القيود المتأصلة التي لوحظت في هياكل RESTful، وأبرزها مشكلتي الإفراط في الجلب ونقص الجلب للبيانات. إنها تمكّن العملاء من طلب البيانات التي يحتاجونها بالضبط، لا أكثر ولا أقل، عادة ضمن دورة طلب-استجابة واحدة.

المفاهيم الأساسية لـ GraphQL:

تم بناء هندسة GraphQL على عدة مفاهيم أساسية.

حجر الزاوية هو **لغة تعريف المخطط (SDL - Schema Definition Language)**. يتم تعريف واجهات برمجة تطبيقات GraphQL بدقة بواسطة نظام أنواع قوي. ينشر الخادم مخططًا يصف بدقة جميع أنواع البيانات التي يُسمح للعميل بالاستعلام عنها، بالإضافة إلى العلاقات المعقدة التي توجد بين هذه الأنواع من البيانات. يعمل هذا المخطط كعقد ملزم بين العميل والخادم. ضمن SDL، تقوم بتعريف بناءات مختلفة:

• **الأنواع (Types)** تصف الكائنات التي يمكنك جلبها وحقولها (على سبيل المثال، type User { id: ID!, name: String, email: String, posts: [Post] }).
• **الاستعلامات (Queries)** تحدد نقاط الدخول لعمليات جلب البيانات (على سبيل المثال، type Query { user(id: ID!): User, posts: [Post] }).
• **التعديلات (Mutations)** تحدد نقاط الدخول لعمليات تعديل البيانات - إنشاء البيانات أو تحديثها أو حذفها (على سبيل المثال، type Mutation { createUser(name: String!, email: String!): User }).
• **الاشتراكات (Subscriptions)** تحدد كيف يمكن للعملاء تلقي تحديثات في الوقت الفعلي عندما تتغير بيانات معينة على الخادم (على سبيل المثال، type Subscription { newPost: Post }).

ميزة أخرى مميزة هي استخدامها النموذجي **لنقطة نهاية واحدة (Single Endpoint)**. على عكس REST، الذي يستخدم عادة عناوين URL متعددة لتمثيل موارد وعمليات مختلفة، فإن واجهات برمجة تطبيقات GraphQL عادة ما تعرض نقطة نهاية واحدة فقط (على سبيل المثال، /graphql). يتم توجيه جميع الطلبات، سواء كانت استعلامات لجلب البيانات، أو تعديلات لتعديل البيانات، أو اشتراكات لتحديثات في الوقت الفعلي، إلى نقطة النهاية المفردة هذه، وعادة ما يكون ذلك عبر طلب HTTP POST.

يُعد مفهوم **الاستعلامات المحددة من قبل العميل (Client-Specified Queries)** جوهر قوة GraphQL. يقوم تطبيق العميل ببناء سلسلة استعلام تحدد صراحة البيانات التي يحتاجها بالضبط. يمكن أن يشمل ذلك ليس فقط الحقول على كائن أساسي ولكن أيضًا الحقول على الكائنات ذات الصلة، مع اجتياز علاقات البيانات المعقدة. يقوم الخادم بعد ذلك بمعالجة هذا الاستعلام والرد بكائن JSON يعكس هيكله بدقة هيكل الاستعلام الذي قدمه العميل.

كيف يعمل GraphQL:

يتبع التفاعل في نظام GraphQL تدفقًا محددًا جيدًا. يبدأ بـ **تعريف المخطط (Schema Definition)**، حيث يحدد الخادم قدرات بياناته باستخدام SDL الخاص بـ GraphQL.

بعد ذلك، يتم بناء **استعلام العميل (Client Query)**. يقوم العميل بصياغة سلسلة استعلام GraphQL، مفصلًا حقول البيانات المحددة التي يحتاجها. على سبيل المثال:GraphQL

query GetUserDetails {
  user(id: "123") {
    id
    name
    email
    posts { # Fetch related posts
      title
      content
    }
  }
}

يتم بعد ذلك إرسال هذا الاستعلام في **طلب إلى الخادم (Request to Server)**، عادة كحمولة JSON ضمن طلب HTTP POST، مستهدفًا نقطة نهاية GraphQL الواحدة.

عند تلقي الطلب، تبدأ **معالجة الخادم (Server Processing)**. يتضمن ذلك عدة خطوات فرعية. يقوم الخادم أولاً بـ **تحليل والتحقق من الصحة (Parses & Validates)** الاستعلام الوارد، والتحقق من تركيبه والتأكد من مطابقته للمخطط المحدد. إذا كان صالحًا، ينتقل الاستعلام إلى **التنفيذ (Execution)**. يقوم الخادم بتنفيذ الاستعلام عن طريق استدعاء دوال "المحلل" (resolver). يتم دعم كل حقل معرف في مخطط GraphQL بواسطة دالة محلل مقابلة. المحلل هو جزء من الكود المسؤول عن جلب البيانات لحقله المحدد. يمكن لهذه المحللات استرداد البيانات من مصادر مختلفة، مثل قواعد البيانات، أو واجهات برمجة تطبيقات داخلية أو خارجية أخرى، أو حتى بيانات ثابتة.

أخيرًا، يقوم الخادم بصياغة وإرسال **استجابة إلى العميل (Response to Client)**. هذه الاستجابة هي كائن JSON يعكس هيكله شكل الاستعلام الأصلي، ويحتوي فقط على البيانات التي تم طلبها صراحة. بالنسبة للاستعلام المثال أعلاه، قد تبدو الاستجابة كما يلي:JSON

{
  "data": {
    "user": {
      "id": "123",
      "name": "Alice Wonderland",
      "email": "alice@example.com",
      "posts": [
        {
          "title": "My First Post",
          "content": "Hello world!"
        },
        {
          "title": "GraphQL is Cool",
          "content": "Learning about GraphQL..."
        }
      ]
    }
  }
}

إيجابيات GraphQL:

• لا يوجد إفراط في الجلب أو نقص في الجلب: يطلب العملاء البيانات التي يحتاجونها بالضبط، مما يؤدي إلى نقل بيانات عالي الكفاءة وتقليل عرض النطاق الترددي المهدر.
• طلب واحد لموارد متعددة: يمكن جلب البيانات ذات الصلة، حتى عبر موارد مفاهيمية مختلفة، في استعلام واحد، مما يقلل بشكل كبير من عدد جولات الذهاب والإياب عبر الشبكة.
• مخطط قوي النوع (Strongly Typed Schema): يعمل المخطط كعقد واضح وموثوق بين العميل والخادم. يتيح هذا التحديد القوي للنوع أدوات تطوير قوية، مثل الإكمال التلقائي، والتحليل الساكن، والتحقق من صحة الاستعلام، كما يعمل كشكل من أشكال التوثيق الذاتي.
• قابلية التطور (Evolvability): يصبح من الأسهل تطوير واجهات برمجة التطبيقات دون اللجوء إلى الإصدار. إضافة حقول أو أنواع جديدة إلى المخطط لا يكسر العملاء الحاليين، حيث أنهم يتلقون فقط البيانات التي يطلبونها صراحة. إهمال الحقول القديمة يصبح أيضًا أكثر وضوحًا.
• بيانات في الوقت الفعلي مع الاشتراكات (Real-time Data with Subscriptions): يتضمن GraphQL دعمًا مدمجًا للتحديثات في الوقت الفعلي من خلال الاشتراكات، مما يسمح للعملاء بالاستماع إلى تغييرات بيانات محددة على الخادم.
• قابل للاستبطان (Introspective): واجهات برمجة تطبيقات GraphQL قابلة للاستبطان بطبيعتها. يمكن للعملاء استعلام المخطط نفسه لاكتشاف الأنواع والحقول والاستعلامات والتعديلات والاشتراكات المتاحة، مما يسهل الاستكشاف وإنشاء العملاء الديناميكي.

سلبيات GraphQL:

• التعقيد: قد يكون إعداد وإدارة خادم GraphQL أكثر تعقيدًا مقارنة بواجهات برمجة تطبيقات REST البسيطة، خاصة فيما يتعلق بتنفيذ منطق المحلل، وتصميم المخطط، وتحسين الأداء.
• التخزين المؤقت (Caching): آليات التخزين المؤقت لـ HTTP أقل وضوحًا لتطبيقها مباشرة في GraphQL مقارنة بالتخزين المؤقت القائم على الموارد في REST. بينما توجد حلول تخزين مؤقت متطورة على جانب العميل (مثل Apollo Client أو Relay)، يتطلب التخزين المؤقت على جانب الخادم والوسيط استراتيجيات مختلفة، ويمكن أن يكون التخزين المؤقت على مستوى الحقل معقدًا.
• تحميل الملفات (File Uploads): لا يتعامل مواصفات GraphQL بشكل أصلي مع تحميل الملفات. يتطلب هذا عادة حلولًا بديلة، مثل استخدام نقاط نهاية REST منفصلة لمعالجة الملفات أو تنفيذ مكتبات معالجة الطلبات متعددة الأجزاء جنبًا إلى جنب مع GraphQL.
• تحديد المعدل (Rate Limiting): قد يكون تطبيق تحديد المعدل الفعال أكثر تعقيدًا لأن "تكلفة" أو كثافة موارد استعلام GraphQL ليست واضحة على الفور بمجرد النظر إليه؛ يمكن أن يكون الاستعلام المتداخل بعمق أو المعقد مكلفًا جدًا للتنفيذ. هذا يتطلب غالبًا آليات تحليل تكلفة الاستعلام.
• منحنى التعلم (Learning Curve): هناك منحنى تعلم مرتبط بفهم مفاهيم GraphQL، وإتقان أفضل ممارسات تصميم المخطط، وإتقان لغة الاستعلام نفسها.
• مزالق الأداء (Performance Pitfalls): يمكن أن تؤدي المحللات المكتوبة بشكل سيء أو الاستعلامات المعقدة بشكل مفرط والمتداخلة بعمق إلى مشاكل في الأداء، مثل مشكلة N+1 (حيث يؤدي جلب قائمة من العناصر وأبنائها إلى استعلام واحد للقائمة وN استعلامًا إضافيًا لأبناء كل عنصر)، إذا لم يتم التعامل معها بعناية باستخدام تقنيات مثل محملات البيانات (data loaders).

متى تستخدم GraphQL:

GraphQL مناسب بشكل خاص للتطبيقات ذات العملاء المتنوعين، مثل تطبيقات الويب، وتطبيقات الهاتف المحمول، وأجهزة إنترنت الأشياء، وكلها قد تكون لها متطلبات بيانات مختلفة. يتألق في الحالات التي يكون فيها تقليل نقل البيانات وتقليل عدد جولات الذهاب والإياب عبر الشبكة أمرًا حاسمًا، على سبيل المثال، في تطبيقات الهاتف المحمول التي تعمل على شبكات بطيئة أو غير موثوقة. بالنسبة للأنظمة المعقدة حيث يحتاج العملاء إلى جلب البيانات من مصادر أساسية متعددة أو التنقل في علاقات موارد متداخلة بعمق، يقدم GraphQL حلاً أنيقًا. إذا كان عقد واجهة برمجة تطبيقات قوي النوع، وقدرات توثيق ذاتي قوية، وقابلية تطور واجهة برمجة التطبيقات ذات قيمة عالية، يوفر GraphQL هذه الفوائد. يمكن للتطبيقات التي تتطلب تحديثات في الوقت الفعلي عبر الاشتراكات الاستفادة من دعم GraphQL الأصلي لهذه الميزة. في النهاية، GraphQL هو خيار ممتاز عندما تريد منح العملاء المزيد من القوة والمرونة في كيفية جلب البيانات، وتخصيص الطلبات لتلبية احتياجاتهم الدقيقة.

RPC مقابل REST مقابل GraphQL: نظرة مقارنة