سر عداء الـ Backend والـ Frontend !

المقدمة

في عالم البرمجة، هناك علاقة غريبة بين مطوري الـ Backend ومطوري الـ Frontend
أحيانًا تشعر وكأنهما في معسكرين منفصلين، كل منهما يعمل بشكل مستقل دون أن يكون هناك تواصل حقيقي بينهما
وكل منهما يعتقد أن الآخر هو السبب في المشاكل التي تواجه المشروع
وكلايهما يظن أنه أهم شخص في الفريق وتجد من يقول أن الـ Backend هو أساس كل شيء، ومنهم من يقول أن الـ Frontend أهم شيء في المشروع
حتى وإن كانت الشركة بها مطور Backend واحد ومطور Frontend واحد فقط، تجد بينهما صدامات ومشاكل في التواصل

وتجد هذا يحمل فأسه الحادة أينما ذهب والآخر يسن سيفه ويجهز للمعركة

فما سر هذا العداء المستمر وكيف نستطيع أن نحد من هذا الأمر ونحله
وكيف تتعامل الشركات أو الفرق البرمجية مع هذا التحدي ؟

في هذه المقالة المميزة، سأشارككم تجربتي الشخصية في هذا الموضوع
المقالة مميزة لأنها ليست من منظوري الخاص فقط، بل شارك في هذه المقالة مجموعة من المطورين
من خلال آرائهم وتجاربهم الشخصية في هذا الموضوع

هذه المقالة ستوفر عليك تكلفة شراء الفأس والسيف وتعلمك كيف تتعامل مع الطرف الآخر كشريك وليس كعدو

لماذا يحدث الصدام ؟

في البداية لدينا العديد من النقاط التي يجب أن نفهمها جيدًا
وكل نقطة تمثل جانب من جوانب المشكلة

من هذه النقاط:

• انعزالية الطرفين
• جهل طبيعة عمل الطرف الآخر والصعوبات التي يواجهها
• عدم فهم مسؤوليات كل طرف
• غياب النقاش المبكر قبل التنفيذ
• التعامل مع الـ User Story أو المطلوب من زاوية واحدة فقط
• عدم وضوح الـ API أو طريقة التعامل معها
• التغييرات المفاجئة في الـ API أو الـ UI
• غياب المعايير الموحدة أي عدم اتباع الـ Standards
• الأنانية والكبرياء واتهام الطرف الآخر

هذه أهم النقاط التى أراها تسبب هذه المشكلة

وسأحاول توضيحها في أربع محاور رئيسية وهى:

1. فهم دور كل طرف والصعوبات التي يواجهها
2. التعامل مع الـ User Story من زاوية واحدة
3. التغييرات المفاجئة وكيفية التعامل معها
4. غياب المعايير الموحدة Standards

فهم دور كل طرف والصعوبات التي يواجهها

من المهم أن نفهم طبيعة عمل كل طرف ودوره في المشروع
وما الصعوبات التي يواجهها في عمله لنعرف كيف يمكن لكل منهما أن يدعم الآخر

فكرة أن كل طرف سواء كان مطور Backend أو Frontend يعمل في فراغ منفصل عن الآخر هي فكرة خاطئة تمامًا

دعونا نسمع أراء أحد الأصدقاء حول هذا الموضوع ونتناقشها

أظن أن سبب وجود المشكلة بين الاثنين هو جهل كل طرف بمهمة الطرف الآخر

1. فتجد أن الـ Backend يقوم بإرجاع الـ API Response بالشكل الذي يراه مناسبًا دون مراعاة قدرة الـ Frontend على التعامل معه
   فينتج لنا API Response غير مرن أو معقد جدًا أو يحتاج إلى عمليات حسابية كثيرة في الـ Frontend
2. في حالة ارجاع الـ Backend للبيانات بشكل مرن وبسيط تجد أن الـ Frontend أحيانًا يستسهل أن يقوم ببعض العمليات والـ mapping فيطلب من الـ Backend أن يرجع البيانات بشكل مخصص جدا بما يتناسب مع هوى الـ Frontend وينتج لنا API Response غير مرن ومعقد أو مخصص جدًا لاحتياج واحد يتناسب مع شكل معين في الـ UI

