جعل GraphQL تعمل في WordPress

يبدو أن WordPress مقطوع الرأس أصبح رائجًا مؤخرًا ، مع حدوث العديد من التطورات الجديدة في الأسابيع القليلة الماضية فقط. أحد أسباب الانفجار في النشاط هو إصدار الإصدار 1.0 من WPGraphQL ، وهو خادم GraphQL لـ WordPress.

يوفر WPGraphQL واجهة برمجة تطبيقات GraphQL: طريقة لجلب البيانات من موقع WordPress الإلكتروني ونشر البيانات عليه. إنها تمكننا من فصل تجربة إدارة المحتوى الخاص بنا ، والتي تتم عبر WordPress ، عن عرض موقع الويب ، حيث يمكننا استخدام مكتبة إطار العمل الذي نختاره (React ، Vue.js ، Gatsby ، Next.js ، أو اي شيء اخر).

حتى وقت قريب ، كان WPGraphQL هو خادم GraphQL الوحيد لـ WordPress. ولكن الآن يتوفر مكون إضافي آخر: GraphQL API for WordPress ، من تأليفه أنا.

يخدم هذان المكونان الإضافيان نفس الغرض: توفير واجهة برمجة تطبيقات GraphQL إلى موقع ويب WordPress. قد تتساءل: لماذا يوجد مكون إضافي آخر عندما يكون هناك بالفعل WPGraphQL؟ هل هذين الملحقين يفعلان نفس الشيء؟ أم هم لمواقف مختلفة؟

دعني أقول هذا أولاً: WPGraphQL يعمل بشكل رائع. لم أقم ببناء المكون الإضافي الخاص بي بسبب أي مشكلة به.

لقد قمت بإنشاء GraphQL API لـ WordPress لأنني كنت أعمل على محرك لاسترداد البيانات بكفاءة ، وهو ما كان مناسبًا جدًا لـ GraphQL. فقلت لنفسي ، "لما لا؟" ، وقمت ببنائه. (وأيضًا سببان آخران.)

يحتوي المكونان الإضافيان على هياكل مختلفة ، مما يمنحهما خصائص مختلفة ، مما يسهل إنجاز مهام معينة باستخدام أحد المكونات الإضافية أو الأخرى.

في هذه المقالة ، سأصف ، من وجهة نظري الخاصة ولكن بشكل موضوعي قدر الإمكان ، متى يكون WPGraphQL هو السبيل للذهاب وعندما يكون GraphQL API for WordPress خيارًا أفضل.

استخدم WPGraphQL إذا: باستخدام Gatsby

إذا كنت تقوم بإنشاء موقع ويب باستخدام Gatsby ، فهناك خيار واحد فقط: WPGraphQL.

والسبب هو أن WPGraphQL هو الوحيد الذي يحتوي على البرنامج المساعد لمصدر Gatsby لـ WordPress. بالإضافة إلى ذلك ، تم تعيين مُنشئ WPGraphQL ، Jason Bahl ، حتى وقت قريب من قبل Gatsby ، لذلك يمكننا أن نثق تمامًا في أن هذا المكون الإضافي سوف يناسب احتياجات Gatsby.

يتلقى Gatsby جميع البيانات من موقع WordPress الإلكتروني ، ومن ذلك الحين فصاعدًا ، سيكون منطق التطبيق بالكامل من جانب Gatsby ، وليس على WordPress. وبالتالي ، لن تحدث أي إضافات إلى @stream (مثل الإضافات المحتملة لتوجيهاتstream أو @defer ) فرقًا كبيرًا.

WPGraphQL هي بالفعل جيدة كما يحتاجها Gatsby.

استخدم WPGraphQL إذا: باستخدام أحد الأطر الجديدة مقطوعة الرأس

كما ذكرت ، كانت هناك في الآونة الأخيرة موجة من النشاط في مساحة WordPress بلا رأس فيما يتعلق بالعديد من الأطر الجديدة والمشاريع المبدئية ، وكلها تستند إلى Next.js:

