ما الذي يوجد فعلاً داخل تطبيق مبنيّ بالذكاء الاصطناعي: جولة لغير المطوّرين

كتبت وصفاً، وضغطت “انطلق”، وبعد عشرين دقيقة كان لديك تطبيق يعمل. عظيم. لكنك الآن نقرت على “عرض الملفات” وأنت تحدّق في شجرة مجلّدات تبدو وكأنها مكتوبة بلغة مختلفة. ما هو package.json؟ لماذا توجد أربعون شيئاً في node_modules؟ ماذا يعني “schema” ولماذا لديك واحد؟

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

سأستخدم ثلاثة أمثلة جارية على امتداد المقال، ليكون للأجزاء المجرّدة ما تتعلّق به على نحو ملموس:

• مايا، قائدة تسويق، بنت لوحة صدارة للإحالات لفريقها.
• جوردان، مدرّب يوغا، بنى موقع حجز للحصص.
• سام، الذي يدير مخبزاً، بنى صفحة “اطلب مسبقاً كرواسان الغد”.

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

الواجهة الأمامية: ما يراه عميلك فعلاً

الواجهة الأمامية هي كل ما يُحمَّل في متصفّح أحدهم. الأزرار، والتخطيطات، والخطوط، والحركات، والطريقة التي يفرّغ بها نموذج نفسه بعد الإرسال. إن كنت تستطيع رؤيته، فهو واجهة أمامية.

بالنسبة لمايا، الواجهة الأمامية لوحة صدارة فيها الرتبة، والاسم، وعدد الإحالات. وبالنسبة لجوردان، تقويم حصص مع زر “احجز”. وبالنسبة لسام، قائمة معجّنات بأزرار زائد وناقص صغيرة بجانب كلٍّ منها.

داخل المشروع، تعيش الواجهة الأمامية عادةً في مجلّد يُسمَّى شيئاً مثل app/، أو pages/، أو src/. سترى ملفّات تنتهي بـ .tsx أو .jsx. كلٌّ منها تقريباً “شاشة واحدة” أو “جزء واحد من شاشة”. صفّ لوحة الصدارة ملفّ واحد. والترويسة ملفّ آخر. والصفحة التي تربط كل شيء معاً ملفّ ثالث.

حين تطلب من أداة الذكاء الاصطناعي “اجعل الأزرار أكثر استدارة” أو “انقل لوحة الصدارة إلى اليمين”، فهذا هو الجزء الذي يتغيّر.

الواجهة الخلفية: الجزء الذي يفكّر

الواجهة الخلفية هي الجزء الذي لا يراه أحد، لكن يعتمد عليه الجميع. إنها الشيفرة التي تعمل في مكان آخر — على خادم، لا في متصفّح العميل — حين يحتاج شيء إلى أن يحدث ولا ينبغي الوثوق بمتصفّح العميل ليقوم به وحده.

لماذا لا يستطيع المتصفّح فعل كل شيء؟ لأن المتصفّح هو جهاز العميل، ولا يمكنك الوثوق به. لو حدّثت لوحة صدارة مايا أعداد الإحالات في المتصفّح فقط، لاستطاع أي شخص أن ينقر بزر الفأرة الأيمن ويضيف 9,000 إحالة لنفسه. لذا فإن الواجهة الخلفية هي حيث تعيش القواعد: “هذا الشخص يستطيع فعل هذا، لكن ليس ذاك”، و”احفظ هذا فعلاً في قاعدة البيانات”، و”أرسِل هذا البريد”.

تعيش الواجهة الخلفية عادةً في مجلّد يُسمَّى api/، أو server/، أو app/api/. والملفّات هناك عادةً قصيرة. كلٌّ منها يعالج طلباً محدّداً: “أنشئ حجزاً”، “اعرض كرواسان اليوم”، “أضف إحالة”.

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

قاعدة البيانات: ذاكرة تطبيقك

تخيّل ذاكرة تطبيقك كصفّ من خزائن الملفّات. على واجهة كل خزانة لافتة. واحدة مكتوب عليها “users”. وأخرى “bookings”. وأخرى “croissant_orders”. وداخل كل خزانة، كل درج صفّ واحد. وكل درج له المجموعة نفسها من الفتحات: اسم، وبريد، وتاريخ إنشاء، وحالة.

تلك البنية — “ما الخزائن الموجودة، وما الفتحات التي يملكها كل صفّ” — تُسمَّى schema. إنها أهمّ ملفّ في المشروع، رغم أنها على الأرجح أكثرها مللاً في المظهر. ابحث عن ملفّ يُسمَّى schema.ts، أو schema.prisma، أو شيئاً داخل مجلّد يُسمَّى db/ أو migrations/. افتحه. سترى قائمة تعكس ما يتذكّره تطبيقك فعلاً عن العالم.

مخطّط (schema) جوردان فيه جدول classes، وجدول bookings، وجدول users. ومخطّط سام فيه products، وorders، وorder_items. ومخطّط مايا فيه members وreferrals. شكل المخطّط هو شكل المنتج، ولهذا فإن تغييره لاحقاً أصعب من تغيير شكل الأزرار.