وهذا الكلام صحيح جدًا ونقطة مهمة جدًا تحتاج لتفصيل

يجب أن نعرف هنا أنه ليس هناك ضرر في أن يكون لدى الـ Backend معرفة بطبيعة عمل الـ Frontend والعكس صحيح
ليعرف كل منهما كيف يفكر الآخر وما هي الصعوبات والتحديات التي يواجهها في عمله
وما هي الحدود التي لا يستطيع تجاوزها وكيف يمكننا التعاون معًا لتجاوز هذه الحدود

صديقنا هنا نوه إلى نقطتين مهمتين:

النقطة الأولى: طبيعة عمل الـ Backend

الـ Backend مهمته الأساسية هى أن يكون حلقة الوصل بين الـ Database والـ Client ويحتوى على الـ Business Logic بشكل عام
والـ Client هنا قد يكون الـ Frontend سواء كان Website App أو Mobile App أو أي Client آخر

بالتالي الـ Backend يجب أن يرجع البيانات بشكل عام ومرن لكي يستطيع أي Client مهما كان أن يستخدم هذه الـ API ويعرضها في الـ UI بما يناسبه
وأهم شيء أن يكون الـ API Response بسيط وسهل الفهم والاستخدام

ومن الجيد أحيانًا أن يقوم الـ Backend بوضع نفسه مكان الـ Frontend ويتخيل كيف سيستخدم هذه البيانات في الـ UI
لأن هناك شخص لديه أسرة وبيت وأطفال سيقوم باستخدام هذه الـ API ويحتاج أن تكون سهلة الفهم والاستخدام
لا نريد أن نعقد الأمور على الـ Frontend ونصيبه بأزمة قلبية بسبب تعقيد الـ API Response

فدائمًا يجب أن يسأل الـ Backend نفسه:

• ما هي طبيعة البيانات التي يحتاجها الـ Frontend لعرضها في الـ UI ؟
• هل يستطيع الـ Frontend التعامل مع هذه البيانات بسهولة ؟ هل يستطيع عمل Mapping أو Transformation بسهولة ؟
• هل الـ Frontend يحتاج indicators مثل is_best_seller أو is_new_arrival وهل يحتاج لعمل filters أو sorting عليها أم لا
• هل يحتاج معلومات صلاحيات مثل can_edit أو can_delete لإظهار أو إخفاء الأزرار

النقطة الثانية: طبيعة عمل الـ Frontend

الـ Frontend مهمته هو عرض البيانات في الـ UI بالشكل المناسب بما يتناسب مع تجربة المستخدم الـ UX
وبما يتوافق مع متطلبات الـ Business Analyst
الـ Frontend يجب أن يفهم حدود الـ Backend وما الذي يستطيع فعله وما الذي لا يستطيع
ويدرك أن الـ Backend يستطيع أن يعطيك البيانات بشكل خام لتكون مرنة في عرضها في أي UI
بالتالي يجب أن يقوم الـ Frontend بعمل Mapping وTransformation على هذه البيانات لتناسب احتياجات الـ UI الخاصة به

ولا يجب على الـ Frontend أن يطلب من الـ Backend أن يرجع له بيانات مخصصة جدًا لاحتياج معين في الـ UI
بمعنى عمليات الـ Mapping أو الـ Transformation الـ Grouping التى تخص الـ UI ليس من مسؤولية الـ Backend
فهذا يجعل الـ API Response غير مرن ويصعب استخدامه في حالات أخرى وخصوصًا في حالة وجود أكثر من Client يستخدم نفس الـ API

الـ Backend يستطيع أن يساعدك في ارجاع بيانات بشكل معين لكن في حدود المعقول لأن وظيفة الـ Backend أن يرجع لك البيانات بشكل عام ومرن
لكي يمكن عرضها في الـ Website App أو الـ Mobile App أو أي Client آخر يريد استخدام هذه الـ API ليعرضها بما يناسبه
أما عمليات الـ Mapping أو الـ Transformation التى تخص الـ UI فهي من مسؤولية الـ Frontend