• أنشأ كولبي فايوك Next.js WordPress Starter.
• أطلقت WebDevStudios برنامج Next.js WordPress Starter الخاص به.
• قام WP Engine بإنشاء إطار عمل WordPress بدون رأس ، والذي يدعم خدمته لاستضافة ونشر مواقع WordPress بدون رأس.

إذا كنت بحاجة إلى استخدام أي من هذه الأطر الجديدة بدون رأس ، فستحتاج إلى استخدام WPGraphQL ، لأنها كلها مبنية فوق هذا المكون الإضافي.

هذا أمر مؤسف بعض الشيء: أحب حقًا واجهة برمجة تطبيقات GraphQL لـ WordPress لتكون قادرة على تشغيلها أيضًا. ولكن لكي يحدث ذلك ، يجب أن تعمل هذه الأطر مع GraphQL عبر واجهة ، حتى نتمكن من تبديل خوادم GraphQL.

أنا آمل إلى حد ما أن أي من هذه الأطر سوف تضع مثل هذه الواجهة في مكانها. سألت عن ذلك في لوحة مناقشة إطار عمل WordPress بدون رأس وقيل لي أنه يمكن النظر فيه. سألت أيضًا في لوحة مناقشة Next.js WordPress Starter الخاصة بـ WebDevStudios ، ولكن للأسف ، تم حذف سؤالي على الفور ، دون رد. (غير مشجع ، أليس كذلك؟)

إذن WPGraphQL هو إذن ، حاليًا وفي المستقبل المنظور.

استخدم إما (أو لا تستخدم أيًا منهما) في حالة: استخدام الواجهة

الواجهة هي إطار عمل React لـ WordPress. يمكّنك من إنشاء تطبيق قائم على React تتم إدارته في النهاية الخلفية عبر WordPress. حتى إنشاء منشورات مدونة باستخدام محرر WordPress يتم دعمه خارج الصندوق.

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

هذه هي الطريقة التي تتميز بها Frontity بالذكاء: المكون الإضافي المصدر هو واجهة للتواصل مع مزود البيانات. حاليًا ، المكون الإضافي الوحيد المتاح هو المكون الإضافي لواجهة برمجة تطبيقات WordPress REST. ولكن يمكن لأي شخص تنفيذ مكون إضافي مصدر إما لـ WPGraphQL أو GraphQL API لـ WordPress. (هذا هو النهج الذي أرغب في تكرار الأطر المستندة إلى Next.js.)

الخلاصة : لا يوفر WPGraphQL ولا واجهة برمجة تطبيقات GraphQL أي ميزة على الآخر للعمل مع Frontity ، وكلاهما يتطلب بعض الجهد الأولي لتوصيلهما.

استخدم WPGraphQL إذا: إنشاء موقع ثابت

في القسمين الأولين ، كانت النتيجة واحدة: استخدم WPGraphQL. لكن ردي على هذا الاستنتاج كان مختلفًا: بينما كنت مع غاتسبي لم أشعر بأي ندم ، مع Next.js شعرت بأنني مضطر لفعل شيء حيال ذلك.

لماذا هذا؟

الفرق هو أنه في حين أن Gatsby هو مجرد مولد موقع ثابت ، فإن Next.js يمكنه تشغيل مواقع الويب الثابتة والمباشرة.

لقد ذكرت أن WPGraphQL جيد بالفعل بما يكفي لـ Gatsby. يمكن بالفعل توسيع هذا البيان: WPGraphQL جيد بالفعل بما يكفي لأي مولد موقع ثابت . بمجرد حصول مُنشئ الموقع الثابت على البيانات من موقع WordPress الإلكتروني ، يتم تسويتها إلى حد كبير باستخدام WordPress.

