المشكلة
تدير وكالة التواصل الاجتماعي حسابات عملاء كثيرين في آنٍ واحد: محتوى يجب التخطيط له، وموافقات يجب جمعها، وجداول نشر يجب ألّا تتعارض. ينجح العمل بجداول البيانات ومجموعات المحادثة حتى العميل الثالث، ثم تتوزع الموافقات في أماكن مختلفة ولا يعرف أحد ما الذي سيُنشر غدًا.
ما الذي طوّرته
منصة عمل للوكالات متعددة المستأجرين منذ البداية: تسجّل كل وكالة وتحصل على مساحتها المستقلة، بعملائها وفريقها وبياناتها الخاصة. تخطيط المحتوى ومسارات الموافقة والتقويم المشترك كلها في مكان واحد، مع أدوار تحدد من يحق له النشر ومن يقتصر دوره على الاقتراح.
التقنيات المستخدمة
Next.js على خادم VPS مشترك مع خدمات أخرى، مع المصادقة وعزل المستأجرين مدمجَين في البنية الأساسية لا مضافَين لاحقًا. تصدر التحديثات على مراحل، وكل ما يمس إعدادات خادم الويب يُتحقق منه قبل إطلاقه، لأن مواقع أخرى تعمل على الجهاز نفسه.
لماذا بهذه الطريقة
صُمّمت المنصة لتخدم وكالات عديدة منذ اليوم الأول، مع أنها انطلقت بوكالة واحدة. فإضافة تعدد المستأجرين لاحقًا إلى تطبيق مبني لعميل واحد تعني تعديل كل استعلام يقرأ البيانات على أمل ألّا يُنسى أيٌّ منها — وهو نوع من إعادة العمل يكلّف أكثر من البناء الأصلي.