وبالنسبة لنقطة هل من مسؤولية الـ Backend أن يرسل indicator في الـ API Response مثل can_edit, can_delete
للـ Frontend ليستخدمها في إظهار أو إخفاء الأزرار بناءً على صلاحيات المستخدم
أم هذه من مسؤولية الـ Frontend ؟

أحد الأصدقاء اعترض على هذا الأمر لي وقال لي:

الـ Frontend يستطيع أن يخفي الأزرار بناءً على صلاحيات المستخدم ولا حاجة لأن يرسل له الـ Backend هذه المعلومات
لأن الـ Frontend سيكون لديه معلومات عن الـ User Role والصلاحيات الخاصة به
وبالتالي يستطيع أن يحدد هل يظهر هذه الأزرار أم لا بناءً على هذه الصلاحيات

وهذا كلام صحيح في بعض الحالات، لكن في حالات أخرى قد يكون من الأفضل أن يرسلها الـ Backend لتقليل التعقيد في الـ Frontend
وخصوصًا عندما يتعقد المشروع فتتعقد الشروط والصلاحيات ويصبح من الصعب على الـ Frontend أن يدير كل هذه التعقيدات بمفرده
لذا من الأسهل أن يرسلها الـ Backend لتسهيل عمل الـ Frontend وخصوصًا أنه في أغلب الأحيان الـ Backend لديه معلومات أكثر عن صلاحيات المستخدم
وهناك بعض الصلاحيات تحتاج لعمل queries معقدة في الـ Database لتحديدها

التعامل مع الـ User Story من زاوية واحدة

من المشاكل الشائعة التي تحدث هي أن كل طرف يتعامل مع الـ User Story أو مع متطلبات الـ Business Analyst من زاوية واحدة فقط
بمعنى أن الـ Backend ينظر إلى الـ User Story من زاوية الـ Backend فقط ثم يقوم مباشرًا بتنفيذ الـ API
وكذالك الـ Frontend ينظر إلى الـ User Story من زاوية الـ Frontend فقط ثم يقوم بتنفيذ الـ UI برمجيًا

دون أن يرجع كل منهما للطرف الآخر ليفهم كيف يرى الطرف الآخر الـ User Story وكيف يفكر في تنفيذها
حتى وإن كان كل طرف منهما يفهم وظيفة الآخر كما ذكرنا في الفقرة السابقة
يظل من المهم أن يكون هناك تواصل بين الطرفين لفهم المطلوب بشكل أفضل قبل الشروع في التنفيذ

هنا يأتي تعليق مهم من أحد الأصدقاء أصحاب الخبرة:

في رأيي أن هذا الأمر يعتمد بشكل أساسي على الفهم الصحيح للـ User Story
لذلك نقوم بمرحلة الـ Planning حيث يشرح فريق الـ Business Analyst ما هو المطلوب بشكل واضح
وبعد ذلك يجتمع الـ Frontend والـ Backend ويتفقان على شكل الـ API Response وكيفية التعامل معها
لهذا السبب يأتي دور أدوات مثل OpenAPI التي تعمل كعقد contract بين جميع الأطراف
حتى في بعض الأحيان يكون من المفيد أن يقوم فريق الـ Business Analyst بمراجعته والموافقة عليه
قبل شروع أي طرف في التنفيذ

هذا هو الحل الأمثل، النقاش المبكر قبل التنفيذ

هنا لدينا الكثير من الفوائد والأمور التي يجب أن نلتزم بها
أولها وأهمها هو النقاش المبكر قبل التنفيذ
بمعنى أن هناك اجتماع مشترك بين الـ Backend والـ Frontend والـ Business Analyst أو الـ Product Owner أول صاحب الـ User Story بشكل عام

هذا الإجتماع يسمى Planning أو Grooming أو Refinement حسب تسميات الشركات المختلفة
في هذا الاجتماع يتم مناقشة الـ User Story بشكل مفصل من جميع الأطراف
الـ Business Analyst يشرح المطلوب بشكل واضح ويتأكد أن كل شخص فهم المطلوب بشكل صحيح
ثم يقوم الـ Frontend والـ Backend بسؤال أي أسئلة أو استفسارات حول المطلوب

