لوحة المتصدرين

في بداية رحلتك إلى عالم التدوين كنوع من أنواع العمل الحر، تحتاج غالباً إلى الإلمام ببعض النقاط الهامة في هذا المجال، منها البحث عن منصة سهلة لإدارة ونشر المحتوى عبر الشبكة العنكبوتية، وبالطبع فإن معرفتك بمميزات وعيوب منصات التدوين المختلفة ستساعدك في اختيار المنصة الملائمة لك. حالياً تعتبر منصة وورد برس المنصة الأكثر استخداماً في تشغيل المواقع والمدونات حول العالم، لكن ربما يجد الكثير من المدونين في البداية بعض الصعوبة في التعامل معها، لذلك يلجأ الكثير منهم إلى منصة بلوجر الأسهل استخداماً من وجهة نظرهم، لكن سرعان ما يبدأ التفكير حول دقة اختيار المنصة ومدى توافقها مع رغبات المدون. بالتالي نجد تساؤلاً يطفو إلى السطح مع كل بداية جديدة من أحد المدونين ألا وهو بلوجر أم وورد برس: أيهما أستخدم؟ أو أيهما أفضل؟ وباعتقادي الشخصي فإن هذا التساؤل يجب أن يكون على نحو مغاير تماماً لأن أفضلية منصة معينة ليست العامل الأساسي الذي يجب أن ينطلق منه المدون، بل في مدى ملائمة هذه المنصة وتوافقها مع رغبات المدون. وبأي حال، سنحاول من خلال هذا الموضوع مناقشة بعض الفروقات الهامة بين منصة وورد برس ومنصة بلوجر والإجابة على هذا التساؤل، لكن أرجو أن نلتفت إلى النقاط التالية قبل البداية: المقارنة التالية موجهة بشكل أساسي للراغبين باستخدام إحدى المنصتين في مجال التدوين أو ما شابه، وليست مقارنة لما يمكننا فعله باستخدام كل منصة. المقارنة ستكون بين منصة بلوجر و WordPress.org غير المدفوعة هذه المقارنة لا تشبه المقارنات بين فريقي كرة القدم "ريال مدريد" و"برشلونة" أو بين شركتي Apple وSamsung، فهي لا تهدف إلى نسف منصة ما وتمجيد الأخرى، بل هي محاولة عملية لمساعدة القارئ للوصول إلى استخدام منصة معينة وفق معايير محددة. دعونا نبدأ أولاً: الملكيةبلوجر هي منصة نشر محتوى تمتلكها شركة Google العملاقة وبالتالي يمكنك الوثوق بها دون تردد كغيرها من منتجات شركة Google الرائعة، بينما منصة وورد برس هي نظام مفتوح المصدر لإدارة المواقع تمتلكه شركة Automattic ويعود حق ملكية المدونة إلى المدون نفسه. وذلك يعني أنك لست المالك الحقيقي لمدونة بلوجر، فيمكن لشركة Google حذف المدونة الخاصة بك أو إغلاقها مؤقتاً أو نهائياً فيما إذا قمت بمخالفة شروط النشر والاستخدام أو حتى إذا أرادت جوجل ذلك لسبب أو لآخر وحينها لن تكون الشركة مضطرة لإبداء أي تفاصيل حول أسباب الإغلاق. بينما مع مدونة وورد برس ستكون أنت المالك الفعلي للمدونة ويمكنك إغلاقها كيفما تريد، ولا يمكن لجهة معينة إغلاق أو حذف المدونة لسبب أو لآخر حيث ستكون لديك سيطرة كاملة على محتويات وملفات مدونتك من خلال استضافة خاصة. المسألة الثانية المترتبة على موضوع الملكية هي إمكانية بيع المدونة، فمع مدونات بلوجر هناك صعوبة بالغة في بيع المدونة مع عدم حقك أصلاً في بيعها، بينما مع مدونات وورد برس فلك الأحقية الكاملة في بيع المدونة متى شئت وبكل سهولة. الخلاصة: من الواضح أن استخدام وورد برس لديه أفضلية في هذه النقطة، لكن من الإنصاف القول بأن شركة Google لا تلجأ إلى إغلاق المدونة بسبب انتهاك بسيط وهي غير متعسفة إطلاقاً في استخدام هذا الحق. وبالتالي فإن الالتزام بسياسة بلوجر يضمن لك عدم المساس بالمدونة من طرف Google. ثانياً: التصميمالكثير من القوالب المتوفرة لمدونات بلوجر هي قوالب منخفضة الجودة، وحتى في حال حصولك على قالب مميز ستجد أن العديد من المدونات الأخرى تستعمل نفس القالب وبالتالي فإن الحصول على قالب احترافي ومميز لمدونات بلوجر ليس بالأمر السهل، خصوصاً مع وجود عدد قليل جداً من المطورين لمدونات بلوجر. وقد تتجه فعلاً لاختيار أحد المختصين في تطوير قوالب بلوجر وتدفع له مقابل ذلك للحصول على قالب يناسبك، لكنك في الغالب ستُصطدم بالخيارات المحدودة جداً التي تسمح بها منصة بلوجر من حيث التصميم والقالب. أما مدونات وورد برس فتمتلك مجموعة كبيرة جداً من القوالب الرائعة والتصاميم المتنوعة، كما يمكن للمدون الحصول على قوالب احترافية للغاية، ويمكنه وضع تصوره الخاص بالتصميم الذي يرغب به وسيجد الكثير من المطورين المميزين على استعداد لتنفيذ كل ما يريد وعلى أفضل وجه، وبالتالي فمنصة وورد برس تقدم لك خيارات غير محدودة من حيث التصميم والقوالب، وبالتالي لا داعي للقلق إطلاقاً حول مسألة التصميم. الخلاصة: الأفضلية من حيث القوالب والتصميم هي لمدونات وورد برس. ثالثاً: التعامل مع المنصةتتميز مدونات بلوجر بسهولة كاملة في التعامل مع المنصة، وبمجرد امتلاكك لحساب GMail ستكون قادراً على إنشاء مدونة مجانية عبر بلوجر والبدء في نشر المواضيع من خلال لوحة التحكم البسيطة ودون الدخول في أمور برمجية أو فنية. بينما تحتاج مدونات وورد برس إلى معرفة ببعض الأشياء الفنية والبرمجية بشكل مسبق حتى تتمكن من تنصيب المدونة والبدء في نشر المواضيع، وبالتالي قد يجد بعض المدونين صعوبة في التعامل مع وورد برس في البداية. الخلاصة: مدونات بلوجر لها الأفضلية من حيث التعامل وسهولة الاستخدام ولا تتطلب معرفة مسبقة بالأمور الفنية. رابعاً: التحكم في المنصةتوفر مدونات بلوجر خيارات محدودة جداً للتحكم في المنصة وتخصيصها بالطريقة الملائمة للمدون، وبالتالي على المدون العمل وفق ما تُمليه المنصة عليه وليس العكس، فمثلاً هناك خيارات محدودة جداً في التحكم بالتعليقات ونماذج الاتصال داخل المدونة. أيضاً لا تسمح مدونات بلوجر بإضافة محررين ومساهمين آخرين للمدونة، وجود عدد محدود من الصفحات الثابتة، عدم القدرة على التحكم في آلية ظهور المواضيع وغيرها. أما مدونات وورد برس فتمتلك خيارات غير محدودة للتحكم في المنصة وبالطريقة التي تلائم المدون، فيمكن إدراج عدد غير محدود من المساهمين والمحررين داخل المدونة وتخصيص ملفاتهم الشخصية، نظام تحكم مميز في التعليقات ونماذج الاتصال والصفحات الثابتة وآلية ظهور المواضيع، بالإضافة إلى إمكانية استخدام العديد من الإضافات لتوفير المزيد من الخيارات للتحكم في المنصة. الخلاصة: الأفضلية من حيث التحكم في المنصة هي لمدونات وورد برس. خامساً: تحسين الظهور في محركات البحث "SEO"يعتقد الكثير من المدونين بأن استخدام منصة بلوجر يعطيها أفضلية من ناحية SEO وذلك لأنها تابعة لشركة Google وبالتالي ظهور أفضل داخل محرك بحث Google على الأقل، في الواقع هذا الافتراض غير صحيح بالمطلق. دعونا نحتج برأي المهندس في شركة جوجل Matt Cutts، فهو يعمل لدى الشركة المالكة والداعمة لبلوجر بينما تعمل مدونته الشخصية عبر منصة وورد برس. يرى Matt أن كل من المنصتين تعمل بشكل مناسب مع SEO وكل منصة لها إيجابيات وسلبيات، لكن في نفس الوقت فإن منصة وورد برس تعطي خيارات وإمكانية تخصيص أكبر في هذه المسألة. ويضيف Matt بأنه إذا كنت تمتلك محتوى جيد وعددًا معقولًا من الروابط المؤدية لمدونتك وبالتالي زوارًا أكثر، فإن المسألة لن تشكل أي فارق بين استخدام وورد برس أو بلوجر. يمكننا القول بأن مسألة SEO تعتمد في الأساس على المدون نفسه، فكل من وورد برس وبلوجر لا تقدم أي مميزات في هذا الخصوص ابتداءً، وبالتالي على المدون معرفة بعض الاستراتيجيات المتعلقة بالسيو للحصول على ظهور أفضل. لكن يمكن لمستخدمي منصة وورد برس الاستعانة لاحقاً ببعض الإضافات المتعلقة بـ SEO مثل إضافة Yoast والتي توفر العديد من المميزات والاحتياجات المتعلقة بالسيو، وهذا الأمر غير متوفر في مدونات بلوجر. الخلاصة: وورد برس يتيح خيارات أوسع من ناحية تحسين محركات البحث "SEO" من خلال توفير العديد من الإضافات والقدرة على تهيئة المدونة لمحركات البحث بشكل أفضل، لكن في نفس الوقت يجب الالتفات إلى أن جودة المحتوى هي النقطة المركزية في المدونة، بمعنى لو أنك تمتلك محتوى ضعيف وسيء مع أفضل استراتيجية سيو في العالم فلا تتوقع أن تحقق مدونتك أي نجاح حقيقي على صعيد الشبكة العنكبوتية. بينما المحتوى الجيد سواء كان عبر منصة بلوجر أو وورد برس هو المفتاح الحقيقي للنجاح. سادساً: التكاليفتتيح لك منصة بلوجر إنشاء مدونة مجانية بشكل كامل، حيث يتم استضافة المدونة لدى سيرفرات جوجل دون دفع أي مبلغ مقابل ذلك، بالإضافة إلى ذلك ستحصل على 1 جيجابايت لتخزين الصور من خلال خدمة بيكاسا مجاناً ويمكنك زيادتها إلى 15 جيجابايت باستخدام حساب جوجل بلس أو حساب جوجل درايف مجاناً أيضاً، كما تسمح لك جوجل بنشر عدد لا نهائي من المواضيع عبر المدونة والقدرة على إنشاء عدة مدونات عبر حساب واحد، والأهم أن جوجل تتيح لمدونتك حجم تبادل بيانات Bandwidth غير محدود. وبالطبع يمكن دفع بعض التكاليف البسيطة بحسب الرغبة لظهور المدونة بشكل أفضل أهمها اختيار اسم نطاق خاص للمدونة بدلاً عن اسم نطاق فرعي تقدمه بلوجر بشكل افتراضي، بالإضافة إلى إمكانية اختيار قالب مدفوع. أما مع منصة وورد برس فيجب عليك امتلاك استضافة لمدونتك من خلال إحدى الشركات التي توفر خدمات الاستضافة، ويجب عليك حينها تحديد المتطلبات التي تحتاجها مدونتك مثل المساحة التخزينية وحجم تبادل البيانات وبالتالي يمكنك اختيار أنسب العروض التي توفرها شركات الاستضافة المختلفة، وبالطبع ستقوم بدفع مبلغ مادي شهري بحسب خطة الاستضافة التي اخترتها، وكلما ازدادت المتطلبات الخاصة لمدونتك مثل الحاجة لمساحة أكبر أو أصبحت المدونة تستقطب عدد زوار أكبر، كلما ازدادت الحاجة لدفع مبالغ إضافية والانتقال لاستضافة مناسبة أكثر لمتطلبات المدونة. هناك نقطة هامة مرتبطة بمسألة التكاليف وهي أي المنصتين أفضل لتحقيق الدخل من المدونة؟ في الواقع مسألة تحقيق الدخل هي مسألة مرتبطة بجودة المحتوى واختيارك لمجال المدونة بصورة ملائمة بالإضافة إلى اتباع طرق تسويق فعالة لجلب المزيد من الزوار وبالتالي دخل أفضل، وليس لها علاقة باستخدام هذه المنصة أو تلك لكن دعونا ننوه لأمرين، الأول أن خدمة جوجل أدسنس هي إحدى خدمات شركة جوجل وبالتالي فإن ربط مدونة بلوجر بحساب أدسنس يتم بصورة سريعة وتقدم جوجل تسهيلات لقبول المدونات التابعة لها من خلال التكامل بين أدسنس وبلوجر، بينما تحتاج أحياناً مدونات وورد برس لبعض الوقت لاعتمادها عبر جوجل أدسنس. الأمر الثاني يتعلق بمستقبل المدونة، فإذا أردت تحويل المدونة إلى أشبه بالمشروع التجاري وتحقيق دخل أكبر فربما تحتاج حينها لخيارات أكبر لإدارة المدونة وبالتالي ستكون منصة وورد برس خيارك الأفضل. الخلاصة: مدونات بلوجر لها الأفضلية من حيث التكاليف، بينما يجب أن يتوفر لك مبلغ مادي لإنشاء مدونة وورد برس. سابعاً: الأمانباستخدامك لمنصة بلوجر فأنت تقول وداعاً لمشاكل الأمان والحماية الخاصة بالمدونة، فشركة جوجل هي المسؤول المباشر عن المعالجة الأمنية للمدونة وحمايتها من الاختراق، وبالتالي فليس هناك داعي لوضع إضافات أو خدمات أمنية أو الاستعانة بأحد المختصين في هذا المجال. ولغاية الآن تعتبر مدونات بلوجر عصية على الاختراق من قبل القراصنة وربما تعتبر هذه الميزة هي الأقوى من بين كل المميزات الخاصة بمدونات بلوجر. أما عند استخدامك لمدونة وورد برس فستكون أنت المسؤول الأساسي عن توفير الحماية اللازمة للمدونة ومتابعتها في حال حدوث أي خلل أو اختراق. وبالرغم من وجود العديد من الإضافات المتعلقة بالحماية والتطوير والتحديث الأمني الدائم للمنصة إلا أن مدونات وورد برس تبقى عرضة لهجمات القراصنة. فمثلاً من الممكن أن تتعرض بعض المدونات لهجمات حجب الخدمة DDOS وإيقافها لمدة معينة، بينما لا يمكن حدوث أمر من هذا القبيل مع مدونات بلوجر وسيرفرات جوجل، وبالطبع هذا لا يعني أن منصة وورد برس هي منصة غير آمنة، لكن في نفس الوقت يجب الاهتمام بهذه النقطة من قبل المدون لضمان عدم وجود أي مشاكل مستقبلية. الخلاصة: مدونات بلوجر لها أفضلية واضحة من حيث الأمان والحماية، بينما تحتاج مدونات وورد برس إلى المتابعة من صاحب المدونة لتوفير الحماية اللازمة. ثامناً: الدعمللأسف فإن مدونات بلوجر لا تتمتع بدعم حقيقي من طرف جوجل، ففي حال اختيارك للتدوين عبر منصة بلوجر عليك أن تنسى تماماً بعض المصطلحات مثل فريق الدعم أو مجتمع الدعم ومن الأفضل ألا تتعب نفسك في محاولة الاتصال بهم أو حتى البحث عن طريقة للاتصال. وللتوضيح أكثر يوجد هناك منتدى دعم رسمي خاص ببلوجر يطرح بعض المشاكل والحلول الخاصة ببلوجر ويمكنك البحث خلاله عن إحدى المشاكل التي واجهتك، لكن على الأغلب لن تجد هناك أي مساعدة حقيقية لحل مشكلتك عبر هذه المنتديات أو حتى أي تفاعل من قبل المطورين. وباختصار إن واجهتك مشكلة داخل بلوجر فعليك اختصار الوقت والعمل على إيجاد الحل بنفسك أو عن طريق الاستعانة بأحد المختصين بعيداً عن الدعم الرسمي من جوجل. أما بالنسبة لمدونات وورد برس فهي تتمتع بدعم فني كامل، مع وجود العديد من المساهمين والمطورين المستعدين لتقديم المساعدة عبر قسم المساعدة أو المنتدى الرسمي الخاص بالمنصة، وبالتالي ستجد حلاً لأغلب المشاكل التي قد تواجهك عند استخدامك للمنصة بكل سهولة. الخلاصة: تمتلك مدونات وورد برس أفضلية كاملة من حيث الدعم الفني وإيجاد الحلول لأي مشكلة تواجه المدون. تاسعاً: مستقبل المنصّتيندعونا نعود إلى الوراء قليلاً ونتذكر الخطوة التي قامت بها شركة ياهو بإغلاق منتديات مكتوب والصدمة التي تلقتها شريحة واسعة من المستخدمين في العالم العربي حينها. لكن لا شك أن هذه الصدمة ستكون متواضعة جداً في حال أقدمت جوجل على إغلاق خدمة بلوجر بعد فترة معينة من الزمن، ولك أن تتصور ذلك الآن. هناك العديد من المخاوف حول إمكانية إقبال جوجل على خطوة شبيهة بخطوة ياهو يوماً ما، ومما يشير على هذا الأمر أن شركة جوجل لم تقم بإطلاق أي تحديثات حقيقية أو تطوير فعلي على منصة بلوجر منذ فترة طويلة جداً، بالإضافة إلى أن تطبيق بلوجر لنظام أندرويد يعتبر من أسوأ التطبيقات التي أطلقتها الشركة، مما يعطي انطباعاً لدى البعض بعدم اهتمام جوجل بمنصة بلوجر بشكل جدي، وتركيزها بشكل كبير جداً على خدمة يوتيوب التي تحقق لها أرباح طائلة. وعلى الرغم من أن المخاوف بإغلاق خدمة بلوجر هي مخاوف مبررة، لكن لا توجد أي دلائل حقيقية تدعمها أو حتى تلميحات حول الأمر من شركة جوجل، والمقارنة بمسألة إغلاق ياهو لمكتوب لا تستقيم مطلقاً، والمتابع الجيد للأحداث يعلم الصعوبات التي واجهتها ماريسا ماير الرئيسة التنفيذية لشركة ياهو واضطرارها على اتخاذ عدة خطوات حاسمة وقوية، وهو الأمر الذي لا تعاني منه جوجل حالياً ولا حتى في السنوات القليلة المقبلة. لكن لنفترض في أسوء الحالات أن جوجل قامت بإغلاق خدمة بلوجر فهل يعني ذلك ضياع المدونة؟ بالتأكيد لا فشركة عملاقة مثل جوجل لن تترك المستخدم الذي وضع الثقة في خدماتها لسنوات دون إيجاد حل فعال، وأبسط هذه الحلول هو إعطاء مهلة زمنية معينة لنقل المدونة عبر منصة أخرى. بالطبع ستكون هناك أضرار معينة جراء ذلك لكن يمكن مع الوقت تدارك هذه الأضرار والتغلب عليها. أما منصة وورد برس فلا شك أن أمامها مستقبلاً واعداً، فهي تسير يوماً بعد يوم نحو مزيد من التطوير والتحديث خصوصاً مع وجود آلاف المطورين والمختصين في البرمجة أو التصميم والمواضيع المرتبطة بتطوير منصة وورد برس، وبالتالي فإن استخدامك لمنصة وورد برس سيشعرك باطمئنان أكبر حول مستقبل مدونتك وتطويرها بشكل دائم، بالإضافة إلى ذلك ستكون أنت المتحكم الوحيد في مصير المدونة ومستقبلها. الخلاصة: تمتلك مدونات وورد برس أفضلية واضحة من ناحية مستقبل المنصة، سواء من حيث الملكية أو التطوير والتحديث، في نفس الوقت لا يوجد أي نهوض حقيقي لغاية الآن لمنصة بلوجر بالإضافة إلى المخاوف الخاصة بإغلاق الخدمة من طرف جوجل. بعد هذه المناقشة المفصلة لأوجه الفرق بين المنصتين دعونا نلخص أبرز مميزات وعيوب كل منصة على هيئة نقاط سريعة. مميزات بلوجر منصة بسيطة جداً وسهلة الاستخدام.التكامل مع خدمات شركة جوجل وأهمها جوجل أدسنس.مجانية تماماً، مع إمكانية دفع مبالغ بسيطة بحسب رغبة المدون مثل امتلاك دومين مدفوع أو الحصول على قالب خاص وأكثر احترافية من القوالب المجانية.توفر مستوى عالي من الحماية والأمانتساعد المدون بالتركيز على تقديم المحتوى بعيداً عن الأمور الفنية الأخرى.عيوب بلوجر عدم وجود إضافاتخيارات محدودة بالنسبة للتصميم والقالبلست المالك الحقيقي للموقععدم وجود دعم فنيخيارات محدودة جداً لتخصيص المدونة والتحكم بهامميزات وورد برس منصة مرنة تمتلك العديد من الوظائف والخيارات المختلفةوجود مجموعة كبيرة جداً من التصاميم والقوالب التي يمكنك الاختيار بينها.إمكانية تخصيص المدونة بشكل كامل، بالإضافة إلى وجود العديد من الإضافاتإمكانية التحكم الكامل بالمدونة بالإضافة إلى حق الملكية.دعم فني شامل والحصول على حل لأي مشكلة قد تواجهكعيوب وورد برس تحتاج بعض الوقت للتعلم والتعامل مع المنصةتحتاج إلى صيانة ومتابعة دوريةتحتاج إلى دفع تكاليف أكبر وتوفير ميزانية محددة منذ البداية لبناء المدونة.الصعوبة في التعامل مع المنصة والتكيف معها في البداية، خصوصاً للمدونين الجدد.والآن وصلنا إلى الإجابة النهائية عن التساؤل الأساسي لهذا الموضوع، ماذا أستخدم بلوجر أم وورد برس؟ في البداية دعونا نتفق بأن تجربة التدوين وتقديم محتوى جيد هي تجربة تستحق الدعم الكامل والتقدير بغض النظر عن المنصة التي ستقوم باستخدامها لهذا الغرض، فالمدونات هي نشاط لطيف وجميل جداً يساعدنا في قضاء بعض الوقت المفيد والممتع لنا وللآخرين، فتقاسم خبراتك ومعرفتك ومهاراتك مع الآخرين والبدء في تكوين شبكة من الأصدقاء والحصول على بعض الأموال هي تجربة مثيرة وممتعة فعلاً. لكن من الجيد أن تتيح لنفسك القليل من الوقت للتفكير واتخاذ القرار المناسب وفقًا لتطلعاتك وأهدافك التي تريد الوصول إليها من خلال مجال التدوين، فإجراء تعديلات ضخمة على مدونتك بعد فترة من الزمن قد يؤثر على تصنيفها داخل محركات البحث بالإضافة إلى انخفاض عدد الزوار لمدونتك. لذلك أرجو أن تساعدك النقاط التالية بالإضافة إلى المقارنة الفائتة في تحديد اختيارك بصورة ملائمة الحالات التي يُفضل فيها استخدام بلوجرالتدوين بشكل منقطع أو غير نظامي، بحيث تقوم بالتدوين بصورة غير رسمية وعلى فترات متباعدة. عدم الحاجة للعديد من المميزات والخصائص والتحكم داخل المدونة، أي أن ما يهمك هو نشر محتوى معين بعيداً عن خيارات التحكم الخاصة بالمدونة. خوض تجربة جديدة وشبه تجريبية في مجال التدوين، وبالتالي يمكنك استخدام منصة بلوجر لفترة معينة وتحديد خطواتك المقبلة اعتماداً على نتائج هذه الفترة. عدم امتلاك المعرفة اللازمة في الأمور التقنية والفنية المتعلقة بإدارة المدونة، ولا تريد تخصيص بعض الوقت للتعلم عدم الرغبة في إنفاق أي مبالغ مادية على المدونة اقتصار المدونة على مجال واحد فقط من مجالات التدوين. الحالات التي يُفضل فيها استخدام وورد برسإنشاء مدونة شاملة ومتكاملة وتحتاج إلى العديد من إمكانيات التخصيص الرغبة في التحكم الكامل بالمدونة، والاحتفاظ بملكية محتويات المدونة بصورة تامة. العمل على المدونة بشكل تجاري، أي وجود نية لبيعها في مرحلة معينة المقدرة على التعامل الفعال مع منصة وورد برس ومعرفة بالأمور الفنية. المقدرة على دفع التكاليف الخاصة بالمدونة الحاجة لوجود خيارات واسعة لقالب المدونة والتصميم الخاص بها. التدوين المتواصل وطويل المدى ووجود رؤية مستقبلية لدى المدون.

