نظام محتوى يمكنك انتزاعه دون أن يتعطل الموقع

كان اختيار نظام إدارة محتوى (CMS) يعني الزواج منه. فقوالبك تتعلّم خصائصه، ونموذج محتواك ينحني لمخططه (schema)، وبعد ثلاث سنوات يصبح معنى «مجرد التبديل» إعادةَ بناءٍ كاملة. لقد صمّمنا طبقة المحتوى بحيث يبقى ذلك القرار قابلًا للعكس.

كل ما يقرأ المحتوى يمرّ عبر محوّل (adapter) واحد محايد تجاه المزوّد، يُبدَّل بمتغيّر بيئة واحد: فقيمة `CMS_PROVIDER` إمّا `file` أو `headless`. في وضع `file`، يقيم المحتوى في مصدرٍ خاضع للإصدارات (versioned source) قابلٍ للمقارنة (diffable) والمراجعة ويُنشر مع الشيفرة. وفي وضع `headless`، يتحدّث المحوّل نفسه إلى مصدرٍ بعيد ويخزّن لقطة (snapshot) منشورة مؤقتًا. والصفحات التي فوقه لا تعرف ولا تكترث أيّهما الفعّال؛ فهي تستدعي الواجهة (interface) نفسها وتسترجع الشكل نفسه.

الجزء الذي نفخر به أكثر هو سلوك الإخفاق. فالمحوّل يبلّغ عن مصدره في كل قراءة: `live-remote` أو `snapshot-cache` أو `file-fallback`، وعندما يتعذّر الوصول إلى المصدر البعيد، فإنه يلجأ إلى البديل الاحتياطي (falls back) بدلًا من تفريغ الصفحة. وهكذا يصبح تعطّل قاعدة البيانات قراءةً متدهورة، لا انقطاعًا في الخدمة. يرى الزوّار محتوى؛ ونرى نحن سبب اللجوء إلى البديل مسجَّلًا. ذلك هو الفرق بين حادثة وحدثٍ لا يُذكر.

ما نرفض فعله: تضمين استدعاءات واجهة برمجة تطبيقات (API) خاصة بمزوّدٍ ما داخل مكوّنات الصفحات (page components)، أو ترك نمذجة المحتوى تُملى من واجهة إدارة (admin UI) لنظام إدارة محتوى، أو بناء موقع يعيد أخطاءً لحظةَ تعثّر خادمه الخلفي (backend). كما أننا لا ندّعي أن الوصلة (seam) مجانية، فللتجريد كلفةٌ في الالتفاف غير المباشر (indirection). ندفعها عن دراية، لأن البديل هو دفع ضريبة هجرة لاحقًا، مع فائدتها.

المبدأ: اعتمدْ على وصلة، لا على مزوّد. إن كانت طبقة محتواك يمكن تبديلها بمتغيّر بيئة واحد وتنجو من إظلام خادمها الخلفي، فأنت تملك محتواك. أمّا إن كان تبديلها يعني إعادة كتابة، فالمزوّد يملكك. ونحن نفضّل أن نتحمّل قليلًا من الالتفاف غير المباشر الآن على أن نمنح غيرنا حق نقضٍ (veto) على خارطة طريقنا.