CMS مقطوعة الرأس: Gatsby JS مع WordPress

من المعروف أن WordPress يغطي ما يقرب من ثلث أفضل مليون موقع ويب في العالم مع أكثر من 50 ٪ من حصة السوق في أنظمة إدارة المحتوى. في عام 2016 ، قرر WordPress تقديم واجهة برمجة تطبيقات REST لتوفير وصول محسن للتطبيقات الأخرى إلى المحتوى في قاعدة بيانات WordPress. نتيجة لذلك ، تزويد المطورين بالقدرة على الاستفادة من WordPress كنظام CMS مقطوع الرأس.

هذا يعني بالضرورة أن المهندسين لن يقتصروا بعد الآن على استخدام طبقة العرض التقليدية في WordPress (الواجهة الأمامية) ، ولكن يمكنهم الآن استغلال أي تطبيق للواجهة الأمامية لتقديم بياناتهم. في ضوء ذلك ، ستستكشف غالبية هذه المدونة العلاقة بين WordPress و Gatsby.js فيما يتعلق بتأثير Headless CMS.

تاريخ موجز لـ CMS

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

في الأساس ، يعد Monolithic CMS تطبيقًا برمجيًا يتضمن كل ما هو مطلوب لتحرير ونشر المحتوى على الويب. اقتصر أول هذه الأنظمة على مؤسسات مثل EpiServer ، ولكن ظهرت لاحقًا اختلافات مفتوحة المصدر مثل WordPress و Drupal و Joomla. الباقي هو التاريخ حيث اكتسب WordPress أكبر حصة في السوق بمرور الوقت.

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

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

CMSs مقطوعة الرأس

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

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

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

تنفيذ WordPress Headless CMS

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

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

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

WordPress وواجهة برمجة تطبيقات REST

يعتمد نقل الحالة التمثيلية (REST) ​​على بروتوكول HTTP ويوفر دلالات واجهة موحدة لإنشاء وقراءة وتحديث وحذف البيانات (CRUD).

بشكل عام ، يتيح تنفيذ REST API في WordPress للمطورين الوصول إلى البيانات في قاعدة بيانات WordPress عن بُعد عن طريق إرسال واستقبال كائنات JSON (JavaScript Object Notation). وبالتالي ، يوفر هذا للمطورين فرصة إنشاء بيانات WordPress وقراءتها وتحديثها وحذفها من التطبيقات الأخرى التي لم يتم تصميمها باستخدام WordPress. على سبيل المثال ، تطبيقات الويب JavaScript أو تطبيقات الأجهزة المحمولة الأصلية.

ومع ذلك ، كلما تعمقنا في فهم علاقة WordPress CMS بدون رأس مع واجهات برمجة تطبيقات REST و Gatsby ، سنحتاج إلى ملاحظة بعض المفاهيم الأساسية لواجهة برمجة تطبيقات WordPress:

• المسارات ونقاط النهاية: المسارات هي مسارات يمكنك الوصول إليها عبر مكالمة HTTP بينما نقطة النهاية هي طريقة HTTP (مثل get أو post أو put أو delete) يتم تعيينها لهذا المسار.
• الطلب: عند بدء طلب HTTP لمسار REST مسجل ، سيقوم WordPress تلقائيًا بإنشاء كائن طلب. ستحدد البيانات المحددة في الطلب الإجابة التي ستعود إليك.
• الاستجابة: كائن الاستجابة هو البيانات التي تتلقاها مرة أخرى عند تقديم طلب. يمكن أن تتكون من البيانات المطلوبة أو رسائل الخطأ.
• المخطط: يشير المخطط إلى بنية البيانات في نقطة النهاية. يمكن أن تحتوي كل نقطة نهاية على بنية بيانات مختلفة قليلاً أو كبيرة يمكن إرجاعها. وفقًا لذلك ، سيحدد المخطط جميع الخصائص الممكنة التي يمكن لنقطة النهاية إرجاعها وجميع المعلمات الممكنة التي يمكن أن تتلقاها.
• فئات أجهزة التحكم: تتيح فئات أجهزة التحكم للمطورين إدارة نقاط النهاية والمسارات وتسجيلها ، مع السماح لهم أيضًا بمعالجة الطلبات واستخدام المخطط وإنشاء الاستجابات.