حيلة مفيدة: إن استطعت وصف ما يتذكّره تطبيقك، بكلمات بسيطة، فعادةً ما تستطيع وصف المخطّط. “أتذكّر اسم كل عميل وبريده. ولكل عميل، أتذكّر الطلبات التي قدّمها. ولكل طلب، أتذكّر أي معجّنات وكم من كلٍّ منها.” تلك الجملة هي، كلمةً كلمةً تقريباً، المخطّط.

المصادقة (Auth): الحارس على الباب

“Auth” كلمتان مدموجتان: authentication (المصادقة: من أنت؟) وauthorization (التفويض: ماذا يُسمَح لك بفعله؟). كلاهما يُعالَج عادةً بمجموعة صغيرة من الملفّات في مجلّد يُسمَّى auth/، أو بخدمة قد تتعرّف على اسمها: Clerk، أو Auth0، أو Supabase Auth، أو NextAuth.

السؤالان مختلفان. المصادقة تجيب: “هل هذه مايا فعلاً؟” — عادةً بكلمة مرور، أو تسجيل دخول عبر Google، أو رابط سحري يُرسَل إليها بالبريد. أما التفويض فيجيب: “هل يُسمَح لمايا بحذف إحالات أشخاص آخرين؟” — والإجابة الصادقة لمعظم التطبيقات المبنيّة بالذكاء الاصطناعي في أسبوعها الأول هي “نسينا أن نتحقّق”.

هذا هو الجزء الأكثر تعرّضاً للتعطّل الصامت. شاشة تسجيل الدخول تعمل، فيبدو الأمر آمناً. لكن الواجهة الخلفية لا تتحقّق دائماً من أن الشخص المسجَّل دخوله هو الشخص نفسه الذي يحاول قراءة بياناته. إن كان لتطبيقك أي مفهوم لـ”بياناتي مقابل بياناتك”، فاطلب من أداة الذكاء الاصطناعي صراحةً: “تأكّد من أن المستخدمين لا يستطيعون رؤية وتعديل سوى بياناتهم الخاصّة.” ستُفاجأ بكم مرّة تكشف فيها تلك الجملة الواحدة عن تحقّق مفقود.

التكاملات: الأشياء التي لم تبنِها لكنك تستخدمها على أي حال

هنا يستهين معظم غير المطوّرين بما يحدث فعلاً. الشيء الذي يرسل بريد “كرواسانك جاهز” لسام ليس شيفرة — بل حساب لدى SendGrid أو Resend. والشيء الذي يعالج دفعة حصّة جوردان ليس شيفرة — بل Stripe. والشيء الذي يستضيف الصور على لوحة صدارة مايا ليس شيفرة — بل خدمة تخزين مثل S3 أو Cloudinary.

يظهر كل تكامل في مكانين. هناك قطعة صغيرة من الشيفرة في الواجهة الخلفية تقول “مرحباً Stripe، اخصم من هذه البطاقة”. وهناك مفتاح — سلسلة سرّية طويلة — مخزّن في مكان آمن (عادةً ملفّ يُسمَّى .env ينبغي ألّا يرفعه أحد إلى المستودع أبداً) يثبت لـ Stripe أن الطلب جاء من مخبز سام لا من شخص غريب.

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

النشر: كيف يصل إلى الإنترنت

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

• المُضيف: خدمة مثل Vercel، أو Netlify، أو Fly، أو Render، تشغّل واجهتك الخلفية وتقدّم واجهتك الأمامية.
• النطاق: اسم مثل mayas-leaderboard.com يشير إلى مُضيفك.
• البناء (build): الوصفة التي تأخذ ملفّاتك المصدرية الفوضوية وتحوّلها إلى النسخة الأنحف والأسرع التي تعمل فعلاً.

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

عادة الخمس دقائق التي تكافئ نفسها

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

تفعل مايا هذا كل بعد ظهر جمعة. تكتب: “ما الذي تغيّر في المخطّط هذا الأسبوع، ولماذا؟” و: “هل توجد أي تكاملات جديدة في هذا التطبيق لم أطلبها؟” الإجابات تكون مطمئنة دائماً تقريباً. أما المرّات القليلة التي لا تكون فيها كذلك، فتلتقط فيها المشكلات وهي ما زالت صغيرة.

تلك هي الغاية كلها من فهم الأجزاء. لا أن تصبح مطوّراً، بل فقط أن تكون قادراً على طرح أسئلة أفضل.

إلى أين تذهب بعد ذلك

إن ساعدتك هذه الجولة، فهناك متابعتان تستحقّان وقتك. خلل “يبدو على ما يرام” يغطّي ما تفعله حين يتعطّل أحد هذه الأجزاء بصمت، وجاهز للعرض مقابل جاهز للإنتاج يغطّي كيف تعرف متى انتقل تطبيقك من المرحلة الأولى إلى الثانية. الخريطة نفسها، باستخدامات مختلفة لها.