حتى إذا كانت واجهة برمجة تطبيقات GraphQL لـ WordPress تقدم ميزات إضافية ، فمن المرجح ألا تحدث فرقًا في منشئ الموقع الثابت.

وبالتالي ، نظرًا لأن WPGraphQL جيد بالفعل بما يكفي ، وقد قام بتعيين مخطط GraphQL بالكامل (والذي لا يزال قيد التنفيذ لواجهة GraphQL API لـ WordPress) ، فإن WPGraphQL هو الخيار الأنسب الآن وفي المستقبل المنظور.

استخدم واجهة برمجة تطبيقات GraphQL في حالة: استخدام GraphQL في موقع ويب مباشر (أي غير ثابت)

الآن ، يتغير الموقف أعلاه إذا أردنا أن تقوم GraphQL بجلب البيانات من موقع ويب مباشر ، مثل عند تشغيل تطبيق جوال أو التخطيط لبيانات في الوقت الفعلي على موقع ويب (على سبيل المثال ، لعرض التحليلات) أو الجمع بين النهجين الثابت والمباشر على نفس الموقع.

على سبيل المثال ، لنفترض أننا أنشأنا مدونة ثابتة بسيطة باستخدام أحد إطارات Next.js ، ونريد السماح للمستخدمين بإضافة تعليقات إلى منشورات المدونة. كيف ينبغي التعامل مع هذه المهمة؟

لدينا خياران: ثابت ومباشر (أو ديناميكي). إذا اخترنا ثابتًا ، فسيتم تقديم التعليقات مع بقية الموقع. وبعد ذلك ، كلما تمت إضافة تعليق ، يجب علينا تشغيل خطاف ويب لإعادة إنشاء موقع الويب وإعادة نشره.

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

في هذه الحالة ، سيكون من المنطقي عرض موقع الويب بشكل ثابت بدون تعليقات ، ثم استرداد التعليقات من موقع مباشر وعرضها ديناميكيًا في العميل.

لهذا ، يوصى باستخدام Next.js على Gatsby. يمكنه التعامل بشكل أفضل مع النهجين الثابت والحي ، بما في ذلك دعم المخرجات المختلفة للمستخدمين ذوي القدرات المختلفة.

العودة إلى مناقشة GraphQL: لماذا أوصي بـ GraphQL API لـ WordPress عند التعامل مع البيانات الحية؟ أفعل ذلك لأن خادم GraphQL يمكن أن يكون له تأثير مباشر على التطبيق ، خاصة من حيث السرعة والأمان .

بالنسبة إلى موقع ويب ثابت تمامًا ، يمكن الحفاظ على خصوصية موقع WordPress الإلكتروني (قد يكون موجودًا حتى على الكمبيوتر المحمول الخاص بالمطور) ، لذلك فهو آمن. ولن ينتظر المستخدم أي استجابة من الخادم ، لذا فإن السرعة ليست بالضرورة ذات أهمية حاسمة.

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

في هذا الصدد ، تتمتع GraphQL API for WordPress ببعض المزايا التي تتفوق على WPGraphQL .

تقوم WPGraphQL بتنفيذ إجراءات أمنية ، مثل تعطيل الاستبطان افتراضيًا. لكن واجهة برمجة تطبيقات GraphQL لـ WordPress تذهب إلى أبعد من ذلك ، من خلال تعطيل نقطة النهاية الفردية افتراضيًا (جنبًا إلى جنب مع العديد من الإجراءات الأخرى). هذا ممكن لأن GraphQL API for WordPress تقدم استعلامات مستمرة أصلاً.

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

هذه الأسباب تجعل GraphQL API for WordPress أكثر ملاءمة للتعامل مع مواقع الويب الحية.

استخدم واجهة برمجة تطبيقات GraphQL في حالة: الكشف عن بيانات مختلفة لمستخدمين أو تطبيقات مختلفة

