اختبار المستوى 3 — Node.js

الاختبار — أسئلة جديدة

12 سؤالا لتأكيد إكسبريس وقواعد البيانات : التوجيه والوسائط والقوالب والثابت ومونغو/مونغوز و SQL وبريزما.
أجب عن جميع الأسئلة ثم اضغط تصحيح: ستظهر نتيجتك والتوضيحات.

3.1 · تذكر

1. في إكسبريس، يُعرَف الوسيط بـ…

إعادة تشغيله الخادم توقيعه (req, res, next) في الخط لونه في الطرفية طباعته على ورق

يتصرف أثناء المعالجة ثم ينادي next() أو يرد.

3.1 · تطبيق

2. يريد ساليم بطاقة المنتج 7 عبر /produits/7. يكتب…

‏app.imprimer('/produits', ...);‏ ‏app.eteindre('/produits', ...);‏ ‏app.get('/produits/:id', (req, res) => res.json({ id: req.params.id }));‏ ‏app.couleur('/produits', ...);‏

طريق ديناميكية : يُلتَقط المقطع في req.params.id.

3.1 · تحكيم

3. طلب ساليم بقي عالقا دون رد. التحكيم الصحيح ؟

تغيير ألوان الطرفية التحقق من مناداة كل وسيط next() أو رده، وترتيب الحلل-قبل-التحقق إعادة طباعة كل شيء للقراءة حذف إكسبريس والعودة للورق

‏next()‏ المنسية تعلق الخط ؛ والتحقق قبل التحليل يقرأ فراغا.

3.2 · تذكر

4. ‏express.static('public')‏ و res.render() يخدمان على التوالي لـ…

حذف القاعدة ثم إعادة إنشائها إطفاء نود ثم إعادة تشغيلها طباعة الخادم ثم تلوينه خدمة الملفات الثابتة، ثم تصيير عرض HTML ببيانات

الثابت للأصول الثابتة، والقوالب لـ HTML الديناميكي (SSR).

3.2 · تطبيق

5. يصير ساليم بطاقة المنتج EJS. يكتب…

‏res.render('produit', { produit });‏ ‏res.imprimer('produit');‏ ‏app.effacer('produit');‏ ‏res.couleur('produit');‏

يستقبل عرض views/ البيانات وينتج HTML.

3.2 · تطبيق

6. بطاقات واجهات يجب فهرستها + لوحة متابعة شديدة التفاعل. يحكم ساليم…

‏SPA‏ في كل مكان حتى لثلاث صفحات ثابتة الورق للبطاقات والكلام الشفهي للباقي ‏SSR‏ (‏EJS‏) للبطاقات SEO، و API JSON + واجهة للوحة المتابعة لا عرض، وكل شيء في الذاكرة

المحتوى/SEO ← ‏SSR‏ ؛ والتطبيق التفاعلي ← ‏API‏ + واجهة منفصلة.

3.3 · تذكر

7. مونغو دي.بي أمام SQL، هو أولا…

مطبوعات ملونة في مجموعات مستندات JSON/BSON في مجموعات، دون مخطط صارم كابلات شبكة في مجموعات لا فرق في النموذج

مستندات مرنة قريبة من JS، مقابل جداول وأسطر صارمة.

3.3 · تطبيق

8. يفرض ساليم بريدا مطلوبا ووحيدا على مستعمليه. يكتب…

‏email‏ : قبول كل شيء دون قاعدة ‏email‏ : محذوف عند كل save ‏email: { type: String, required: true, unique: true }‏ في المخطط ‏email‏ : « مطلوب تقريبا » في تعليق

يتحقق مخطط مونغوز قبل التسجيل.

3.3 · تحكيم

9. يتردد ساليم بين مونغو دي.بي وبوستغريسكيول للفوترة المرتبطة. التحكيم الصحيح ؟

لا هذا ولا ذاك، وكل شيء في الذاكرة مونغو دي.بي دائما ولكل شيء ‏SQL‏ دائما ولكل شيء بيانات مرنة ومتطورة ← مونغو دي.بي ؛ وبيانات مرتبطة بسلامة حرجة ← ‏SQL‏

نختار حسب طبيعة البيانات، لا حسب الموضة.

3.4 · تطبيق

10. يسرد ساليم الزبناء النشطين مع بريزما. يكتب…

‏await prisma.client.findMany({ where: { actif: true } });‏ ‏await prisma.imprimer({ tout: true });‏ ‏await prisma.effacer({ tout: true });‏ ‏await prisma.colorier({ tout: true });‏

طريقة ORM مُنمَّطة تولد SQL مُعامَلا آمنا.

3.4 · تطبيق

11. في SQL الخام (pg)، يرشح ساليم ببريد مُدخَل. النسخة الآمنة ؟

‏await pool.query('SELECT * FROM clients WHERE email = ' + emailSaisi);‏ ‏await pool.imprimer(emailSaisi);‏ ‏await pool.effacer(emailSaisi);‏ ‏await pool.query('SELECT * FROM clients WHERE email = $1', [emailSaisi]);‏

الموضع $1 يفصل الكود عن البيانات : لا حقن.

3.4 · تحكيم

12. يقترح زميل دمج المدخل « للاختبار فقط ». التحكيم الصحيح ؟

الرفض : التعامل أو ORM دائما، حتى في الاختبار الدمج ثم الطباعة للتحقق تدوين كلمة السر الحقيقية في الكود للسرعة القبول، فالاختبار لا يُهاجَم أبدا

يولد الحقن من دمج ؛ والمنعكس الآمن لا يقبل استثناء.

وماذا بعد؟

نقطة ≥ 80 % : مروا إلى المستوى 4 — ‏API REST‏ كاملة ومصادقة JWT وتحقق (البناء على أسس سليمة).
نقطة 50-79 % : راجعوا الأقسام الراسبة (الخط في 3.1 و SSR مقابل API في 3.2 والمخطط في 3.3 والتعامل في 3.4) ثم أعيدوا الاختبار.
نقطة < 50 % : أعيدوا قراءة المستوى 2 (‏http‏ الأصلي و async/await) ثم أعيدوا كل تحدي 48 ساعة بالترتيب.