لماذا قررت فصل الباك اند عن الفرونت اند؟

قبل سنتين تقريبًا، كنت أتعلم البرمجة وبدأت أتعرف على مفهوم الباك اند. كأي مبتدئ، كنت أبحث عن حلول بسيطة وسهلة تساعدني على بناء تطبيقات عملية. في ذلك الوقت، تعرفت على مفهوم BAAS (Backend as a Service)، وبدأت باستخدام Firebase. ساعدني Firebase كثيرًا في بناء تطبيقات بسيطة مثل تطبيقات المحادثة ومشاريع صغيرة للسوشيال ميديا.

مع مرور الوقت وتعلمي React وNext.js، أصبحت أكتب الباك اند بنفسي، حيث وفرت لي Next.js ميزة كتابة الـAPI داخل نفس الكود بيس الخاص بالفرونت اند. بقيت أعتمد على هذا الأسلوب لسنوات وكنت أراه عمليًا ومناسبًا للمشاريع الصغيرة.

لماذا قررت التغيير؟

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

الأسباب التي دفعتني لفصل الباك اند عن الفرونت اند

1. تنظيم الكود وتحسين الهيكلية:

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

1. قابلية التوسع:

مشاريع SaaS تحتاج بنية قابلة للتوسع بسهولة. فصل الباك اند يجعل التطوير أكثر مرونة وقابلية لتوسيع المشروع دون المساس بالفرونت اند. يمكنك تغيير البنية التحتية للباك اند أو إضافة خدمات جديدة بسهولة.

1. الاستقلالية بين الفرق:

في المشاريع التي تتطلب العمل ضمن فريق، وجود كود بيس منفصل لكل جزء (الباك اند والفرونت اند) يجعل كل فريق يركز على جزء محدد دون تعقيدات إضافية.

1. تحسين الأداء:

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

1. التوثيق والمعايير:

العمل على باك اند منفصل يتيح استخدام أدوات مثل Swagger UI وOpenAPI لتوثيق الـAPIs، مما يجعل النظام أكثر وضوحًا وسهولة في الفهم للمطورين الآخرين.

1. المرونة التقنية:

يمكنك استخدام تقنيات حديثة ومخصصة لكل جزء. في حالتي، أستخدم:

Express.js: لإنشاء RESTful APIs.

Prisma ORM: لإدارة قاعدة البيانات والتعامل مع PostgreSQL بكفاءة.

TypeScript: لتوفير أمان عالٍ في كتابة الكود وتقليل الأخطاء.

PostgreSQL: كقاعدة بيانات قوية وقابلة للتوسع.

Railway: لإدارة ونشر الباك اند.

Vercel: لاستضافة الفرونت اند باستخدام Next.js.

Swagger UI وOpenAPI: لتوثيق الـAPIs.

1. قابلية الاختبار والصيانة:

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

1. التعلم والتحسين:

العمل على باك اند منفصل يفتح لك آفاقًا جديدة لتعلم تقنيات وأدوات متقدمة. بالنسبة لي، أتعلم يوميًا كيفية تحسين الـAPI، تحسين قواعد البيانات، واستغلال الأدوات الحديثة مثل Prisma وTypeScript.

ملاحظات إضافية:

الكود بيس المشترك لمشاريع صغيرة:

إذا كنت تعمل على مشروع صغير أو MVP، يمكن أن يكون وجود كود بيس واحد لكل من الباك اند والفرونت اند خيارًا عمليًا وسريعًا.

الباك اند المنفصل للمشاريع الكبيرة:

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

الخلاصة:

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

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