WordPress هو نظام إدارة محتوى متعدد الاستخدامات ، قادر على إدارة المحتوى لتطبيقات متعددة ويمكن الوصول إليه من قبل أنواع مختلفة من المستخدمين.

اعتمادًا على السياق ، قد نحتاج إلى واجهات برمجة تطبيقات GraphQL الخاصة بنا لعرض بيانات مختلفة ، مثل:

• كشف بيانات معينة للمستخدمين المدفوعين ولكن ليس للمستخدمين بدون أجر ،
• كشف بيانات معينة لتطبيق الهاتف ولكن ليس إلى موقع الويب.

لفضح بيانات مختلفة ، نحتاج إلى توفير إصدارات مختلفة من مخطط GraphQL .

يسمح لنا WPGraphQL بتعديل المخطط (على سبيل المثال ، يمكننا إزالة حقل مسجل). لكن العملية ليست مباشرة: يجب ترميز تعديلات المخطط ، وليس من السهل فهم من يقوم بالوصول إلى ماذا وأين (على سبيل المثال ، ستظل جميع المخططات متاحة ضمن نقطة النهاية الفردية ، /graphql ).

في المقابل ، تدعم GraphQL API for WordPress حالة الاستخدام هذه أصلاً: فهي توفر نقاط نهاية مخصصة ، والتي يمكن أن تعرض بيانات مختلفة لسياقات مختلفة ، مثل:

• /graphql/mobile-app و /graphql/website ،
• /graphql/pro-users و /graphql/regular-users .

يتم تكوين كل نقطة نهاية مخصصة عبر قوائم التحكم في الوصول ، لتوفير حقل وصول مستخدم دقيق حسب الحقل ، بالإضافة إلى وضع واجهة برمجة التطبيقات العامة والخاصة لتحديد ما إذا كانت البيانات الوصفية للمخطط متاحة للجميع أو للمستخدمين المصرح لهم فقط.

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

توفر واجهة برمجة تطبيقات GraphQL لـ WordPress ، على ما أعتقد ، حلاً طبيعيًا لحالة الاستخدام هذه.

استخدم واجهة برمجة تطبيقات GraphQL في حالة: التفاعل مع الخدمات الخارجية

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

الآن ، ما هي أفضل طريقة تتيح لـ GraphQL التواصل مع الخدمات الخارجية؟ في رأيي ، من الأفضل تحقيق ذلك من خلال التوجيهات ، التي يتم تطبيقها عند إنشاء البيانات أو استردادها (على عكس كيفية عمل مرشحات WordPress).

لا أعرف جيدًا كيف يتفاعل WPGraphQL مع الخدمات الخارجية ، لأن وثائقه لا تذكر ذلك ، وقاعدة الكود لا تقدم مثالًا على أي توجيه أو يوثق كيفية إنشاء واحد.

في المقابل ، تمتلك GraphQL API for WordPress دعمًا قويًا للتوجيهات . يتم تنفيذ كل توجيه في استعلام مرة واحدة فقط في المجموع (على عكس مرة واحدة لكل حقل و / أو كائن). تتيح هذه الإمكانية الاتصال الفعال للغاية مع واجهات برمجة التطبيقات الخارجية ، كما أنها تدمج واجهة برمجة تطبيقات GraphQL في سحابة من الخدمات.

على سبيل المثال ، يوضح هذا الاستعلام استدعاء Google Translate API عبر التوجيه @translate ، لترجمة عناوين ومقتطفات العديد من المنشورات من الإنجليزية إلى الإسبانية. تتم ترجمة كافة الحقول الخاصة بكافة المنشورات معًا ، في مكالمة واحدة.

واجهة برمجة تطبيقات GraphQL لـ WordPress هي خيار طبيعي لحالة الاستخدام هذه.

