ما هو تطبيق Full-Stack؟ شرح بلغة بسيطة
تطبيق Full-Stack هو تطبيق يضم كل الطبقات التي يحتاجها ليعمل: الواجهة الأمامية (frontend) التي يراها الناس ويضغطون عليها، والخلفية (backend) التي تعمل على خادم وتطبّق القواعد، وقاعدة البيانات التي تتذكر كل شيء. قائمة مهام تحفظ مهامك، وتسمح لك بتسجيل الدخول من أي جهاز، ولا تعرض قائمتك لأحد غيرك، هي تطبيق Full-Stack. أما صفحة واحدة تعرض ساعات عمل المحل فقط، فليست كذلك.
"Stack" تعني ببساطة طبقات التقنية المكدّسة فوق بعضها. و"Full" تعني أن كل هذه الطبقات موجودة.
لماذا يهم ذلك عند البناء بالذكاء الاصطناعي
عندما تصف تطبيقاً لأداة بناء بالذكاء الاصطناعي، فإن الكلمات التي تستخدمها تحدد الطبقات التي ستُبنى. «اصنع صفحة تعرض قائمة طعامنا» تنتج واجهة أمامية. أما «دع الزبائن يطلبون من قائمتنا، ودع المطبخ يرى الطلبات الجديدة» فتحتاج إلى الطبقات الثلاث، لأن الطلبات يجب أن تُحفظ، ويجب أن تُشارَك بين نوعين من المستخدمين، وأن تبقى خاصة.
معرفة الفرق تساعدك بثلاث طرق:
- تطلب الشيء الصحيح. إذا أردت حفظ البيانات، فقل ذلك صراحةً. أداة لا تبني إلا الواجهة الأمامية ستبدو منتهية، لكنها ستنسى كل شيء عند التحديث.
- تكشف الاكتمال الزائف. العرض التجريبي ببيانات نموذجية قد يبدو مطابقاً لتطبيق يعمل فعلاً. ومعرفة الطبقات تمكّنك من التحقق من أن البيانات تُحفظ فعلاً في مكان ما.
- تفهم تكاليف التشغيل. الواجهة الأمامية وحدها يمكن تقديمها كملفات ثابتة. أما الخلفية وقاعدة البيانات فهما برامج تعمل على خوادم، ومن هناك تأتي معظم تكلفة الاستضافة.
تشبيه من الحياة اليومية: مطعم
فكّر في مطعم.
- صالة الطعام هي الواجهة الأمامية. القوائم والطاولات ودفتر النادل. هي ما يراه الضيوف، وينبغي أن تكون ممتعة وسهلة الاستخدام.
- المطبخ هو الخلفية. الضيوف لا يدخلونه. يستقبل الطلبات، ويتحقق من توفر الطبق، ويطبخه، ويرفض الطلبات الغريبة. والقواعد تعيش هنا.
- المخزن وسجل الطلبات هما قاعدة البيانات. فيهما ما هو موجود وما طُلب، فلا يُنسى شيء عند تغيير الوردية.
مطعم فيه صالة طعام فقط يستطيع أن يعرض لك قائمة جميلة، لكنك لن تأكل. هذا هو تطبيق الواجهة الأمامية وحدها الذي يدّعي أنه Full-Stack.
الطبقات الثلاث بالتفصيل
| الطبقة | أين تعمل | مهمتها | التقنيات المعتادة |
|---|---|---|---|
| الواجهة الأمامية | في متصفح الزائر | عرض الشاشات، واستقبال المدخلات، وأن تبدو سريعة | HTML وCSS وJavaScript، وغالباً React |
| الخلفية | على خادم تتحكم فيه | فحص الصلاحيات، وتطبيق قواعد العمل، واستدعاء خدمات أخرى بمفاتيح سرية | Node.js وPython وC# وJava وغيرها |
| قاعدة البيانات | على خادم، بجوار الخلفية | تخزين البيانات والبحث فيها بموثوقية | Postgres وMySQL وSQLite |
تتحدث الطبقات مع بعضها بترتيب ثابت. الواجهة الأمامية تطلب شيئاً من الخلفية عبر واجهة API، أي مجموعة محددة من الطلبات تقبلها الخلفية. تفحص الخلفية الطلب، وتقرأ قاعدة البيانات أو تكتب فيها، ثم ترد بجواب. ولا تتحدث الواجهة الأمامية مع قاعدة البيانات مباشرة أبداً.
هذا الترتيب هو أهم فكرة أمنية في المكدس كله. فأي شيء في الواجهة الأمامية يستطيع الزائر قراءته وتعديله، لأنه يعمل على جهازه. لذلك يجب فرض القواعد، مثل «لا يرى هذه الفاتورة إلا مالكها» أو «يمكن استخدام القسيمة مرة واحدة»، في الخلفية. لمزيد من التفاصيل عن الفصل بين الطرفين، انظر الواجهة الأمامية مقابل الخلفية.
مثال عملي: تطبيق حجز حصص يوغا
لنفترض أنك تدير استوديو يوغا وتريد أن يحجز الناس الحصص عبر الإنترنت.
ما يفعله الزائر: يفتح الموقع، ويرى جدول حصص هذا الأسبوع، ينقر على إحداها، يسجّل الدخول، ويحجز مكاناً.
ما يحدث في الخلفية:
- الواجهة الأمامية تعرض الجدول. ولملئه تسأل الخلفية: «ما الحصص المتاحة هذا الأسبوع، وكم مكاناً بقي فيها؟»
- الخلفية تسأل قاعدة البيانات عن الحصص وتحسب الحجوزات لكل حصة، ثم ترد.
- يضغط الزائر احجز. ترسل الواجهة الأمامية: «احجز الحصة رقم 42 لهذا الشخص المسجّل دخوله».
- تتحقق الخلفية: هل هذا الشخص مسجّل فعلاً؟ هل الحصة ممتلئة؟ هل حجزها من قبل؟ فقط إذا كانت الأمور سليمة تكتب صفاً جديداً للحجز في قاعدة البيانات.
- ترد الخلفية بـ«تم الحجز»، فتعرض الواجهة الأمامية رسالة التأكيد.
- لاحقاً تسجّل مالكة الاستوديو الدخول وترى قائمة الحصص. تتحقق الخلفية من أنها مشرفة قبل أن تعرض أسماء الجميع.
الآن تخيّل أن هذا بُني كواجهة أمامية فقط. قد يظهر الجدول، وقد يعرض زر الحجز علامة صح جميلة، لكن الحجز سيختفي عند التحديث، وعدد «الأماكن المتبقية» سيكون خاطئاً لبقية الناس، ولن ترى المالكة الحجز أبداً. الخطوة الرابعة، أي الفحوصات، ستكون غائبة تماماً. هذا هو الفرق العملي.
مصطلحات أساسية
- الواجهة الأمامية (جانب العميل): الجزء الذي يعمل في المتصفح.
- الخلفية (جانب الخادم): الجزء الذي يعمل على خادم. ويُسمى أيضاً خادم الـ API.
- قاعدة البيانات: المكان الذي تُخزَّن فيه البيانات بشكل منظم. انظر ما هي قاعدة البيانات.
- API: قائمة الطلبات التي تقبلها الخلفية من الواجهة الأمامية أو من برامج أخرى.
- المصادقة (Authentication): التحقق من هوية الشخص عند تسجيل الدخول. التفويض (Authorisation): التحقق من الأشياء المسموح له بفعلها.
- النشر (Deployment): وضع كل الطبقات على خوادم حتى يستطيع الجمهور استخدامها.
- Monolith مقابل الخدمات: برنامج واحد يفعل كل شيء، مقابل عدة برامج أصغر (مثل موقع وواجهة API منفصلة). وكلاهما Full-Stack.
أخطاء شائعة وتصورات خاطئة
- "يبدو منتهياً، إذن هو منتهٍ." البيانات النموذجية والزر الذي يبدو عاملاً ليسا كالبيانات المحفوظة فعلاً. حدّث الصفحة، وافتحها في نافذة خاصة، وتأكد من أن البيانات ما زالت موجودة.
- وضع القواعد في الواجهة الأمامية. إخفاء الزر ليس أماناً. إذا لم تتحقق الخلفية، يستطيع أي شخص يعرف الطلب أن يرسله.
- وضع المفاتيح السرية في الواجهة الأمامية. مفتاح مزود الدفع أو الذكاء الاصطناعي في كود المتصفح يمكن لكل زائر قراءته. المفاتيح تنتمي إلى الخلفية، في متغيرات البيئة. انظر متغيرات البيئة والأسرار.
- الظن بأن Full-Stack يعني التعقيد. تطبيق Full-Stack صغير قد يكون بضع شاشات وعدداً قليلاً من مسارات الخلفية وثلاثة جداول في قاعدة البيانات. إنه وصف للطبقات، لا لحجم التطبيق.
- الظن بأنك يجب أن تختار كل تقنية بنفسك. أي مكدس منطقي ومستخدم على نطاق واسع يكفي لنسخة أولى. الأهم هو وصف واضح للبيانات والقواعد.
ماذا تطلب من أداة البناء بالذكاء الاصطناعي
صف التطبيق بدلالة الطبقات الثلاث، حتى لو لم تذكر أسماءها:
- البيانات: «احفظ الحصص (الاسم، الوقت، السعة) والحجوزات (الحصة، الشخص، وقت الحجز) في قاعدة بيانات.»
- القواعد: «لا يمكن حجز حصة بعد اكتمال سعتها. ولا يحجز الشخص الحصة الواحدة إلا مرة واحدة. ولا يرى من حجز إلا المشرفون.»
- الشاشات: «جدول أسبوعي للحصص، وتأكيد الحجز، وصفحة إدارة تعرض الحجوزات لكل حصة.»
- الفحوصات: «طبّق هذه القواعد على الخادم، لا في الصفحة وحدها. واحتفظ بمفاتيح API على الخادم.»
ثم اختبر كأنك متشكك: حدّث الصفحة، وسجّل الدخول بشخصين مختلفين، وحاول رؤية بيانات لا يحق لك رؤيتها. يشرح دليل بناء تطبيق بالذكاء الاصطناعي هذه الحلقة من البداية إلى النهاية.
تطبيقات Full-Stack في Mythex
تبني Mythex تطبيقات ويب Full-Stack من وصف في المحادثة. افتراضياً يحصل التطبيق الجديد على واجهة أمامية بـ React وTypeScript، وعندما يحتاج التطبيق إلى حفظ البيانات، تضيف Mythex قاعدة بيانات Postgres مخصصة إلى المشروع، ويمكنك أن تطلب خادم API منفصلاً (مثل Python أو Node أو C# أو Java) إلى جانب الموقع. كل شيء يعمل معاً في معاينة حية، ويُنشر على عنوان عام. توضح صفحة الوثائق عن التطبيقات متعددة الخدمات كيف يُعاينان وينشران معاً، وتضم صفحة منشئ تطبيقات Full-Stack نقاط بداية.
الأسئلة
ماذا يعني Full-Stack؟
Full-Stack يعني أن التطبيق يضم كل الطبقات التي يحتاجها ليعمل بمفرده: الواجهة الأمامية التي يراها الناس ويضغطون عليها، والخلفية (backend) التي تعمل على خادم وتطبّق القواعد، وقاعدة البيانات التي تحفظ البيانات. والمطوّر Full-Stack شخص يستطيع العمل على كل هذه الطبقات.
هل الموقع تطبيق Full-Stack؟
ليس دائماً. الموقع التعريفي بصفحات ثابتة هو واجهة أمامية فقط. ويصبح Full-Stack عندما يحتاج إلى خادم وقاعدة بيانات، مثلاً ليسمح للناس بالتسجيل أو حفظ الطلبات أو رؤية بياناتهم الخاصة.
هل أحتاج إلى تطبيق Full-Stack أم واجهة أمامية فقط؟
إذا كان تطبيقك يجب أن يتذكّر أي شيء بين الزيارات، أو يحافظ على خصوصية البيانات لكل مستخدم، أو يستقبل مدفوعات، أو يتواصل مع خدمات أخرى بمفاتيح سرية، فأنت بحاجة إلى خلفية وقاعدة بيانات، أي إلى Full-Stack. أما إذا كان يعرض معلومات فقط، فتكفي الواجهة الأمامية.
هل يستطيع الذكاء الاصطناعي بناء تطبيق Full-Stack؟
نعم. تستطيع أدوات بناء التطبيقات بالذكاء الاصطناعي كتابة الواجهة الأمامية والخلفية وجداول قاعدة البيانات من وصف بلغة عادية، وتشغيلها معاً في معاينة حية. ومع ذلك، ما زال عليك وصف البيانات ومن يحق له رؤية ماذا، واختبار النتيجة.