استضافة WPGraphQL لموقع يحتوي على عنوان URL واحد ولا صفحات.
يقوم WordPress بدون رأس بانهيار الموقع بأكمله في نقطة نهاية واحدة. كل تقنية مبنية حول صفحات التخزين المؤقت تتوقف عن التطبيق ، لأنه لم تعد هناك أي صفحات.
نقطة نهاية واحدة، كل طلب.
تصل جميع الزيارات إلى نفس العنوان الذي يطرح أسئلة مختلفة ، وهو عكس ما تم تصميم ذاكرة التخزين المؤقت للصفحة له.
الردود التي يمكن أن تكون في الواقع مخبأة
استعلام GraphQL هو عبارة عن جسم POST افتراضيًا ، ولا شيء يخزن POSTs. يتم التعامل مع الاستفسارات بحيث يمكن تقديم طلبات متطابقة من ذاكرة التخزين المؤقت بدلاً من إعادة حلها في كل مرة.
سقف على ما يمكن أن تسأل الاستعلام واحد عن
الاستعلام المتداخل بعمق هو طلب واحد يمكنه السير في مجموعة البيانات بالكامل. يتم تعيين حدود العمق والتعقيد ، لذلك لا يمكن لعميل واحد طرح سؤال يجب ألا يجيب الخادم عليه.
حلال التي لا تنتشر في كل حقل
قرار ساذج يتحول قائمة واحدة من خمسين وظيفة في خمسين بحث المؤلف والبحث عن المدى الخمسين. يتم تجميعها ، وهو الفرق بين نقطة النهاية السريعة وبطيئة.
البناء الذي يجلب كل شيء
يتم تجديد الواجهة الأمامية الثابتة عن طريق الاستعلام عن كل عقدة على الموقع في وقت واحد. يتم التعامل مع هذا التشغيل كعبء عمل معروف بدلاً من كونه شذوذًا مروريًا يتم خنقه.
WordPress لا يزال البيانات
يغير الرأس بلا رأس الواجهة الأمامية ، وليس المسؤولية. يتم نسخ قاعدة البيانات والتحميلات احتياطيًا يوميًا تمامًا كما ستكون بالنسبة لموقع تم تقديمه.
المخبأ ليس لديه ما يحمله
خذ بعيدا القوالب وأنت تأخذ بعيدا التخزين المؤقت الصفحة ، التخزين المؤقت للصفحة الكاملة و HTML الحافة. ما تبقى هو نقطة نهاية واحدة تقوم بعمل حقيقي في كل مكالمة.
- استعلامات متطابقة تم تقديمها من ذاكرة التخزين المؤقت
- عمق الاستعلام والتعقيد محدود
- عمليات البحث عن حل الحلول دفعة بدلا من كل حقل
- جلب وقت البناء تعامل كما الحمل المتوقع
التكلفة في المروحة.
استجابة GraphQL تبدو وكأنها طلب واحد وتتصرف مثل عشرات الاستعلامات. ما يقرر السرعة هو عدد تلك التي يتم تجنبها.
ما نغيره لـ WPGraphQL
بدون رأس يزيل الأدوات التي يصل إليها الجميع لأول مرة ، لذلك ينتقل الضبط بالكامل إلى نقطة النهاية.
| الإعداد | ما نضبطه | السبب |
|---|---|---|
| التخزين المؤقت لنقطة النهاية | الاستعلامات المتكررة التي تم تقديمها دون إعادة حل | تصل طلبات GraphQL كهيئات POST ، والتي لا تخزن شيئًا افتراضيًا ، لذلك يكلف الاستعلام المتطابق السعر الكامل في كل مرة يتم فيها طرحه. |
| حدود الاستعلام | السقوف المفروضة على العمق والتعقيد | يمكن لاستعلام متداخل واحد اجتياز مجموعة بيانات كاملة في طلب واحد ، مما يجعل نقطة النهاية مكلفة للغاية لإساءة الاستخدام عن طريق الصدفة أو غير ذلك. |
| حل الخلط | عمليات البحث ذات الصلة مجمعة بدلاً من كل حقل | حل خمسين وظيفة يعني بسذاجة خمسين استعلامات المؤلف والاستعلامات لمدة خمسين، وهذا مروحة التدريجي هو الفرق كله في الأداء مقطوعة الرأس. |
| حركة المرور وقت البناء | تعامل كعبء عمل معروف، وليس خنق كإساءة | يجلب التجديد الثابت كل عقدة في وقت واحد ، والتي تبدو تمامًا مثل الكشط لأي محدد معدل لم يتم إخباره عنه. |
| الاستبطان | مقيد في الإنتاج | إن تفريغ المخطط العام يخبر أي شخص بالضبط ما الذي يطلبه ، ونقطة النهاية هي السطح الوحيد الذي يحتوي عليه موقع بلا رأس. |
أسعار واضحة وبسيطة.
تتضمن كل خطة نقلًا مجانيًا ونسخًا احتياطيًا يوميًا وشهادة SSL ودعمًا على مدار الساعة.
- موقع ووردبريس واحد
- 10 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- الدعم عبر التذاكر
- 5 مواقع ووردبريس
- 50 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- تذاكر دعم ذات أولوية
- 20 مواقع ووردبريس
- 200 غيغابايت من تخزين NVMe
- شهادة SSL مجانية
- نسخ احتياطي يومي
- نشر بنقرة واحدة
- دعم مخصص
الأسئلة الشائعة.
هل يمكن تخزين نقطة نهاية GraphQL مؤقتًا على الإطلاق؟
لماذا موقعي بدون رأس أبطأ من الموقع المقدم؟
هل سيتم الحد من معدل البناء الثابت؟
هل ما زلت بحاجة إلى النسخ الاحتياطية إذا كانت الواجهة الأمامية منفصلة؟
اجعل نقطة النهاية هي الجزء السريع.
حرّك الطرف الخلفي عبر، الهجرة مجانية، والمخطط لم يمس.