إطار التفاعل

نظرًا لأننا ندخل الآن في جوهر علاقة Gatsby.js و WordPress ، لمزيد من السياق ، يتعين علينا فك شفرة هذا المشهد التكنولوجي من الأساسيات التاريخية. تعتبر React مفتاح هذه القصة لأنها مكتبة / إطار عمل JavaScript الأمامي الأسرع نموًا. اشتهر موقع Facebook (مطوروه الأساسيون) ، تستخدم مواقع الويب الكبيرة الأخرى React لواجهتها الأمامية مثل: Airbnb و Netflix و Dropbox و BBC و PayPal و Reddit و Salesforce و Squarespace و Tesla.

وبالتالي ، نظرًا لأن React مكتبة عمليًا (لأنها لا تزال تفتقر إلى الميزات البارزة لإطار عمل كامل) ، فإن هذا يعني أنه يمكن تصميم "أطر عمل" أخرى فوقها. نتيجة لذلك ، أحد هؤلاء هو Gatsby.js.

نقدم لكم غاتسبي

وفقًا لموقع الويب الرئيسي الخاص به ، Gatsby.js هو إطار عمل JavaScript مجاني ومفتوح المصدر يعتمد على React الذي يساعد المطورين على إنشاء مواقع ويب وتطبيقات سريعة. من حيث المبدأ ، يُنشئ Gatsby.js صفحات HTML ثابتة من التطبيقات للتحميل الأولي ، ثم يتابع كتطبيق React أحادي الصفحة (SPA).

سمات Gatsby.js

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

تمنح كل هذه الإمكانات المدمجة للمطورين الأدوات اللازمة لإنشاء أسرع مواقع الويب وتطبيقات الويب الممكنة لأنها تقوم فقط بتحميل HTML و CSS والبيانات وجافا سكريبت الهامة. لذلك ، بمجرد تحميل الصفحة ، يقوم Gatsby بإعداد الموارد مسبقًا للصفحات المرتبطة ، وبالتالي فإن التنقل في الموقع يبدو سريعًا جدًا.

أيضًا ، نظرًا لأن الصفحات يتم إنشاؤها عند التجميع ، قبل التنسيب عبر الإنترنت ، فلن تحتاج إلى خوادم PHP قوية بعد الآن ويمكنك تقديم ملفات ثابتة (HTML و JS و CSS ، مباشرة من تخزين الحاوية). بالإضافة إلى ذلك ، نظرًا لأن Gatsby مدعوم من React ، فستتمكن من تصميم كل شيء بشكل جيد باستخدام المكونات. يسمح هذا الجانب المعياري للمطورين بإعادة استخدام المكونات بسهولة.

تشمل ميزات Gatsby الأخرى المهمة خارج منطقة الجزاء ما يلي:

• مولد موقع ثابت
• الوصول دون اتصال
• الجلب المسبق للصفحات المرتبطة
• التخزين المؤقت للصفحة
• لا توجد تعليمات برمجية غريبة
• تصدير كرمز
• حار إعادة تحميل المحتوى
• كود إعادة التحميل السريع
• المكونات
• ربط البيانات أحادي الاتجاه
• استعلامات بيانات API التعريفية (GraphQL)
• واجهة المستخدم التعريفي
• تحميل الصورة التدريجي
• استجابة تحميل الصور
• تضمين CSS الحرجة
• خط الاستضافة الذاتية
• خادم
• خطوط أنابيب الأصول
• ملحقات CSS (SaSS)
• بناء جملة JavaScript متقدم
• تفاعل النظام البيئي

ملحقات غاتسبي

بشكل أساسي ، تعد مكونات Gatsby الإضافية عبارة عن حزم Node.js تستخدم واجهة برمجة تطبيقات Gatsby. يمكن لهذه المكونات الإضافية إضافة مصادر البيانات وتحويل البيانات إلى تنسيقات أخرى وإضافة خدمات الجهات الخارجية. على الرغم من أن Gatsby.org يحتفظ بمكتبة مكونة إضافية تتضمن العديد من المكونات الإضافية التي تم إنشاؤها بالفعل بواسطة فريق Gatsby الأساسي أو جهات خارجية. من الناحية المثالية ، لتثبيت مكون إضافي لمشروع Gatsby ، يستخدم المطورون مدير حزمة العقدة (NPM) على محطة UNIX الخاصة بهم وتشغيل تثبيت الأمر npm.