ملاحظة : في الحقيقة ، المحرك الذي تستند إليه GraphQL API for WordPress ، وهو GraphQL by PoP ، وقد تم تصميمه خصيصًا لتوفير إمكانات متقدمة لمعالجة البيانات. هذه واحدة من خصائصها المميزة. للحصول على مثال متطرف لما يمكن تحقيقه ، راجع دليل "إرسال رسالة إخبارية مترجمة ، مستخدم حسب المستخدم".

استخدم WPGraphQL إذا كنت تريد مجتمع دعم

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

في حالتي ، ما زلت أسعى جاهدًا لإنشاء مجتمع من المستخدمين حول GraphQL API for WordPress ، وهي بالتأكيد ليست قريبة من WPGraphQL.

استخدم واجهة برمجة تطبيقات GraphQL إذا كنت تحب الابتكار

أسمي GraphQL API for WordPress خادم GraphQL "استشرافي". والسبب هو أنني غالبًا ما أتصفح قائمة الطلبات لمواصفات GraphQL وأنفذ بعضها في وقت مبكر جدًا (خاصة تلك التي أشعر ببعض التقارب معها أو يمكنني دعمها بجهد ضئيل).

اعتبارًا من اليوم ، تدعم GraphQL API for WordPress العديد من الميزات المبتكرة (مثل تنفيذ استعلامات متعددة ومساحة أسماء المخططات) ، والتي يتم تقديمها كاشتراك ، وهناك خطط للمزيد.

استخدم WPGraphQL إذا: كنت بحاجة إلى مخطط كامل

قامت WPGraphQL بتعيين نموذج بيانات WordPress بالكامل ، بما في ذلك:

• المشاركات والصفحات ،
• أنواع المنشورات المخصصة ،
• الفئات والعلامات ،
• التصنيفات الجمركية ،
• وسائل الإعلام،
• القوائم ،
• الإعدادات،
• المستخدمين ،
• تعليقات،
• الإضافات
• الموضوعات ،
• الحاجيات.

تعمل واجهة برمجة تطبيقات GraphQL لـ WordPress على تعيين نموذج البيانات بشكل تدريجي مع كل إصدار جديد. اعتبارًا من اليوم ، تشمل القائمة:

• المشاركات والصفحات ،
• أنواع المنشورات المخصصة ،
• الفئات والعلامات ،
• التصنيفات الجمركية ،
• وسائل الإعلام،
• القوائم ،
• الإعدادات،
• المستخدمين ،
• تعليقات.

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

استخدم WPGraphQL إذا: كنت بحاجة إلى ملحقات

تقدم WPGraphQL امتدادات للعديد من المكونات الإضافية ، بما في ذلك Advanced Custom Fields و WooCommerce و Yoast و Gravity Forms.

تقدم GraphQL API for WordPress امتدادًا لمدير الأحداث ، وستستمر في إضافة المزيد بعد إصدار الإصدار 1.0 من البرنامج المساعد.

استخدم إما إذا: إنشاء قوالب لمحرر WordPress

يعمل كل من WPGraphQL و GraphQL API for WordPress حاليًا على دمج GraphQL مع Gutenberg.

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

تمتلك GraphQL API for WordPress أيضًا نهجًا للتكامل مع Gutenberg ، استنادًا إلى إستراتيجية "الإنشاء مرة واحدة ، والنشر في كل مكان". يقوم باستخراج بيانات الكتلة من المحتوى المخزن ، ويستخدم نوع Block واحد لتمثيل جميع الكتل. هذا النهج يمكن أن يتجنب الحاجة إلى التسجيل من جانب الخادم المقترح.

يمكن اعتبار حل WPGraphQL مؤقتًا ، لأنه سيعتمد على قبول المجتمع لاستخدام التسجيل من جانب الخادم ، ولا نعرف ما إذا كان ذلك سيحدث أم لا.

بالنسبة إلى GraphQL API for WordPress ، سيعتمد الحل كليًا على نفسه ، وهو بالفعل عمل قيد التقدم.

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

استخدم واجهة برمجة تطبيقات GraphQL في حالة: توزيع الكتل عبر مكون إضافي

