GraphQL و
REST هما
نموذجان يستخدمان لإنشاء واجهات برمجة التطبيقات لتطبيقات الويب.
REST عبارة عن مجموعة من المعرفات الفريدة (عناوين URL) التي تستخدمها التطبيقات لطلب البيانات وإرسالها.
GraphQL هي لغة استعلام تتيح لتطبيقات العميل تحديد البيانات التي يحتاجون إليها بدقة من نقطة نهاية واحدة.
هذه تقنيات ذات صلة ، يتم استخدامها بشكل أساسي لنفس الأشياء (أو يمكنها التعايش) ، لكنها مختلفة تمامًا.
يبدو قليلا جديدة ، أليس كذلك؟ دعنا نوضح اختلافاتهم بطريقة أكثر إثارة للاهتمام ، والتي يمكن أن تساعدك على فهم GraphQL بشكل أفضل ، وربما مجرد تسليه.
هل أنت في حفل كوكتيل
جئت إلى الحفلة لإجراء الشبكات ، لذلك تحتاج إلى معلومات حول الأشخاص من حولك. قريب هناك خمسة ضيوف آخرين.
علامات الأسماء هي كما يلي:
ريتش ريست
صديق ريتشي
صاحب عمل ريتشي ريست
جورجيا GraphQL
لكونك أحد رواد الحفلات النشطين والاجتماعيين ، توجه مباشرة إلى ريتشي ريست وتقول: "مرحبًا ، أنا آدم إبريل ، ومن أنت؟" إجابة ريتشي ريستا هي:
{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... 20 other things about Richy REST }
لقد فكرت في نفسك ، "واو ، الكثير من المعلومات على الفور". في محاولة لتجنب الصمت المحرج ، تتذكر أن ريتشي ريست ذكر أنه يعمل ، ويسأل: "أين تعمل؟"
والمثير للدهشة أن ريتشي ريست ليس لديه فكرة عن مكان عمله. ربما صاحب العمل ريتشي ريستا في معرفة؟
أنت تطرح نفس السؤال على صاحب العمل ريتشي ريستا ، الذي يسعده الإجابة على سؤالك:
{ company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... 20 other things about Richy REST Employer }
في هذه المرحلة أنت بالفعل استنفدت. أنت لا تريد حتى مقابلة صديق ريتشي ريستا! قد يستغرق الأمر إلى الأبد ، وإهدار كل طاقتك ، وإلى جانب ذلك ، لم يعد لديك وقت.
ومع ذلك ، جورجيا GrafKewel تقف قريبة جدا وتقرر الدردشة معها.
"مرحبا ، ما اسمك؟"
{ name: "Georgia GraphQL" }
"من أين أنت وكم عمرك؟"
{ hometown: "Pleasant-Ville", age: 28 }
"كم من الهوايات والأصدقاء لديك وما هو اسم أصدقائك؟"
{ hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...etc ] }
جورجيا GrafKewEl لا تصدق ، بوضوح التعبير عن الأفكار وموجزة ودقيقة. أنت بالتأكيد تريد تبادل بطاقات العمل معها والعمل معًا في مشاريع مستقبلية.
تتضمن هذه القصة تجربة المطورين الذين يعملون مع GraphQL و REST. يتيح GraphQL للمطورين صياغة ما يريدون باستخدام استعلام أنيق والحصول على ما يحددونه فقط استجابة. هذه الاستعلامات ديناميكية ، لذلك لا يلزم سوى نقطة نهاية واحدة. على العكس من ذلك ، يحتوي REST على إجابات محددة مسبقًا ويتطلب من التطبيقات استخدام نقاط نهاية متعددة للاستعلام الكامل عن البيانات.
مع الانتهاء من الاستعارات. هيا بنا إلى العمل
لمزيد من الكشف عن المفاهيم المقدمة في استعارة الطرف ، ننتقل بالتحديد إلى اثنين من القيود التي غالبا ما تنشأ عند استخدام REST.
1. يضرب متعددة في الحصول على الموارد ذات الصلةغالبًا ما تتطلب إدارة البيانات لتطبيقات الجوال وتطبيقات الويب موارد ومجموعات بيانات ذات صلة وبالتالي ، يمكن أن يستلزم الحصول على البيانات باستخدام واجهة برمجة تطبيقات REST طلبات عديدة لنقاط نهاية متعددة. على سبيل المثال ، يمكن تقديم طلب نشر والمؤلف المرتبط به من خلال طلبين لنقاط نهاية مختلفة:
someServer.com/authors/:id someServer.com/posts/:id
المكالمات المتكررة إلى API تؤثر على أداء التطبيق. هذا الأمر أكثر أهمية بالنسبة للأجهزة ذات النطاق الترددي المنخفض (على سبيل المثال ، الساعات الذكية ، إنترنت الأشياء ، الأجهزة المحمولة القديمة ، إلخ).
2. الإفراط في الجلب وقلة الجلبالإفراط في الجلب / الجلب أمر لا مفر منه عند استخدام RESTful API. باستخدام المثال أعلاه ، تسترجع نقطة نهاية domainName.com/posts/:id البيانات لسجل معين. يتكون كل إدخال من سمات مثل المعرف والنص الأساسي والعنوان وتاريخ النشر ومؤلف المؤلف وغيرها. في REST ، يتم تحديد الاستجابة مسبقًا ويتم إرجاع كائن البيانات نفسه دائمًا.
في المواقف التي يكون فيها عنوان ونص التسجيل مطلوبين فقط ، يحدث الإفراط في جلب البيانات المرسلة عبر الشبكة أكثر من المستخدم الفعلي.
عندما يكون المنشور بأكمله مطلوبًا جنبًا إلى جنب مع البيانات ذات الصلة حول مؤلفه ، فهناك نقص في جلب البيانات نظرًا لأن البيانات التي يتم إرسالها عبر الشبكة أقل من التي يتم استخدامها فعليًا. يؤدي عدم كفاية جلب البيانات إلى زيادة عدد طلبات واجهة برمجة التطبيقات ، ونتيجة لذلك ، الاستخدام المفرط لموارد الإنترنت.
استفسارات العميل مع GraphQL
يمثل GraphQL أسلوبًا فريدًا يمنح مرونة هائلة لتطبيقات العميل. مع GraphQL ، يتم إرسال الطلب إلى API الخاص بك ، ويتم إرجاع ما تحتاجه بالضبط - لا أكثر ولا أقل - في طلب واحد. يتم إرجاع نتائج الاستعلام بنفس النموذج مثل الاستعلام نفسه ، مما يضمن إمكانية التنبؤ بهيكل الاستجابة دائمًا. تتيح هذه العوامل تشغيل التطبيقات بشكل أسرع وتكون أكثر استقرارًا
لأنها تتحكم في البيانات التي تتلقاها ، وليس الخادم.
"يتم إرجاع النتائج في نفس شكل الاستعلامات"
{ myFriends(first: 2) { items { name age } } }
/* Response */ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } }
التحقق من الواقع
الآن ربما تعتقد أن العمل مع GraphQL سهل مثل تقطيع الزبدة الدافئة بسيف الساموراي. قد يكون هذا صحيحًا لمطوري الواجهة الأمامية. ومع ذلك ، عندما يتعلق الأمر بتكوين جانب الخادم ، يتعين على شخص ما القيام بالعمل الأكثر صعوبة. بذل صديقنا Georgia GrafKewEl الكثير من الجهد ليصبح محترفًا أنيقًا.
يستغرق إنشاء واجهة برمجة تطبيقات GraphQL من جانب الخادم وقتًا وجهدًا وتجربة. ومع ذلك ، فإن أولئك المستعدين للاختبار قادرون على التعامل مع هذا. هناك العديد من الطرق المختلفة للقيام بذلك ، على سبيل المثال:
لوحدك : إذا كنت تريد فعل كل شيء بنفسك ، فحاول بناء واجهة برمجة تطبيقات GraphQL مع الحزم. باستخدام القضبان؟ جرب graphql-ruby. الحب Node.js؟ حاول التعبير عن graphql.
من خلال المساعدة : إذا كانت تهيئة الاستضافة المرنة أولوية بالنسبة لك ، فيمكن أن يساعدك شيء مثل Graph.cool في البدء في مشروع GraphQL.
لحظة : تعبت من كتابة قالب CRUD وتريد أن تبدأ بسرعة؟ يوفر 8base واجهة برمجة تطبيقات GraphQL الفورية وخلفية للخادم يمكن تمديدها.
في الختام
بالنسبة لخدمات الويب ، كانت REST خطوة مهمة إلى الأمام ، مما سهل إنشاء واجهات برمجة التطبيقات للوصول إلى الموارد الضرورية. ومع ذلك ، لم يأخذ تصميمها في الاعتبار الانتشار الحالي للأجهزة المحمولة ، مع وجود قيود مختلفة على حجم ومتطلبات تنزيل البيانات. أدى هذا الإغفال إلى تزايد شعبية GraphQL ، التي جعلها Facebook مفتوحة المصدر في عام 2015 ، ويرجع ذلك في المقام الأول إلى المرونة التي تمنحها للمطورين المتقدمين. يعد العمل مع GraphQL تجربة رائعة لكل من المطورين والفرق الفردية.