بعد الانتهاء من شرح الـ User Story، يبدأ الـ Backend والـ Frontend في مناقشة كيفية تنفيذ المطلوب
ويحددان الصعوبات التي قد تواجه كل منهما في تنفيذ المطلوب
ويبحثان عن حلول لهذه الصعوبات معًا
ويتفقان على شكل الـ API Response وكيفية التعامل معها في الـ UI
وهنا يتم عمل API Contract باستخدام OpenAPI أو أي أداة أخرى
يلتزم بها الجميع في تنفيذ المطلوب

هذه الاتفقات تكون مبدئية وقابلة للتغيير لاحقًا إذا دعت الحاجة

لكن هذا النقاش المبكر يوفر الكثير من الوقت والجهد لاحقًا
ويمنع الكثير من المشاكل التي قد تحدث لاحقًا بسبب سوء الفهم أو التغييرات المفاجئة

التعاون بين الـ Backend والـ Frontend مهم جدًا في فهم المطلوب من الـ User Story وكيفية تنفيذها بشكل صحيح
أحيانًا الـ Frontend يخدم الـ Backend في بعض الأشياء والعكس صحيح
فهم طبيعة عمل كل منهما وكيفية التعاون معًا هو ما يجعل المشروع ناجحًا

أحيانًا يكون صعوبة تقنية في تنفيذ المطلوب من الـ User Story
سواء من الـ Backend أو الـ Frontend وقد يتتطلب تنفيذها تغيرات و refactor في الكود
بالتالي يتم أخذ هذه الأمور في الاعتبار أثناء المناقشة الـ User Story
ويتم تبليغ الـ Business Analyst بأي صعوبات قد تواجه التنفيذ
بالتالي قد يتم تعديل الـ User Story أو تقسيمها إلى أكثر من User Story لتسهيل التنفيذ وامداد الوقت اللازم
من المهم جدًا أن يكون هناك تواصل مستمر بين جميع الأطراف طوال فترة تنفيذ الـ User Story
ليعرف كل شخص لماذا يتأخر التنفيذ أو ما هي المشاكل التي تواجهه وهل يمكننا الإستغناء عن جزء معين من المطلوب أو تأجيله لوقت لاحق

قصة واقعية من تجربتي الشخصية

دعوني أشارككم قصة حقيقية حدثت لي، كنت مطور Backend في أحد المشاريع

كان هناك User Story بسيطة وسهلة، فقط أقوم بإرجاع بيانات معينة ليتم عرضها في جدول في الـ UI
لنتخيل أن هذا الجدول هو جدول منتجات يقوم بمقارنة الأسعار المعروضة لكل منتج
بمجرد أن قرأت الـ User Story، قلت في نفسي إن هذا المطلوب بسيط جدًا واعتيادي ونفذناه أكثر من مرة من قبل

فقمت سريعًا بتنفيذ الـ API بكل سهولة ومررتها إلى مطور الـ Frontend دون أن أركز في شكل الـ UI أو كيف سيتم عرضها في الجدول
كل ما يهمني أن هناك بعض البيانات التي يجب أن أرجعها في الـ API

بعد انتهائي من تنفيذ الـ API، فوجئت بأن الـ Frontend لا يستطيع عرضها في الجدول بالشكل المطلوب
وكنت أحيانًا أتجادل وأقول أنني أرجع لك المطلوب وأنت حاول أن تعرضها في الجدول

لكن ما زال الـ Frontend لا يستطيع عرضها في الجدول أو يواجه مشاكل في عرضها
ظننت أن المشكلة في الـ Frontend وفي قدراته التقنية

لكن بعد أن تدخل الـ Senior الذي يشرف علي وتناقشت مع الـ Frontend والـ Business Analyst الذي كتب الـ User Story
وانعقاد محكمة بين الجميع، تم الحكم بأنني لم أفهم الـ User Story بشكل صحيح
وأنني لم أقم بمناقشتها مع الـ Frontend قبل تنفيذ الـ API ولم اهتم حتى برؤية شكل الـ UI