لقد توصلت إلى إدراك: لا يبدو أن العديد من المكونات الإضافية (إن وجدت) تستخدم GraphQL في WordPress.

لا تفهموني خطأ: لقد تجاوز WPGraphQL 10000 عملية تثبيت. لكنني أعتقد أن هذه هي في الغالب منشآت لتشغيل Gatsby (من أجل تشغيل Gatsby) أو لتشغيل Next.js (من أجل تشغيل أحد أطر العمل بدون رأس).

وبالمثل ، يحتوي WPGraphQL على العديد من الامتدادات ، كما وصفت سابقًا. لكن تلك الامتدادات هي فقط: الامتدادات. إنها ليست مكونات إضافية قائمة بذاتها.

على سبيل المثال ، يعتمد امتداد WPGraphQL لـ WooCommerce على كل من الإضافات WPGraphQL و WooCommerce. إذا لم يتم تثبيت أي منهما ، فلن يعمل الامتداد ، ولا بأس بذلك. لكن WooCommerce ليس لديه خيار الاعتماد على WPGraphQL من أجل العمل ؛ وبالتالي ، لن يكون هناك GraphQL في المكون الإضافي WooCommerce.

ما أفهمه هو أنه لا توجد مكونات إضافية تستخدم GraphQL لتشغيل وظائف WordPress نفسها أو ، على وجه التحديد ، لتشغيل كتل Gutenberg الخاصة بهم.

السبب بسيط: لا تعد WPGraphQL ولا واجهة برمجة تطبيقات GraphQL لـ WordPress جزءًا من جوهر WordPress. وبالتالي ، لا يمكن الاعتماد على GraphQL بالطريقة التي تعتمد بها المكونات الإضافية على WordPress 'REST API. نتيجة لذلك ، قد تستخدم المكونات الإضافية التي تنفذ كتل Gutenberg فقط REST لجلب البيانات من كتلها ، وليس GraphQL.

على ما يبدو ، فإن الحل هو انتظار إضافة حل GraphQL (على الأرجح WPGraphQL) إلى نواة WordPress. لكن من يدري كم من الوقت سيستغرق ذلك؟ ستة أشهر؟ سنة؟ سنتان؟ طويل؟

نحن نعلم أنه يتم النظر في WPGraphQL لجوهر WordPress لأن Matt Mullenweg قد ألمح إليها. ولكن يجب أن تحدث أشياء كثيرة قبل ذلك الحين: رفع الحد الأدنى من إصدار PHP إلى 7.1 (مطلوب بواسطة كل من WPGraphQL وواجهة برمجة تطبيقات GraphQL لـ WordPress) ، فضلاً عن وجود فصل واضح وفهم وخريطة طريق للوظائف التي ستعتمدها GraphQL.

(التحرير الكامل للموقع ، قيد التطوير حاليًا ، يعتمد على REST. ماذا عن الميزة الرئيسية التالية ، الكتل متعددة اللغات ، التي سيتم تناولها في المرحلة 4 من Gutenberg؟ إذا لم يكن الأمر كذلك ، فما الميزة التي ستكون؟)

بعد شرح المشكلة ، دعنا نفكر في حل محتمل - حل لا يحتاج إلى الانتظار!

قبل أيام قليلة ، كان لدي إدراك آخر: من GraphQL API لقاعدة كود WordPress ، يمكنني إنتاج إصدار أصغر ، يحتوي فقط على محرك GraphQL ولا شيء آخر (لا توجد واجهة مستخدم ، ولا نقاط نهاية مخصصة ، ولا تخزين مؤقت لـ HTTP ، ولا يوجد تحكم في الوصول ، لا لا شيء). ويمكن توزيع هذا الإصدار باعتباره تبعية لـ Composer ، بحيث يمكن للمكونات الإضافية تثبيته لتشغيل كتلهم الخاصة.