كيف ترتبط GraphQL بـ Gatsby.

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

يتيح هذا التنفيذ الفريد للمطورين ربط أي مصدر بيانات بـ Gatsby. على سبيل المثال ، يمكن أن تأتي مشاركات المدونات من ملفات Markdown أو جداول بيانات Google أو حتى موقع ويب WordPress آخر. وبالتالي ، توفير مرونة معززة مع توصيل المحتوى.

آلية Gatsby-WordPress (المكونات الإضافية المصدر)

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

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

تم إنشاء المكون الإضافي "Gatsby-source-WordPress" وصيانته بواسطة فريق Gatsby الأساسي ، ويقوم بسحب البيانات إما من مواقع WordPress ذاتية الاستضافة أو WordPress.com. يستلزم أيضًا مصادقة OAuth لواجهة برمجة تطبيقات Word-Press.com ، ويسمح أيضًا للمطورين بالاستعلام عن الصور المتجاوبة.

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

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

من الناحية العملية ، توفر أداة "Gatsby-source-WordPress" مؤشرًا ثابتًا لجميع المنشورات والكيانات الأخرى. وبالتالي ، كل ما يحتاجه المهندس هو إنشاء صفحة تستدعي وظيفة "createPage". يتم تنفيذ ذلك في ملف Gatsby-node.js ، عادةً عن طريق تشغيل الاستعلام أولاً لمصدر البيانات ثم استدعاء "createPage" لكل عقدة تم العثور عليها ، ثم تعيين ملف قالب ليتم استخدامه كمكون.

CI / CD وأتمتة تحرير التطبيق.

عند تنفيذ WordPress CMS بدون رأس باستخدام Gatsby ، فإن كيفية تنفيذ النشر أمر بالغ الأهمية. عادةً ما تتطلب عمليات التنفيذ هذه نشر تطبيق ليتم أتمتة باستخدام Application Release Automation (ARA).

بشكل عام ، تستلزم ARA الوظائف الأساسية:

• نشر البيانات وكود التطبيق والتحف.
• نشر تكوينات محددة لكل بيئة
• تصميم سير عمل العملية لأتمتة المهام وخطوات النشر.
• أخيرًا ، نمذجة البيئة و / أو التزويد بالثنائيات

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

الاستعلام من WordPress باستخدام GraphQL و gatsby-source-WordPress

كتوضيح ، يعمل gatsby-source-WordPress بطريقة تجعله يجلب أولاً كل شيء في نقطة النهاية باستخدام REST. ثم يقوم بإنشاء واجهة برمجة تطبيقات GraphQl داخلية بناءً على تلك البيانات. بعد ذلك ، سيتم استعراض استفساراتك وجمع البيانات من واجهة برمجة تطبيقات GraphQL الداخلية. لذلك ، بشكل أساسي ، ينتهي بنائك فقط بالبيانات التي طلبتها ولا شيء آخر.

مزايا تطوير WordPress بدون رأس باستخدام Gatsby.js

نظرًا لأننا تطرقنا إلى تطوير Headless WordPress باستخدام Gatsby ، يمكننا الآن تفكيك مزايا هذا النوع من النهج التقني. يجب أن يوجه هذا قرارك بشكل أساسي بشأن تبني Gatsby أم لا!