اتضح أن الجدول الذي يريدونه في الـ UI يحتاج إلى أن أرجعه بشكل معين وأن أكرر بعض البيانات بشكل معين
لكي يستطيع الـ Frontend عرضها في الجدول على شكل مقارنات

لو كنت قد ناقشت الـ User Story مع الـ Frontend قبل تنفيذ الـ API
ما كنت لأقع في هذا الخطأ ولم نكن لنضيع كل هذا الوقت في الجدال وتأخير المشروع
لذا النقاش المبكر قبل التنفيذ هو الحل الأمثل لتجنب هذه المشاكل

التغييرات المفاجئة وكيفية التعامل معها

دائمًا أثناء تنفيذ الـ User Story أو بعد انتهائها، قد تحدث تغييرات مفاجئة في الـ API أو الـ UI
وهذا الأمر له أكثر من حالة

الحالة الأولى: التغييرات التي تحدث أثناء تنفيذ الـ User Story

تعليق من أحد الأصدقاء:

أحيانًا بعد التفاهم بين الـ Backend والـ Frontend وبدء كل شخص بعمله، فجأة يقوم الـ Backend بتغيير الـ API بالكامل ويبلغ الـ Frontend بشكل مفاجئ مما يسبب مشاكل كبيرة في الـ Frontend

قلنا سابقًا أن النقاش المبكر قبل التنفيذ هو الحل الأمثل لتجنب المشاكل
لكن هذا لا يعني أن كل شيء سيكون مثاليًا ولن تحدث تغييرات أثناء التنفيذ
لذا في حالة أننا قمنا بعمل Planning و Grooming جيد وفهمنا المطلوب بشكل صحيح
وقمنا بالتزام بـ API Contract وبدأ كل شخص في تنفيذ المطلوب

قد تحدث تغييرات أثناء التنفيذ لأي سبب من الأسباب سواء من طرف الـ Backend أو الـ Frontend
لكن لو التزمنا بالنقاش المبكر قبل التنفيذ، ستكون هذه التغييرات أقل بكثير أو بسيطة

على أي حال في حالة حدوث تغييرات، يجب أن يكون هناك تواصل مستمر بين الطرفين

ونسأل أنفسنا بعض الأسئلة المهمة:

• وهل هذه التغييرات ضرورية أم لا، بالتالي يمكننا تجاهلها في الوقت الحالي مع اعلام الطرف الآخر بها
• هل هذه التغيرات ستؤثر على الـ User Story الحالية أم لا
  بالتالي يجب أن نبلغ الـ Business Analyst ليقرر:
  • هل نؤجل هذه التغييرات لوقت لاحق أم لا
  • هل يمكننا فصل هذه التغييرات إلى User Story جديدة أم لا
• هل هذه التغييرات ستؤثر على الـ UI أو على الـ API Contract أم لا
  • بالتالي علينا اعادة مناقشة الـ API Contract مع الطرف الآخر

كل هذه الأسئلة يجب أن نجيب عليها قبل تنفيذ أي تغييرات
لأنه مع النقاش المبكر قبل التنفيذ ستجد نفسك في موقف أفضل لفهم تأثير هذه التغييرات
في معظم الحالات قد نقرر تأجيل هذه التغييرات لوقت لاحق أو فصلها إلى User Story جديدة

الحالة الثانية: التغييرات التي تحدث بعد الانتهاء من تنفيذ الـ User Story

بعد الانتهاء من تنفيذ الـ User Story وتسليمها للـ QA أو الـ Business Analyst للمراجعة والاختبار، قد تظهر بعض التغييرات أو الملاحظات
وهذا أمر طبيعي جدًا في أي مشروع برمجي
قد يطلب الـ Business Analyst أو الـ QA بعض التغييرات في الـ UI أو في الـ API بناءً على الملاحظات التي يجدونها أثناء الاختبار
في هذه الحالة، يجب أن نتعامل مع هذه التغييرات على أنها User Story جديدة أو يقال عليها Change Request وتكون Sub Task من الـ User Story الأصلية
وبالتالي يتم مناقشتها مرة أخرى بين الـ Backend والـ Frontend في وقت لاحق بحسب الأولويات

