الواجهة الأمامية مقابل الخلفية: ما الفرق؟
الواجهة الأمامية هي الجزء من التطبيق الذي يعمل في متصفح المستخدم، أي الصفحات والأزرار والنماذج والحركات التي يراها ويضغط عليها. أما الخلفية فهي الجزء الذي يعمل على خادم لا يراه المستخدم أبداً: تخزّن البيانات وتسترجعها، وتطبّق قواعد العمل، وتتحقق من صلاحية كل شخص لتنفيذ ما يريده، وتتواصل مع خدمات أخرى مثل المدفوعات والبريد الإلكتروني. يتواصل الطرفان عبر API، وإلى جانبهما قاعدة بيانات، ومعاً يشكّلون تطبيقاً «Full stack».
لماذا يهم هذا عند البناء بالذكاء الاصطناعي
عندما تصف تطبيقاً لأداة بناء تعمل بالذكاء الاصطناعي، فأنت تصف الجزأين معاً، سواء أدركت ذلك أم لا. فعبارة «يستطيع العملاء حجز موعد» تعني نموذج حجز (واجهة أمامية)، وقواعد تحدد المواعيد المتاحة (خلفية)، ومكاناً لحفظ الحجوزات (قاعدة بيانات).
معرفة هذا التقسيم تفيدك في ثلاثة أمور عملية:
- الأمان. كل ما في الواجهة الأمامية يستطيع المستخدم رؤيته وتغييره. لذلك يجب أن تبقى القواعد والمفاتيح السرية في الخلفية.
- تتبع الأخطاء. عبارة «الزر لا يستجيب» وعبارة «الزر يستجيب لكن شيئاً لا يُحفظ» تشيران إلى جزأين مختلفين، وإخبار الأداة بما تراه يساعدها على إيجاد السبب أسرع.
- الاستضافة والتكلفة. الموقع الذي يحتوي على واجهة أمامية فقط رخيص وبسيط في الاستضافة. أما الخلفية فيجب أن تعمل على مكان ما، وهذا يؤثر على ما تدفعه وعلى طريقة عمل تطبيقك عندما لا يكون أحد يستخدمه.
تشبيه من الحياة اليومية
تخيّل مطعماً.
الواجهة الأمامية هي قاعة الطعام: القائمة والطاولات والديكور والنادل الذي يأخذ طلبك. صُممت للزبائن، ويستطيعون رؤية كل شيء فيها ولمسه.
الخلفية هي المطبخ والمكتب: الطهاة الذين يعدّون الطعام، ومخزن المواد، والصندوق، والقواعد التي يضعها المدير حول من يحصل على خصم. لا يدخل الزبائن إلى هذا المكان، ولا يجب أن يتمكنوا من ذلك.
الـ API هي الممر بين الاثنين: نافذة الاستلام التي تدخل منها الطلبات وتخرج منها الأطباق، بصيغة متفق عليها. أما قاعدة البيانات فهي مخزن المواد وسجل الطلبات.
يستطيع الزبون أن يعدّل ورقة طلبه (الواجهة الأمامية تحت سيطرته)، لكن المطبخ ما زال يقرر ما يطبخه وما يحاسب عليه. لذلك يجب أن تبقى الفحوص المهمة في الخلف.
ماذا يفعل كل جانب
| الواجهة الأمامية | الخلفية | |
|---|---|---|
| تعمل على | جهاز المستخدم، داخل المتصفح | خادم تتحكم فيه أنت أو مزوّد الاستضافة |
| وظيفتها الأساسية | عرض المحتوى، وجمع المدخلات، والاستجابة للنقرات | تخزين البيانات، وتطبيق القواعد، وفرض الصلاحيات، واستدعاء الخدمات الأخرى |
| هل يستطيع المستخدمون رؤية الشيفرة وتغييرها؟ | نعم، فهي تُنزَّل إلى متصفحهم | لا |
| هل تستطيع حفظ مفاتيح API سرية؟ | لا | نعم، في متغيرات البيئة |
| التقنيات الشائعة | HTML وCSS وJavaScript/TypeScript وReact وVue وSvelte وTailwind | Node.js وPython (FastAPI وDjango) وC# وJava وGo وRuby |
| ما الذي يتعطل غالباً | تخطيط غير متناسق على الجوال، زر لا يعمل، صفحة بطيئة | بيانات لا تُحفظ، أو بيانات خاطئة، أو أخطاء، أو ثغرات أمنية |
بعض الأطر تمحو الفاصل بين الجانبين. فمثلاً يتيح Next.js أن يحتوي مشروع واحد على شيفرة للمتصفح وشيفرة للخادم معاً. تبقى الفكرة نفسها: السؤال دائماً هو أين تعمل هذه القطعة؟
مثال عملي: حجز حصة يوغا
إليك ما يحدث عندما يحجز شخص حصة يوغا، خطوة بخطوة.
| الخطوة | المكان | ما الذي يحدث |
|---|---|---|
| 1 | الواجهة الأمامية | تُحمَّل صفحة الجدول وتطلب من الخلفية حصص هذا الأسبوع. |
| 2 | الخلفية | تقرأ الحصص والحجوزات من قاعدة البيانات، وتحسب المقاعد المتبقية، وتعيد القائمة بصيغة JSON. |
| 3 | الواجهة الأمامية | تعرض كل حصة مع الوقت والمدرّب والمقاعد المتبقية. |
| 4 | الواجهة الأمامية | يختار المستخدم حصة ويملأ اسمه وبريده الإلكتروني. يتحقق النموذج من أن البريد يبدو صحيحاً (تنبيه مبدئي، وليس ضماناً). |
| 5 | من الواجهة الأمامية إلى الخلفية | يرسل طلب POST /api/bookings عبر الـ API. |
| 6 | الخلفية | تتحقق من المدخلات مرة أخرى، وتتأكد أن الحصة ليست ممتلئة، وتحفظ الحجز، وتطلب من خدمة البريد إرسال تأكيد باستخدام مفتاح سري. |
| 7 | من الخلفية إلى الواجهة الأمامية | تعيد الرد: «تم الحجز» أو «عذراً، الحصة ممتلئة». |
| 8 | الواجهة الأمامية | تعرض شاشة التأكيد. |
لاحظ الخطوتين 4 و6: المدخلات تُفحص مرتين. فحص الواجهة الأمامية يعطي ردّاً فورياً، أما فحص الخلفية فهو الذي يحسب فعلاً، لأن المستخدم المصمم يستطيع تجاوز الواجهة الأمامية كلياً.
شرح المصطلحات الشائعة
| المصطلح | المعنى |
|---|---|
| Client / server | العميل هو المتصفح (أو التطبيق) الذي يرسل الطلبات، والخادم هو الذي يجيب عليها. |
| UI | واجهة المستخدم، أي الشاشات والعناصر التي يتفاعل معها. |
| API | الطريقة المتفق عليها التي تطلب بها الواجهة الأمامية من الخلفية بيانات أو تنفيذ إجراء. |
| Endpoint | عنوان محدد واحد على الـ API، مثل /api/bookings. |
| Full stack | الواجهة الأمامية والخلفية وقاعدة البيانات معاً. انظر ما هو تطبيق Full stack. |
| Static site | واجهة أمامية بلا خلفية خاصة بها، إذ تُقدَّم الملفات نفسها للجميع. |
| SPA | تطبيق صفحة واحدة: واجهة أمامية تحدّث الصفحة داخل المتصفح بدلاً من تحميل صفحات جديدة. |
| Server-side rendering (SSR) | يبني الخادم HTML الصفحة قبل إرسالها، وهذا قد يحسّن السرعة ومحركات البحث. |
| Environment variables | إعدادات ومفاتيح سرية تُعطى للخلفية أثناء التشغيل، وتبقى خارج الشيفرة. |
هل يحتاج تطبيقك إلى خلفية؟
| إذا كان تطبيقك… | هل يحتاج إلى خلفية؟ |
|---|---|
| يعرض معلومات واحدة للجميع | لا |
| يحتوي على نموذج تواصل يرسل إليك البريد فقط | عادةً خلفية صغيرة، أو خدمة نماذج جاهزة |
| يحفظ بيانات سيراها أشخاص آخرون | نعم |
| يحتوي على تسجيل دخول وبيانات خاصة | نعم |
| يستقبل مدفوعات | نعم، على الأقل لإنشاء صفحات الدفع واستقبال إشعارات الدفع (webhooks) |
| يستخدم API مدفوعاً أو غيره بمفتاح سري | نعم، لإبقاء المفتاح بعيداً عن المتصفح |
أخطاء شائعة وسوء فهم
- وضع المفاتيح السرية في الواجهة الأمامية. ستكون مرئية لأي شخص يفتح أدوات المطور في المتصفح. وهذا أكثر خطأ جدي شيوعاً في التطبيقات المبنية بالذكاء الاصطناعي.
- فرض القواعد في الواجهة الأمامية فقط. إخفاء زر «حذف» عن غير المديرين ليس حماية؛ يجب أن ترفض الخلفية الطلب.
- الاعتقاد بأن الخلفية «مجرد قاعدة بيانات». قاعدة البيانات تخزّن البيانات، أما الخلفية فتقرر من يستطيع قراءتها وتعديلها وكيف.
- الظن أن JavaScript تعني الواجهة الأمامية فقط. تعمل JavaScript وTypeScript على الخوادم أيضاً مع Node.js.
- لوم الجانب الخطأ. إذا بدت الصفحة صحيحة لكن البيانات خاطئة، فالمشكلة غالباً في الخلفية أو قاعدة البيانات، وليست في التصميم.
- البناء الزائد عن الحاجة. لا يحتاج معرض الأعمال إلى خلفية مخصصة. إضافتها تزيد التكلفة والأجزاء المتحركة.
ماذا تطلب من أداة البناء بالذكاء الاصطناعي
- «أي أجزاء هذا التطبيق تعمل في المتصفح وأيها تعمل على الخادم؟»
- «انقل أي مفاتيح API إلى الخلفية واقرأها من متغيرات البيئة.»
- «تحقّق من كل نموذج على الخادم أيضاً، وليس في المتصفح فقط.»
- «اجعل الخلفية تسمح فقط للمديرين بحذف الحجوزات.»
- «الصفحة تبدو سليمة لكن البيانات لا تُحفظ، تحقق من سجلات الخلفية لهذا الطلب.»
- «هذا موقع تسويقي بسيط؛ أبقه واجهة أمامية فقط ما لم نحتج إلى خلفية.»
الواجهة الأمامية والخلفية في Mythex
يبدأ كل مشروع جديد في Mythex من واجهة أمامية مبنية بـ Vite وReact وTypeScript وTailwind، ويضيف الوكيل خلفية عندما يحتاجها تطبيقك، أو يمكنك أن تطلب واجهة API منفصلة بلغة Node أو Python (FastAPI) أو C# أو Java تعمل إلى جانب الواجهة الأمامية في المشروع نفسه. في المعاينة يمكنك التبديل بين الموقع وخادم الـ API، والنشر يرفع الاثنين، مع إضافة قاعدة بيانات وتخزين للملفات عند الحاجة. تشرح الوثائق التطبيقات متعددة الخدمات، ويغطي دليل استضافة المواقع مكان تشغيل كل جزء بعد النشر، وتمثّل قوالب التطبيقات طريقة سريعة لرؤية أمثلة Full stack.
الأسئلة
ما الفرق بين الواجهة الأمامية والخلفية؟
الواجهة الأمامية هي الجزء من التطبيق الذي يعمل في متصفح المستخدم، أي الصفحات والأزرار والنماذج التي يراها ويتفاعل معها. أما الخلفية فتعمل على خادم لا يراه المستخدم أبداً، إذ تخزّن البيانات وتطبّق قواعد العمل وتتحقق من الصلاحيات وتتواصل مع خدمات أخرى.
هل يحتاج كل تطبيق إلى خلفية؟
لا. يمكن أن يكون موقع تسويقي أو معرض أعمال أو صفحة هبوط بسيطة مجرد واجهة أمامية. لكن بمجرد أن يحتاج التطبيق إلى حفظ بيانات مشتركة أو تسجيل دخول للمستخدمين أو معالجة مدفوعات أو استخدام مفاتيح API سرية، فإنه يحتاج إلى خلفية بشكل ما.
هل HTML جزء من الواجهة الأمامية أم الخلفية؟
تعمل HTML وCSS وJavaScript في المتصفح، لذلك فهي جزء من الواجهة الأمامية. ويمكن أن تعمل JavaScript على الخادم أيضاً باستخدام Node.js، وعندها تصبح شيفرة خلفية. اللغة وحدها لا تحدد ذلك، بل مكان تشغيل الشيفرة هو الذي يحدده.
ماذا يعني Full stack؟
يعني Full stack التعامل مع الواجهة الأمامية والخلفية معاً، وعادةً مع قاعدة البيانات أيضاً. التطبيق Full stack هو التطبيق الذي يملك الأجزاء الثلاثة، والمطوّر Full stack يعمل على كل هذه الأجزاء.