مفتاح هذا النهج هو أن هذا المكون يجب أن يكون ذا استخدام محدد للمكوِّن الإضافي ، وليس لمشاركته مع أي شخص آخر. خلافًا لذلك ، قد يقوم مكونان إضافيان يشيران إلى هذا المكون بتعديل المخطط بطريقة تتجاوز كل منهما الأخرى.

لحسن الحظ ، قمت مؤخرًا بحل تحديد نطاق واجهة برمجة تطبيقات GraphQL لـ WordPress. لذلك ، أعلم أنني قادر على تحديد نطاقه بالكامل ، وإنتاج إصدار لا يتعارض مع أي كود آخر على الموقع.

هذا يعني أنه سيعمل مع أي مجموعة من الأحداث :

• إذا كان المكون الإضافي الذي يحتوي على المكون هو الوحيد الذي يستخدمه ؛
• إذا تم أيضًا تثبيت GraphQL API for WordPress على نفس الموقع ؛
• إذا تم تثبيت مكون إضافي آخر يقوم أيضًا بتضمين هذا المكون على موقع الويب ؛
• إذا كان هناك مكونان إضافيان يشيران إلى المكون يشيران إلى نفس إصدار المكون أو إلى مكونات مختلفة.

في كل موقف ، سيكون للمكوِّن الإضافي محرك GraphQL الخاص والمستقل ذاتيًا والذي يمكنه الاعتماد عليه بالكامل لتشغيل كتل Gutenberg الخاصة به (ولا داعي للخوف من أي تعارض).

يجب أن يكون هذا المكون ، الذي يُطلق عليه اسم واجهة برمجة تطبيقات GraphQL الخاصة ، جاهزًا في غضون أسابيع قليلة. (لقد بدأت بالفعل في العمل عليها.)

ومن ثم ، فإن توصيتي هي أنه إذا كنت تريد استخدام GraphQL لتشغيل كتل Gutenberg في المكون الإضافي الخاص بك ، فيرجى الانتظار بضعة أسابيع ، ثم تحقق من GraphQL API للأخ الأصغر لـ WordPress ، وهو واجهة برمجة تطبيقات GraphQL الخاصة.

خاتمة

على الرغم من أنني أمتلك بشرة في اللعبة ، أعتقد أنني تمكنت من كتابة مقال موضوعي في الغالب.

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

بشكل عام ، يمكننا تلخيص ما يلي:

• كن ثابتًا مع WPGraphQL ، أو انطلق مباشرة مع GraphQL API لـ WordPress.
• العبها بأمان مع WPGraphQL ، أو استثمر (لتحقيق مكاسب محتملة) في GraphQL API for WordPress.

في ملاحظة أخيرة ، أتمنى إعادة تصميم أطر عمل Next.js لتتبع نفس النهج الذي استخدمته Frontity: حيث يمكنهم الوصول إلى واجهة لجلب البيانات التي يحتاجون إليها ، بدلاً من استخدام التنفيذ المباشر لبعض الحلول المعينة ( الحالي هو WPGraphQL). إذا حدث ذلك ، يمكن للمطورين اختيار الخادم الأساسي الذي يجب استخدامه (سواء كان WPGraphQL ، أو GraphQL API لـ WordPress ، أو بعض الحلول الأخرى التي يتم تقديمها في المستقبل) ، بناءً على احتياجاتهم - من مشروع إلى آخر.

روابط مفيدة

• WPGraphQL: التوثيق ، صفحة التنزيل ، مستودع الأكواد
• واجهة برمجة تطبيقات GraphQL لـ WordPress: الوثائق ، صفحة التنزيل ، مستودع الأكواد
• "ورشة عمل Gatsby WordPress Integration"
  فيديو يوتيوب مع عرض WPGraphQL
• "مقدمة إلى GraphQL API for WordPress"
  فيديو YouTube مع عرض توضيحي لـ GraphQL API لـ WordPress