يُعتبر خادوما الويب Apache و Nginx الأكثر شهرةً من بين الخواديم المفتوحة المصدر في عالم الشبكة العنكبوتيّة، على اعتبار أنّهما مسؤولان عن خدمة وتأمين نصف تدفّق البيانات على الإنترنت، وعلى مَقدرة على تولّي مُختلف حجوم الأحمال، والعمل مع برمجيات أخرى في سبيل توفير حزمة من خدمات الويب الشاملة والكاملة لتلبية مُختلف الاحتياجات. بينما يَتشارك الخادومان Apache و Ngnix العديد من الميّزات والخاصيّات، فلا يُمكن اعتبارهما مُتشابهان، أو التفكير بأن أحدهما هو بديل عن الآخر، فكل منهما يتفّوق عن الآخر بشيءٍ ما، وعلى مُدير النظام فهم وإدراك لماذا يجب اختيار أحدهما دون الآخر، فهذا الدليل يَهدف إلى مُناقشة كيف أنّ كُل خادوم يَتميّز ويَبرز في شيء ويُخفق في آخر. مقدّمة عامّةسيتمّ أخذ نظرة سريعة عن تاريخ وبداية المشروعين وخواصّهم العامّة قبل التعمّق في الاختلاف بينهما. تاريخ خادوم الويب Apacheأَنْشَأَ “روبت ماك كول” (Robert McCool) “خادم الـ HTTP أباتشي” (Apache HTTP Server) في عام 1995، وتمّ مُتابعة تطويره تحت مظلّة “مُنشأةُ برمجيات أباتشي” (Apache Software Foundation) مُنذ العام 1999، وكان هذا الخادم هو المشروع الأساسي للمُنشأة والأكثر شهرةً عن باقي البرمجيات، فأصبح ببساطة يُشار إليه بالاسم “Apache”. يُعتبر خادم الويب أباتشي الخادم الأكثر استخدامًا على الإنترنت منذ العام 1996، وبسبب هذه الشهرة، استفاد أباتشي من توثيق ودعم باقي مشاريع البرمجيات الأُخرى. يَختار مُدراء الأنظمة الخادم أباتشي غالبًا بسبب مرونته، وقُدرته على التحمّل، وتوفّر دعمه العالي والمُنتشر، كما يُحسب له قابليته على التوسّع عبر نظام الوحدات (modules) الديناميكيّة، واستطاعته على مُعالجة عدد كبير من اللغات المُفسّرة (interpreted languages) من دون الحاجة إلى برمجيّة مٌستقلّة وسيطة. تاريخ خادوم الويب Nginxبَدأ “ايجور سيسيوﭫ” في عام 2002 العمل Nginx للإجابة وحلّ المُشكلة المعروفة بالاسم C10K، والّتي كانت تُشكّل تحدّيًا كبيرًا لخوادم الويب لتُصبح قادرة على تولّي عشرة آلاف اتصال مُتزامن (concurrent) وذلك في تلبية حاجة الويب الحديث، وأُنتجت الإصدارة الأوليّة والمُتاحة للعُموم في عام 2004 مُقدمةً حلًا لهذه المُشكلة، وذلك بالاعتماد على معماريّة مدفوعة بالحالة (event-driven) ولا مُتزامنة. انتشر Nginx كالنار في الهشيم مُنذ إصداره، بمُقتضى خفته واستخدامه الخفيف للمَوارد، وقدرته على التوسّع وتحمّل الضغط العالي وبأقل عتاد مُمكن، وتفوّق Nginx بتأمين المُحتوى الثّابت (static content) بسرعة، وبتصميمه لتمرير الطلبات الديناميكيّة (المُتغيّرة) إلى برمجيات أُخرى قادرة على مُعالجة هذا النوع من المُحتوى. يختار مُدراء الأنظمة الخادم Nginx غالبًا بسبب استهلاكه الأمثل للمَوارد، واستجابته العالية مع الضغط المتزايد. معماريّة مُعالجة الاتصال (Connection Handling Architecture)يَكمن الاختلاف الواضح بين أباتشي و Nginx في طريقة كلٍ منهما في مُعالجة الاتصالات وتدفّق البيانات (traffic)، وربّما هذا السبب وراء الاختلاف في طريقة كل من الخادمين في الاستجابة إلى حالة تدفّق البيانات المُختلفة. وحدات أباتشي (Apache Modules)يقدّم أباتشي تشكيلةً من وحدات المُعالجة المُتعدّدة (multi-processing)، والّتي يُطلق عليها بـ MPMs، والغرض منها تحديد آليّة مُعالجة طلبات العميل، ويَسمح ذلك مُدراء الأنظمة عامّةً بالتبديل بين معماريّة مُعالجة الاتصال بسهولة، والوحدات هي: mpm_prefork: تَستنسخ وتُوالد هذه الوحدة الخاصّة بالمُعالجة عمليّات (processes) باستخدام سلسلة وحيدة (single thread)، على أنّ تكون كل عمليّة لمُعالجة طلب، ويستطيع كل ابن مُعالجة اتصال واحد في نفس الوقت، وطالما أنّ عدد الطلبات أقل من عدد العمليّات، فستكون هذه الوحدة سريعةً جدًا، ولكن يَنخفض الأداء بسرعة بعد تخطّي الطلبات عدد العمليّات، ولذلك لا يُعتبر هذا النمط بالخيار الجيّد للعديد من السيناريوهات، فكل عمليّة لها تأثير بليغ على استهلاك الذاكرة (RAM)، ولهذا السبب تُصعّب هذه الوحدة من عمليّة التوسّع بطريقة مُلائمة، ومع هذا تبقى هذه الوحدة خيارًا جيّدًا إن تمّ استخدامها مقترنةً مع مُقوّمات (components) أُخرى لم تُبنى بالأساس آخذةً بعين الاعتبار السلاسل (threads)، فلغة PHP ليست سلسلة آمنة (thread-safe)، ولذلك يُنصح بهذه الوحدة باعتبارها الطريقة الوحيدة الآمنة للعمل مع mod_php والّتي هي وحدة من وحدات أباتشي لمُعالجة هذا النوع من الملفّات. mpm_worker: تستنسخ وتُوالد هذه الوحدة عمليّات (processes) كل منها ذات قُدرة على إدارة سلاسل مُتعدّدة (multiple threads)، تستطيع كل واحدة من هذه السلاسل مُعالجة اتصال وحيد، تُعتبر هذه السلاسل أكثر كفاءة من العمليّات، بسبب أنّ هذه الوحدة تتوسّع (scales)، وتتحمّل المزيد من الضغط أفضل من الوحدة prefork MPM، وباعتبار أنّه يوجد سلاسل أكثر من العمليّات، فهذا يعني أيضًا أنّ الاتصالات الجديدة تستطيع مُباشرةً استهلاك واستخدام سلسلةبدلًا من اضطرارها إلى الانتظار لتوفّر عمليّة مُتاحة. mpm_event: تَعمل هذه الوحدة بشكل مُشابه إلى الوحدة worker، ولكنها مُحسّنة لتتولّى اتصالات keep-alive، فعند استخدام الوحدة worker فإن الاتصال سيَحتفظ بالسلسلة (thread) بصرف النظر فيما إذا كان الطلب نشطًا فيما صُنع من أجله ما دام الاتصال محفوظًا نشطًا، فالوحدة mpm_event تتولّى الاتصالات keep-alive بالاحتفاظ جانبًا بسلاسل مكرّسة لمُعالجتها، وبتمرير الطلبات النشطة إلى سلاسل أُخرى، وهذا من شأنه أنّ يُبعد الوحدة من الغوص بطلبات keep-alive، الأمر الّذي يُجيز بتنفيذ الطلبات (execution) بشكل أسرع، وهذا الأسلوب أصبح يعمل بشكل مُستقر مع الإصدار Apache 2.4. أصبح الأمر أكثر وضوحًا، حيث تقدّم خوادم أباتشي بنية معماريّة مرنة للاختيار بين مُختلف الاتصالات وخوارزمية مُعيّنة في مُعالجة الطلبات، وبُنيت هذه الخيارات في الدرجة الأولى من تطوّر الخادم والحاجة المُتزايدة للاتصالات المُتزامنة لتواكب طبيعة الإنترنت بعد تغيرها وتطوّرها. آليّة مُعالجة الاتصال في خادوم Nginxقَدِم Nginx إلى عالم خوادم الويب بعد قدوم أباتشي، مَبنيًّا ومُعدًّا لمشاكل الاتصالات المُتزامنة (concurrency) الّتي تواجه المواقع عند التوسّع، مُحمّلًا بهذه المعرفة، صُمّمَ Nginx من جذوره ليستخدم خوارزميّة في مُعالجة اتصالات مدفوعة بالحالة (event-driven)، غير مُستوقفة (non-blocking)، ولا مُتزامِنة. يستنسخ ويُوالد Nginx من العمليّات العاملة (worker processes)، ويستطيع كلٍ مِنها مُعالجة آلاف الاتصالات، وتُنجذ العمليّات العاملة ذلك عن طريق تطبيق/تنفيذ آلية حلقيّة سريعة، والّتي تفحص بشكل مُستمر حالات العمليّات (processes events)، وإن فصل المُهمّة الفعليّة عن الاتصالات يسمح لكلعامل بالاهتمام بنفسه باتصال فقط عند بدء حالة جديدة. يتموضع كل اتصال مُعالج من قبل العامل ضمن حلقة الحالة (event loop) في مكان تواجد بقية الاتصالات، وتُعالج الأحداث بشكل لا مُتزامن ضمن الحلقة، ليتمّ إنجاز المُهمّة بطريقة غير مُستوقفة (non-blocking)، وعندما يُغلق الاتصال سيتمّ نزعه من الحلقة. يَسمح هذا الأسلوب من مُعالجة الاتصال Nginx بتحمّل الضغط العالي بشكل لا يُصدّق وبأقل المَوارد المُتاحة، وباعتبار أنّ الخادم ذو سلسلة وحيدة (single-threaded) ولا تتوالد العمليّات لتُعالج كل اتصال جديد، فإن استهلاك المُعالج (CPU)، والذّاكرة يبقى ثابتًا نسبيّا، حتّى في أوقات الذروة. كيف يُعالج أباتشي و Nginx المُحتوى الثّابت والمحتوى الديناميكي (المُتغيّر)إن أبرز ما يتمّ النظر إليه عند المُقارنة بين الخادمين هي طريقة كلٍ منهما في التعامل مع طلبات المُحتوى الثّابت (static)، والمُحتوى المُتغيّر (dynamic). كيف يتعامل أباتشي مع المُحتوى الثّابت والمُتغيّرتستطيع خوادم أباتشي التعامل مع المُحتوى الثّابت باستخدام الطريقة التقليديّة المُعتمدة على الملفّات، ويعود أداء هذه الإجراءات (operations) في الدرجة الأولى على دور ووظيفة أساليب الوحدات (MPM) المشروحة سابقًا. يستطيع أباتشي أيضًا مُعالجة المُحتوى الديناميكي (المُتغيّر) بدمج مُعالج اللغة المُراد مُعالجتها داخل كل من نماذجه العاملة (worker instances)، وهذا يَسمح له بتنفيذ المُحتوى الديناميكي داخل خادم الويب نفسه بدون الحاجة إلى الاعتماد على مُقوّمات خارجيّة، ومن المُمكن تفعيل هذه المُعالجات الديناميكيّة (المُتغيّرة) من خلال استخدام وحدات قابلة للتحميل بشكل ديناميكي. إن قدرة أباتشي على مُعالجة المُحتوى الديناميكي بشكل داخلي تعني أنّ الإعداد يُصبح أسهل لمُعالجة هذا النوع من المُحتوى، فليس من الضروري تنسيق عمليّة الربط مع برمجيات إضافيّة، وتستطيع الوحدات وبسهولة أنّ تقوم بالتبديل عندما تتغيّر مُتطلّبات المُحتوى. كيف يتعامل Nginx مع المُحتوى الثّابت والمُتغيّرلا يَملك Nginx بطبيعته أي قدرة على مُعالجة المُحتوى الديناميكي، ولمُعالجة شيفرة PHP وطلبات المُحتوى الديناميكي، فإن على Nginx تمرير الطلبات إلى مُعالج خارجي من أجل التنفيذ (execution) والانتظار ريثما يتم الانتهاء من مُعالجة هذا المُحتوى ليتمّ إعادة إعادته، ومن ثم عرض النتائج على العميل. يَنبغي على مُدراء الأنظمة الانتباه إلى أنّ الأسلوب الّذي ينتهجه Nginx يستوجب إعدادًا بينه وبين المُعالج وباستخدام واحدًا من البرتوكولات الّتي يفهمها Nginx أمثال: HTTP, FastCGI, SCGI,uWSGI, memcache، وهذا من شأنه أنّ يُعقّد الأمور بعض الشيء، خصوصًا عند مُحاولة توقّع عدد الاتصالات اللازم السماح بها، حيثُ أنّه سيتمّ استخدام اتصالًا إضافيًا لكل مُعالج يتمّ استدعاؤه. من ناحية أخرى، إن هذا الأسلوب يقدّم بعضًا من الأفضليّة، عندما نعلم أنّ مُفسّر المُحتوى الديناميكي غير مُدمج في عمليّة العامل، وتكلفة هذه الطريقة ستُدفع للمُحتوى الديناميكي فقط، وعلى أنّ يُقدّم المُحتوى الثّابت بطريقة مُباشرة، ولا يتمّ الاتصال بالمُفسر إلا عند الحاجة، والجدير بالذكر أنّ أباتشي يستطيع العمل بهذا الأسلوب، ولكن بعمله ذلك سيتخلّى عندها عن بعض ميزاته. الاختلاف بين الإعداد الموزّع (Distributed) والإعداد المركزي (Centralized)يَعتبر مُدراء الأنظمة الاختلاف الأكبر والبارز بين هذين الخادمين هو فيما إذا كان الإعداد والتخصيص على مُستوى المسار مسموحًا أو لا ضمن مسارات (directories)المُحتوى. فلسفة Apache في الإعداديُضمّن أباتشي خيارًا للسماح بالإعداد لكل مسار عن طريق تَفحُّص (inspecting) وتفسير (interpreting) التعليمات أو التوجيهات الموجودة في الملفات المخفيّة داخل مسارات المُحتوى نفسها، وهذه الملفّات معروفة بملفات .htaccess. باعتبار أنّ هذه الملفّات تَقطن داخل مسارات المُحتوى نفسها، فعند مُعالجة طلبٍ ما، فإن أباتشي يَفحص كل جزء من مسار الملفّ المطلوب باحثًا عن ملفّ .htaccess ليُطبّق التوجيهات الّتي بداخله، وهذا من شأنه أنّ يسمح للإعداد اللامركزي لخادم الويب، والذي غالبًا ما يُستخدم لإنجاز: إعادة كتابة عنوان الموقع (URL rewrites)تقييد الوصول (access restrictions)التفويض والمُصادقة (authorization and authentication)سياسات التخبئة (caching policies)بالطبع يُمكن للأمثلة السابقة إعدادها عن طريق ملفّ إعدادات أباتشي الرئيسي، ولكن استخدام ملفات.htaccess يَملك بعض الميزات: أوّلًا، باعتبار أنّها تُفسّر في كل مرّة توجد بها مع المسار المطلوب، فهي تُنفّذ مُباشرةً بدون إعادة تحميل الخادم.ثانيًا، تجعل من المُمكن السماح للمُستخدِمين غير المصرّح لهم بالتحكم بجانب معيّن من المُحتوى الخاصّة بهم بدون إعطائهم تحكم كامل لملفّ الإعدادات.يُقدّم هذا النمط من الإعداد طريقة سهلة ونموذجيّة، وخاصّة لبعض برمجيات الويب، مثل أنظمة إدارة المُحتوى (CMS)، لغرض إعداد بيئتها بدون مَنح إذن وصول إلى ملفّ إعدادات مركزيّ، وكما هو معروف يُستخدم هذا الأسلوب مع مزودات الاستضافة المُشتركة (shared hosting providers) لصون والحفاظ على الإعدادات الرئيسية مع إمكانيّة منح العُملاء أفضليّة التحكّم بمسارات مُعيّنة. فلسفة Nginx في الإعدادلا يُفسّر Nginx ملفّات .htaccess، ولا يُقدّم أي آليّة للتعامل مع كل مسار من دون استخدام ملفّ إعدادات رئيسي، قد يبدو هذا الأسلوب أقل مرونةً من أسلوب أباتشي، ولكن من ناحية أُخرى فلهذا الأسلوب أفضليته. إن عدم الاعتماد على نظام ملفّات .htaccess الخاصّ بالإعداد على مستوى المسارات يُقدّم سرعةً في الأداءً، فخادم أباتشي عليه القيام بتفحّص المسار الجذر لكل طلب يصله، وعند وجود ملفّ أو أكثر خلال عمليّة البحث، يتم قراءة محتوياته وتفسيرها، ولكن Nginx لا يفعل ذلك، فهو يخدم الطلبات بسرعة أكبر بالاعتماد على مكان وحيد للبحث عنه. أفضليّة أُخرى مُتعلّقة بالحماية، فإن توزيع ملفّات الإعدادات على مستوى المسارات يوزّع مسؤوليّة الحماية على كل المُستخدِمين، الّذين قد يكونوا في معظم الأحوال غير موثوقون لتولّي هذه المُهمّة بالشكل الأمثل، فعندما يقوم مُدير النظام بتولّي مُهمة التحكم بالخادم ككل، يمنع ذلك من حدوث أخطاء، والتي قد تحدث في حال منح صلاحيات وصول لأطراف أُخرى. يجدر الذكر أنّه من المُمكن تعطيل تفسير ملفّات .htaccess’ فيأباتشي`، في حال أنها تُشكل نوعًا من القلق لمُدير النّظام. الاختلاف بين تفسير الملفّات وتفسير URIلا يقتصر الاختلاف بين الخادومين على ما سبق فقط، فيظهر الاختلاف الآخر في كيفيّة تفسير كلٍ منهما للطلبات (requests) وربطها مع المَوارد المُتواجدة على النّظام. كيف يُفسر Apache الطلباتيقدّم أباتشي القدرة على تفسير الطلب إما كمَورد فيزيائي (حقيقي) على نظام الملفّات (filesystem) أو عنوان URI الّذي قد يحتاج أسلوب أكثر تجرّد، ويستخدم أباتشي بشكلٍ عام للأسلوب الأول كتل (blocks) وهي إما <Directory> أو <Files>، بينما يستخدم كتل <Location>للمَوارد الأكثر تجرّدًا. صُمّم أباتشي من الأساس كخادم ويب، لذلك في مُعظم الأحيان فإن السلوك الافتراضيّ هو تفسير الطلبات كمَوارد نظام ملفّات (filesystem)، حيثُ يبدأ بتتبّع جذر المُستند وإلحاقه بجزئية الطلب متبوعًا باسم المُضيف (host) ورقم المنفذ في مُحاولة لإيجاد الملفّ المطلوب، بمعنى آخر وببساطة، تتمثّل هرميّة نظام الملفّات على الويب كشجرة مُستند. يُقدّم أباتشي عددًا من البدائل عندما لا يتوافق الطلب مع نظام الملفّات المقصود، فمثلًا من المُمكن استخدام الموجّه Alias لربط عنوان البديل، مع العلم أنّ استخدام الكتل <Location> هو طريقة للتعامل مع URI نفسها بدلًا من نظام الملفّات، كما يُمكن استخدام التعابير النمطيّة (regular expression)، والّتي من المُمكن استخدامها لتطبيق الإعداد بسهولة أكبر في كامل نظام الملفّات. يُعوّل أباتشي على نظام الملفّات بشكل كبير، يظهر ذلك جليًا في اعتماده على ملفّات .htaccessلإعداد كل مسار، حتّى أنّ التوثيق الرسميّ الخاصّ به يحذر من استخدام كتل مُعتمدة على URI في تقييد الوصول عندما يكون الطلب يَعتمد بشكل أو بآخر على نظام الملفّات. كيف يُفسّر Nginx الطلباتأُنشِأ Nginx ليكون خادمًا للويب وخادمًا وكيلًا/وسيطًا (proxy server)، ونظرًا إلى المعماريّة المطلوبة للعمل بهذه الأدوار، فإنه يعمل بشكل رئيسي مع URIs، والتحويل إلى نظام الملفّات عند الضرورة. يُمكن رؤية ذلك في بعض جوانب بناء وتفسير ملفّات إعدادات Nginx، فلا يوفّر Nginx آليّة لتحديد إعدادًا لمسار نظام الملفّات، بل يَستعيض عنها بتحليل URI نفسه. يُمكن توضيح ذلك بالمثال، كتل الإعداد الأوليّ لـ Nginx هي: server و location، الكتلة serverتُفسّر المُضيف الجاري طلبه، بينما الكتل مسؤولة عن مُطابقة أجزاء من URI التي تأتي بعد المُضيف والمنفذ، في هذه المرحلة يتمّ تفسير الطلب كـ URI، وليس كعنوان على نظام الملفّات. يتوجّب في نهاية المطاف على جميع الطلبات أنّ تُربط مع عنوان على نظام الملفّات وذلك للملفّات الثّابتة، فأولًا، سيَختار Nginx كتل server و location الّتي سوف تتولّى الطلب، ومن ثم ضم جزر المُستند مع الـ URI. إن تحليل ومُعالجة الطلب قبل كل شيء على شكل URIs بدلًا من عناوين نظام الملفّات يَسمح لـ Nginxالعمل بسهولة وعلى حدٍّ سواء كخادم وسيط (بروكسي)، وكخادم بريد، وخادم ويب، فقد تمّ إعداده ليُلائم كيف له أنّ يستجيب لأنماط الطلبات المُختلفة، ولا يفحص Nginx نظام الملفّات حتّى يكون جاهزًا ليَخدم الطلب، وهذا يُفسّر لماذا هو لا يُطبّق نمط ملفّات .htaccess. الوحداتيتوسع كلا الخادومان عن طريق نظام الوحدات، ولكن طريقة عملهما تختلف عن الآخر بشكل كبير. كيف يستخدم أباتشي نظام الوحدات (Modules)؟يَسمح نظام وحدات أباتشي بطريقة آليّة وديناميكيّة بتركيب ونزع الوحدات ليتناسب مع مُتطلّبات مُدير النظام خلال عمليّة تشغيل الخادم، وتتواجد نواة أباتشي دائمًا بكل جاهزية، بينما يُمكن تشغيل أو تعطيل الوحدات، أو حتّى حذفها أو إضافة ما يلزم إلى الخادم. يستخدم أباتشي الوحدات في العديد من المهام، ونظرًا للباع الطويل لمنصة أباتشي، فيتوفّر عدد هائل من مكتبات الوحدات، والّتي من المُمكن استخدامها في تعديل بعض الوظائف الداخليّة في بنية خادم أباتشي، فمثلًا الوحدة mod_php تقوم بدمج مُفسّر PHP داخل كل عامل (worker). لا تنحصر الوحدات لمُعالجة المُحتوى الديناميكي (المُتغيّر) فقط، فيُمكن استخدامها في العديد من الوظائف، فيُمكن استخدامها في: rewriting URLs: إعادة كتابة العناوينauthenticating: المُصادقةlogging: التّتبّعcaching: التخبئةcompression: الضغطproxying: الوساطةencrypting: التشفيركيف يتعامل Nginx مع نظام الوحدات (Modules)يُطبّق ويتعامل Nginx مع نظام الوحدات، ولكن يختلف الأمر عما هو في نظام أباتشي، فلا تُحمّل الوحدات بشكل ديناميكي في نظام Nginx، لذلك يجب على هذه الوحدات أنّ تُختار وتُترجم (compiled) إلى النواة. قد يبدو الأمر صعبًا للعديد من المُستخدمين وخاصّة لهؤلاء الذين لا يُحبذون صيانة برمجياتهم المُترجمة (compiled) بدون الاستعانة بنظام حزم تقليدي، وعلى الرغم من أنّ حزم الموزّع تتضمّن الوحدات الأكثر استخدامًا، ولكن عند الحاجة إلى وحدة غير شائعة، سيتوجب على مُدير النظام بناء الخادم من المصدر بنفسه. تَبقى وحدات Nginx مع ذلك ذات فائدة، وتسمح لمُدير النّظام بتحديد ماذا يجب على الخادم أنّ يحتوي من وظائف، أيضًا بعض المُدراء ينظر إلى الأمر من منظور الحماية، حيثُ أنّ المُكوّنات الاعتباطيّة لا يُمكن أن تُدرج داخل الخادم. تُقدّم وحدات Nginx مقدرات مُماثلة للوحدات الّتي المُقدّمة من أباتشي، على سبيل المثال، توفّر وحدات Nginx: proxying support: الوساطةcompression: الضغطlogging: التّتبّعrewriting: إعادة كتابة العنوانauthentication: المُصادقةencryption: التشفيرالدعم والتوافُقيّة والتوثيقيجب دائمًا التأكد من آليّة بناء الخادم ومُتطلباتها، وما الّذي على مُدير النّظام عمله لبناء خادم يعمل بأبسط الإمكانيات، وما هو حجم الدعم والمُساعدة المتوفّر لهذه البرمجية. الدعم في أباتشييُعرف الخادم أباتشي بباعه الطويل في هذا المجال، ولذلك فإن الدعم الخاصّ به متواجد وبقوّة، حيثُ يتوفّر توثيق مُمتاز لمكتباته الخاصّة به ومكتبات الطرف الثالث (الخارجيّة)، وعلى كافّة المُستويات، سواء كان لنواة الخادم أو للجزئيات المُرتبطة ببرمجيات أُخرى. يتوفّر بجانب التوثيق، العديد من الأدوات ومشاريع الويب لتسريع بدء العمل مع بيئة الخادم، وهي موجودة ضمن المشاريع نفسها أو مُتوفّرة ضمن برمجيات الحزم المعروفة. يَملك أباتشي بشكلٍ عام دعمًا قويًا من قِبل مشاريع الطرف الثالث، وذلك بسبب حصته السوقيّة، وقِدَمه، كما يَملك مُعظم مُدراء الأنظمة بشكل أو بآخر معرفة جيّدة بخادم أباتشي، ليس فقط بسبب انتشاره، ولكن أيضًا بسبب أنّ معظمهم بشكل أو بآخر يستخدم الاستضافة المُشتركة (shared-hosting)، والّتي تعتمد على خادم أباتشي بشكل حصري، لمقدرته الإدارية الموزّعة باستخدام ملفّ .htaccess. الدعم في Nginxيكسب Nginx المزيد من الدعم مع ازدياد المُستخدِمين بسبب أدائه العالي، ولكن يبقى عليه التطوير من نفسه في بعض الجزئيات. قد كان من الصعب إيجاد توثيق مفهوم وواضح بالغة الإنكليزية للخادم Nginx في البداية، نظرًا إلى أنّ تطويره وتوثيقه تمّ بالغة الروسية، ومع ازدياد الاهتمام بالمشروع، أصبح هناك وفرة من المصادر على الموقع الرسميّ وغيره من الدعم الخارجي. أصبح الدعم متوفّرًا أكثر من ذي قبل فيما يخص تطبيقات الطرف الثالث، وبدأت بعض الحزم بتقدم خيارات الإعداد التلقائي سواءً لـ أباتشي أو Nginx، وعند عدم توفّر الدعم، فإن إعداد Nginx مع البرمجيات البديلة عادةً ما يكون واضحًا ومُيسرًا طالما أنّ برمجية الطرف الثالث تملك توثيقًا جيّدًا لمُتطلّباتها. استخدام Apache و Nginx معًاتمّ عرض فوائد وقصور كلا الخادومين، ويجب على مُدير النّظام في هذه المرحلة أنّ يُحدّد أيًا منهما يُناسب احتياجاته، ولكن يجد العديد من المُستخدِمين أنّه من المُمكن تقوية خادوم الويب عند استخدام كلٍ من أباتشي و Nginx جنبًا إلى جنب. إن إتمام هذه الشراكة يتمّ عن طريق تَمَوْضُع Nginx أمام أباتشي كوكيل/وسيط عكسي (reverse proxy)، وهذه يسمح لـ Nginx بمُعالجة جميع الطلبات من العُملاء، الأمر الّذي يَسمح بالاستفادة من سرعة Nginx وقدرته على تولّي عدد كبير من الاتصال في وقتٍ واحد. إن خدمة الملفّات الثّابتة بسرعة كبيرة ومباشرةً إلى العُملاء، هو الأمر الّذي يتفوّق به Nginx، ولكن وللمُحتوى الديناميكي، ملفات PHP مثلًا، سيُوكل Nginx الطلبات إلى أباتشي لمُعالجتها والعودة بصفحة بالنتيجة النهائيّة، ليستطيع Nginx عندها تمرير المُحتوى إلى العميل. يعمل هذا الإعداد بشكل جيّد للعديد من مُدراء الأنظمة، وذلك بسبب أنّه يسمح لـ Nginx ليعمل كآلة فرز وتصنيف، بمعنى أنّه سيتولّى مُعالجة جميع الطلبات طالما أنّه يستطيع ذلك، وتمرير ما لا يستطيع التعامل معه، وبتخفيض الطلبات المطلوب من خادم أباتشي تولّيها، سيُخفف بعضًا من الاستيقاف (blocking) الّذي قد يحدث عندما يستهلك أباتشي المزيد من المُعالج. يَسمح هذا الإعداد أيضًا لمُدراء الأنظمة بالتوسّع عن طريق إضافة خادم خلفي (backend) على حسب الحاجة والضرورة، ومن المُمكن إعداد Nginx لتمرير الطلبات إلى تجمّع (pool) من الخوادم بسهولة، الأمر الّذي يزيد من الأداء والفعاليّة. الختاميُقدّم كلًا من أباتشي و Nginx مُرونة في الاستخدام، وقوّةً في الأداء، والتفضيل بينهما هو لأمرٌ يَعتمد على تقدير مُتطلبات ووظائف الخادم، وعلى مُدير النّظام أنّ لا يسأل: هو أفضل خادم ويب؟، بل السؤال الّذي يجب سؤاله هو، ما هو أفضل خادم ويب لمشروعي الّذي يتطلّب كذا وكذا؟ يوجد بالفعل اختلافات بين المشروعين، هذه الاختلافات من شأنها أن تأثر على الأداء، والقدرات، والوقت المُستغرق في إتمام أي منهما للعمل بالجاهزيّة الكاملة، ولكي يتمّ اختيار الأفضل يُنصح بعمل تسوية أو مقايضة بين المحاسن والمساوئ، ففي نهاية المطاف لا يوجد خادم يُلبي كافة الاحتياجات، ويَكمن الحلّ في ترتيب الأولويات. ترجمة –وبتصرّف– للمقال Apache vs Nginx: Practical Considerations لصاحبه Justin Ellingwood.