أحيانًا قد يضطر الـ Backend بعد أشهر من تنفيذ الـ User Story إلى عمل refactor أو تغييرات جذرية في الكود ويأثر هذا على الـ API Contract لـ ‘User Story قديمة
في هذه الحالة يقوم الـ Backend بإبلاغ الـ Frontend بهذه التغييرات ويشرح لهم السبب قبل تنفيذها
ثم يقوم بالحديث مع الـ Business Analyst ليقوم بكتابة User Story جديدة توضح هذه التغييرات لكي يتم متابعتها واعطاء أولوية لها أو تأجيلها لوقت لاحق
وبهذا النظام لا نؤثر على سير المشروع الحالي بل كل تغير يتم التعامل معه كـ User Story جديدة

خلاصة القول في التغييرات المفاجئة

في شركتي، بعد أن أتفق أنا كـ Backend مع الـ Frontend على شكل الـ API
لا يحق لأي أحد في الفريق أن يغير الـ API إلا بعد مناقشة مع الطرف الآخر والموافقة على التغيير
والموافقة هنا قد تشمل تأجيلها أو كتابتها كـ User Story جديدة أو تعجيلها حسب الأولويات

فيما بعد إذا قرر أحد الأطراف التغير سواء أراد الـ Frontend عرض بعض من مهارته في الـ UX وطلب تغييرات في الـ API Contract
أو أراد الـ Backend تحسين الكود أو عمل refactor لتحسين الـ performance أو لأي سبب آخر وهذا سيؤثر على الـ API Contract
أو أراد صديقنا العزيز صاحب الـ Business Analyst إضافة بعض المتطلبات الجديدة التي تسبب تغيرات جزرية في كل شيء

على كل فرد أن يقوم بالخطوات التالية:

1. كل طرف يبلغ الطرف الآخر ويشرح له السبب
2. يتم ابلاغ الـ Business Analyst حتى وإن كان التغيرات تقنية وتحسين فقط في الأداء ولن تأثر على الـ UI
3. يتم كتابة User Story جديدة توضح التغييرات الجديدة واعطاء أولوية لها أو تأجيلها حسب الأولويات

بالتالي لا نؤثر على سير المشروع ونعطي أولوية لأمور و User Stories أخرى
وطريقة إبلاغ الـ Business Analyst أن يكتب User Story جديدة مستقلة بالتغييرات الجديدة أو المقترحة
دون أن نؤثر على الـ User Story الحالية التي يقوم الـ Backend والـ Frontend بتنفيذها

ملحوظة: ليس شرطًا أن أن يكون دايمًا الـ Business Analyst هو الذي يكتب الـ User Story الجديدة
في بعض الأحيان قد يكون الـ Backend أو الـ Frontend هو الذي يكتبها بناءً على التغييرات التي يريدها وخصوصًا إذا كانت تغييرات تقنية بحتة
لكن برغم هذا على الـ Business Analyst أن يراجعها ويعطي أولوية لها أو يؤجلها حسب الأولويات

غياب المعايير الموحدة Standards

المحور الرابع والأخير من محاور المشكلة هو غياب المعايير الموحدة Standards

كل النزاع يكون مبنيًا على آراء شخصية لكل طرف دون وعي بضرورة تطبيق الأشياء وفق معايير Standards موحدة
لأنه من الطبيعي أنك في يوم من الأيام ستترك هذا العمل وسيعمل عليه شخص آخر غيرك

وهذا كلام في غاية الأهمية ويحتاج لتفصيل لأنه من أكثر الأسباب التي تسبب مشاكل بين الـ Backend والـ Frontend
وهذا المحور تحديدًا حظى باهتمام كبير من الأصدقاء الذين شاركوا في هذه المقالة

سأستعرض بعض الأمثلة والأراء ونناقشها معًا