• الفائدة الأولى هي القدرة على الحصول على موقع ثابت معروض مسبقًا. هذه هي الطريقة الأكثر فاعلية لعرض صفحة ويب ، وبما أن Gatsby تستخدم GraphQL لتنفيذ الحد الأدنى من البيانات المطلوبة ، فإن هذا يوفر بعض الكفاءة الإضافية للوقت بعد التحميل الأولي.
• رؤية مُحسّنة لتحسين محركات البحث: الصفحات الثابتة سهلة القراءة لمحركات البحث حيث يتم عرض كل شيء مسبقًا وقابل للفهرسة. هذا أمر إيجابي ، على عكس الآليات الأخرى التي لا رأس لها حيث يمثل عرض الصفحات باستخدام JavaScript مشكلة تتعلق بتحسين محرك البحث (SEO).
• سرعة تطوير سريعة نسبيًا: بالمقارنة مع الأساليب الأخرى التي لا رأس لها ، فإن Gatsby لديها طريقة واحدة موحدة وسهلة الفهم لجلب البيانات بغض النظر عن المصدر. هذا يجعل التطوير مبسطًا إلى حد ما حيث يمكنك التركيز على موقعك الفعلي والسماح لـ Gatsby بتنفيذ غالبية الرفع الثقيل.
• استضافة أرخص: يمكنك استضافة تطبيق Gatsby الخاص بك في أي مكان لأنه يقدم فقط ملفات ثابتة ، وبالتالي يقلل من نفقات الاستضافة. بالإضافة إلى ذلك ، نظرًا لأنه يتم استدعاء WordPress فقط أثناء عملية الإنشاء ، وليس أثناء جلسة المستخدم أبدًا ، يمكن استضافته على حل استضافة ميسور التكلفة أيضًا.
• أمان محسّن: بشكل عام ، تعد مولدات المواقع الثابتة آمنة للغاية نظرًا لعدم وجود اتصال مباشر بقاعدة بيانات أو تبعيات أو بيانات مستخدم أو معلومات حساسة أخرى.
• خالية من المكونات الإضافية: من منظور غير المطور ، من السهل جدًا تشغيل WordPress بسبب المكونات الإضافية المتاحة. ومع ذلك ، فإن هذا يقيد تنفيذ الوظائف المخصصة. لسوء الحظ ، يمكن أن يؤدي وجود عدد كبير جدًا من المكونات الإضافية إلى إبطاء الموقع لأنه يصبح ثقيلًا ويصعب عرضه. يتغلب إعدام غاتسبي بشكل أساسي على كل هذه الاختناقات.

المزيد من الجوانب التي يمكن أن تحفزك على التفكير في Gatsby باستخدام WordPress:

• من السهل إدارة لوحة إدارة WordPress.
• جاهز لاستخدام نظام تسجيل دخول المستخدم والترخيص.
• باستخدام محرر Gatsby و Gutenberg ، يمكنك إنشاء أداة إنشاء مواقع Gatsby بنظام السحب والإفلات.

عيوب تطوير WordPress بدون رأس باستخدام Gatsby.js

• قيود التحديث: عندما يتغير المحتوى من البداية ، فإنه يضع قيودًا على مدى تكرار تحديث موقعك. بالإضافة إلى ذلك ، قد يستغرق تشغيل Gatsby build ما يصل إلى 10 دقائق إذا كان موقعك يحتوي على الكثير من البيانات ، مما قد يمثل مشكلة للمواقع التي يتم تحديثها بشكل متكرر.
• صخب التحديثات المنتظمة: أيضًا ، نظرًا لأن Gatsby هو منشئ موقع ثابت ، فلا يمكن "تحريره" فقط ، حتى التغيير الصغير في النص سيتطلب نشرًا جديدًا. لذلك ، إذا كانت لديك صفحة تتطلب العديد من التغييرات الديناميكية للمحتوى اليومي ، فقد يستغرق ذلك وقتًا طويلاً وصخبًا.
• التأخيرات: يتعين عليك عادةً الانتظار عدة دقائق لرؤية التغييرات في المحتوى الخاص بك أثناء نشره.
• نقص المعاينات: على عكس تطبيقات WordPress التقليدية ، ليس لديك أي نوع من المعاينة في Gatsby. للأسف ، كانت هذه أكبر مشكلة وجدها منشئو المحتوى مع Gatsby. ستحتاج إلى تجميع كل شيء ، ربما باستخدام خطوط أنابيب Gitlab CI / CD التي تجمع موقع الويب وتضع كل شيء على الإنترنت.
• منحنى التعلم الحاد: بشكل عام ، إذا كنت ترغب في العمل مع Gatsby و WordPress في نفس الوقت ، فأنت بحاجة إلى أن تكون على دراية نسبية بكل من لغات PHP و JavaScript. نظرًا لأن Gatsby يدمج React و GraphQL ، يمكن أن يكون هذا منحنى تعليمي حاد للكثيرين.

افكار اخيرة.

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

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

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