تخيل معي أن تعمل مع Backend كل endpoint له شكل مختلف في إرجاع الـ errors
أحيانًا يرجع لك error بهذا الشكل:

{
  "error": "Invalid input"
}

وأحيانًا بهذا الشكل:

{
  "message": "Invalid input",
  "code": 400
}

وأحيانًا بهذا الشكل:

{
  "errors": [
    {
      "field": "email",
      "message": "Invalid email"
    }
  ]
}

كيف ستتعامل مع كل هذه الأشكال المختلفة في الـ Frontend ؟

ستحتاج إلى كتابة كود معقد جدًا للتعامل مع كل هذه الحالات
وستقضي وقتًا طويلاً في التعامل مع الـ errors بدلاً من التركيز على الـ UI

وهذا ما حدث بالفعل مع أحد الأصدقاء:

أنا كـ Frontend أعمل مع Backend لا يلتزم بشكل موحد للـ errors
بعض الـ endpoints ترجع error بشكل معين وبعضها بشكل مختلف
مما يسبب لي مشاكل في التعامل مع الـ errors في كامل التطبيق

وهذه مشكلة شائعة جدًا ليس فقط في الـ errors بل في كل شيء

أحد الأصدقاء قال لي:

معظم الخلافات تكون على شكل الـ Response دايمًا ما تكون مختلفة برغم من أنها تنتمي لنفس الـ Model
فعلى سبيل المثال لدينا Model يدعى Offer المشكلة أن صديقنا الـ Backend يقوم بارجاعه بشكل مختلف في كل مرة مع كل endpoint برغم أنه نفس الـ Model ونفس هيكل البيانات
فنبدأ في الجدال لأننا نقرأ من Model واحد ونبني عليه عمليات مثل الـ Parsing لكي نستطيع عرضها
فمن غير المنطقي أن يكون هناك أكثر من شكل لـ Model الـ Offer وأضطر لعمل Parsing مختلف لنفس البيانات

وتعليق أخر من أحد الأصدقاء:

المشكلة ليست في شكل الـ Response لكن أيضًا في التسمية الخاصة بالبيانات
فمثلاً في بعض الـ endpoints تجد أن الـ Backend يستخدم snake_case في أسماء الحقول
وفي بعض الـ endpoints يستخدم camelCase
أو يرجع حقول بتسميات لا تعبر عن محتواها بشكل واضح فمثلًا يرسل لي reward_points وهى في الحقيقة تعني used_points
ويرفض تغيرها لأي سبب غير مفهوم

لاحظ أن بعض هذه المشاكل تحدث بسبب غياب النقاش المبكر قبل التنفيذ
وانعزالية الطرفين وعدم فهم دور كل طرف كما ذكرنا في المحاور السابقة

لكن معظم هذه المشاكل تحدث بسبب غياب المعايير الموحدة Standards
مثل توحيد الـ API Response والـ Errors والتسميات وغيرها
وهذه من بديهيات تعلم الـ Restful API والالتزام بها على قدر الإمكان
وهذه تعد من المشاكل التنظيمية التي تحدث في كثير من الشركات والفرق البرمجية

كيف نحل مشكلة غياب المعايير ؟

الحل بسيط جدًا، وضع معايير موحدة Standards يلتزم بها الجميع
سواء معايير متعارف عليها كـ Restful API Standards أو معايير خاصة بالشركة أو الفريق البرمجي يتم الاتفاق عليها
ومحاولة عمل Documentation لهذه المعايير لكي يلتزم بها الجميع وحتى يراها الأعضاء الجدد الذين ينضمون للفريق لاحقًا

من المهم وجود شخص ذو خبرة في الفريق يكون مسؤول عن وضع هذه المعايير ومتابعة الالتزام بها

جعل كل طرف يقوم بـ Code Review للطرف الآخر
بمعنى أن الـ Backend يراجع كود الـ Frontend والـ Frontend يراجع كود الـ Backend
هذا يفيد في فهم كيف يفكر الطرف الآخر وما هي الصعوبات التي يواجهها
وأيضًا يساعد في الالتزام بالمعايير الموحدة Standards
ومعرفة هل كل شخص استطاع التعامل مع الـ API Contract بشكل صحيح أم لا

بالطبع عليك أن تعلم أن المعايير ليست ثابتة

أي أن نفهم أن الـ Standards أو المعايير الخاصة بالشركة والفريق التقني ليست ثابتة
قد نحتاج لتعديلها أو تحديثها مع الوقت أو نتغاضى عن بعضها في حالات معينة فنحن لا نغصب أحد عليها

لكن المهم أن نلتزم بها في الوقت الحالي
وإذا احتجنا لتعديلها، نناقشها مع الفريق ونتفق على التعديلات الجديدة
ثم نقوم بتحديث التوثيق ونبلغ الجميع بالتغييرات

لذا اتبع الـ Standards الموحدة لكي تسهل على من سيأتي بعدك

الخاتمة

بعد كل ما ناقشناه في هذه المقالة، نستطيع أن نقول:

أن العلاقة بين الـ Backend والـ Frontend ليست علاقة عداء، بل هي شراكة

كلاهما يحتاج الآخر لإنجاح المشروع، ولا يمكن لأي منهما العمل بمفرده
المشاكل التي تحدث بينهما ليست حتمية، بل هي نتيجة لسوء الفهم وغياب التواصل ما بينهما

ناقشنا في هذه المقالة أربع محاور رئيسية تسبب الصدام بين الـ Backend والـ Frontend:

1. الجهل بطبيعة عمل الطرف الآخر: عدم فهم دور ومسؤوليات وصعوبات كل طرف
2. التعامل مع الـ User Story من زاوية واحدة: عدم النقاش المبكر قبل التنفيذ
3. التغييرات المفاجئة: عدم التواصل عند حدوث تغييرات في الـ API أو الـ UI
4. غياب المعايير الموحدة: عدم وجود Standards واضحة يلتزم بها الجميع

وبعض حلول هذه المشاكل وغيرها هي:

1. النقاش المبكر قبل التنفيذ:
   • اجتماعات Planning أو Grooming مشتركة بين الجميع
   • مناقشة الـ User Story بشكل مفصل من جميع الأطراف
   • الاتفاق على API Contract باستخدام OpenAPI أو أدوات مشابهة
2. التواصل المستمر بين كل الأطراف طوال فترة تنفيذ الـ User Story:
   • إبلاغ الطرف الآخر بأي تغييرات قبل تنفيذها
   • كتابة User Story جديدة لأي تغييرات جذرية أو حتى تحسينات بسيطة
3. اتباع المعايير الموحدة:
   • وضع Standards واضحة للـ API Responses والـ Errors
   • استخدام شكل موحد للتسمية مثل camelCase أو snake_case
   • وتوحيد الـ Models والـ Responses بين جميع الـ endpoints
   • محاولة كتابة Documentation لهذه المعايير
   • عمل Code Review بين الطرفين لمراجعة الكود
4. فهم دور كل طرف:
   • الـ Backend يفهم كيف ستعرض البيانات في الـ UI
   • الـ Frontend يفهم حدود وإمكانيات الـ Backend
   • كل منهما يضع نفسه مكان الآخر
5. التواضع وقبول الخطأ:
   • لا تتعامل بأنانية أو كبرياء مع الطرف الآخر
   • فكر قبل أن تتهم الآخر بالخطأ، ربما أنت المخطئ
   • الهدف هو نجاح المشروع وليس إثبات أنك على صواب

على أي حال بالنسبة لنقطة غياب المعايير الموحدة Standards وأن نعظم حلها هو وضع معايير موحدة يلتزم بها الجميع
وخصوصًا أن يكون كلا الطرفين على علم بمعايير الـ API المتعارف عليها مثل Restful API
بكتابة مقالتين عن هذا الموضوع الأولى هى التعامل مع أي RESTful API وفهم مكوناته كتبتها لصديق لي مطور Frontend أراد أن يفهم كيف يتعامل مع أي API
والثانية هى بناء RESTful API متوافق مع المبادئ كتبتها لأصدقائي مطوري الـ Backend لكي يفهموا كيف يصمموا API بشكل صحيح