الآن بعد أن
أكملنا تنفيذ خادم REST API باستخدام Express و MongoDB في هذه الدورة،
فإن التفكير الفوري التالي الذي قد يحدث في عقلك هو،
نظرًا لأننا قمنا بالفعل بتطوير تطبيقات العميل،
سواء كان تطبيق Angular أو التطبيق الأيوني
أو تطبيق Native Script في الدورات السابقة،
كيف نقوم بدمج الاثنين معًا بحيث يكون تطبيق العميل الخاص بنا قادرًا على
التفاعل مع خادم REST API الكامل الذي قمنا بتطويره في هذه الدورة؟
لذلك، هذا ما سندرسه في هذا الدرس،
في هذه المحاضرة، والممرين اللذين يتابعان هذه المحاضرة.
لذلك، في نهاية هذا الدرس،
سيكون لديك عميل Angular سنكون
قادرين على التواصل مع الخادم الذي قمت بتطويره للتو في
هذه الدورة، وتكون قادرة
على دعم عرض جانب العميل الكامل للتطبيق بأكمله.
لذا، بهذه الطريقة، سنرى أننا قمنا بتطوير
التطبيق الكامل للنهاية من جانب العميل على طول الطريق إلى جانب الخادم.
يمكن أيضًا استخدام نهج مماثل مع
عميل الأيوني الخاص بك أو مع عميل البرنامج النصي الأصلي،
نظرًا لحقيقة أنه تم
تطوير كل من البرنامج النصي الأيوني والأصلي مع محرك Angular خلف الكواليس.
لذا، يجب أن يكون تنفيذ مجموعة مماثلة من الخطوات قادرًا على جعل العميل الأيوني الخاص بك وكذلك
عميل البرنامج النصي الأصلي الخاص بك يتواصل مع
خادم واجهة برمجة التطبيقات Express بالإضافة إلى MongoDB rest API الذي قمنا بتطويره في هذه الدورة.
لدمج العميل والخادم،
كما أدركنا،
يتم تنفيذ خادمنا بالفعل لدعم واجهة برمجة تطبيقات REST كاملة.
من جانب العميل،
سواء كان العميل الزاوي أو العميل
الأيوني أو عميل البرنامج النصي الأصلي،
فإنها تتفاعل جميعها مع الخادم باستخدام نقاط النهاية REST API.
لذلك، عندما يرسل العميل الطلب إلى الخادم عند نقطة نهاية REST API،
سيستجيب الخادم مع بيانات JSON المقابلة مرة أخرى إلى العميل،
ويمكن للعميل بعد ذلك الاستفادة من بيانات JSON لتقديم طرق العرض للمستخدم.
لذلك، بالنظر إلى هذا الفهم للتواصل بين العميل والخادم،
يجب أن يكون التكامل واضحًا إلى حد ما.
ولكن، الآن بالطبع،
عندما قمنا بتطوير عميل Angular أو الأيونية أو NativeScript،
لم نفعل جزء مصادقة المستخدم الكامل،
لأننا لم يكن لدينا ذلك في خادم JSON الخاص بنا.
الآن بعد أن حصلنا على مصادقة المستخدم المضمنة في جانب الخادم الخاص بنا،
نحتاج إلى تحديث تطبيقات العميل الخاصة بنا
لتمكينها من القيام بمصادقة المستخدم على جانب الخادم،
عن طريق نشر معلومات تسجيل الدخول إلى الخادم ومن ثم
الحصول على رمز المصادقة من جانب الخادم،
وبعد ذلك، التواصل مع الخادم بما
في ذلك رمز المصادقة في رأس رسائل الطلب.
لذلك، كل هذا يعني أننا بحاجة إلى
إجراء تعديلات طفيفة على كل من العميل والخادم،
بحيث يمكن للاثنين التواصل مع بعضها البعض.
أحد الجوانب التي لم أتعامل معها في التمرين سابقًا،
هو كيفية تعامل الخادم مع معلمات الاستعلام التي تأتي من جانب العميل.
لذلك، كما أدركنا،
عندما يرسل جانب العميل طلبًا للحصول
على طبق مميز أو قائد مميز أو ترويج ميزة،
رأينا أن عنوان URL يتضمن أطباق،
ميزة علامة الاستفهام تساوي الصواب في
عنوان URL للطلب الذي يأتي من جانب العميل.
الآن، في البيانات على جانب الخادم،
رأينا بالفعل أن الطبق،
أو الترويج أو القائد،
يتضمن علامة الميزة بالفعل في بيانات JSON.
لذلك، عندما يأتي هذا الطلب إلى جانب الخادم،
فيجب أن يكون الخادم قادرًا على استخراج معلمة الاستعلام هذه من الطلب الوارد،
ثم قم بإجراء استعلام
MongoDB بشكل مناسب ثم الحصول على النتائج فقط حيث يتم تعيين هذه العلامة المميزة إلى true.
لذلك، للقيام بذلك كما رأينا،
عنوان URL الذي يتم استخدامه لإرسال الطلب إلى الخادم هو/الأطباق؟ ميزة = صحيح.
لذا، هذه هي الطريقة التي سنقوم بتزويد معلمات الاستعلام إلى جانب الخادم الخاص بنا.
الآن، بالإضافة إلى ذلك، عندما يتم تلقي هذه المعلومات على جانب الخادم،
الآن، رأينا أنه في وقت سابق عندما فعلنا طلب الحصول على على جانب الخادم،
قلنا ببساطة أطباق تجد وبعد ذلك سوف نجد جميع الأطباق ومن ثم إعادتها
عندما يتم إرسال طلب الحصول إلى DishRouterRoute/.
وينطبق نفس المنطق على كل من جهاز التوجيه الترويجي وكذلك على جهاز التوجيه الزعيم.
الآن، عندما تقوم بتضمين معلمة استعلام مثل ذلك في عنوان URL،
كيف سيتمكن جانب الخادم من استخراج معلمة الاستعلام هذه؟
لذلك، هذا هو المكان الذي يحتوي فيه الطلب الوارد
على معلمة الاستعلام هذه المرفقة بعنوان URL الوارد،
سيقوم الخادم السريع بمعالجة ذلك تلقائيًا وتحويله إلى
كائن JSON يتم تحميله على رسالة طلب قادمة على جانب الخادم.
الآن، هذا متاح على جانب الخادم في شكل req.query.
لذلك، مهما كانت معلمات الاستعلام التي تضمينها في عنوان URL،
سيتم تحويلها إلى كائنات JSON المقابلة مع مجموعة المعلومات كما هو موضح هنا،
ثم تحميلها على كائن الطلب على جانب الخادم.
لذلك، باستخدام req.query على جانب الخادم،
سنكون قادرين على الحصول على معلمات الاستعلام هذه.
لذلك، عند إجراء طلب الحصول على جانب الخادم،
وتقول dishes.find ثم تقوم بتضمين req.query في البحث هناك.
لذلك، عندما يتم الاستعلام عن MongoDB، عندئذ،
فقط تلك السجلات أو فقط تلك الوثائق التي تم تعيين المميز لها إلى true سيتم
استخراجها من MongoDB وتوفيرها مرة أخرى لنا داخل طريقة الحصول هنا،
وبعد ذلك، يمكن إرجاعها إلى جانب العميل.
لذا، هذا بسيط مثل ذلك في التعامل مع معلمات الاستعلام على جانب الخادم الخاص بنا.
لذلك، هذا التحديث سوف نفعل لكل من جهاز التوجيه طبق، جهاز
التوجيه الترويجي، وجهاز التوجيه زعيم على جانب الخادم لدينا.
الجزء التالي هو بالطبع، مصادقة المستخدم.
لذلك، كما أدركنا على جانب الخادم،
لدينا بالفعل نقاط النهاية REST API هذه،
والتي هي مفيدة لمصادقة المستخدم. على
وجه الخصوص، عند إجراء مشاركة إلى/المستخدمين/تسجيل الدخول،
مع اسم المستخدم وكلمة المرور، ثم،
سوف تكون قادرة على مصادقة المستخدم على جانب الخادم.
الآن، عندما تتم مصادقة المستخدم على جانب الخادم بنجاح،
فإن رسالة الرد القادمة من جانب الخادم ستتضمن
رمز ويب JSON في نص الرد الخاص برسالة الرد الواردة من جانب الخادم.
لذلك، على جانب العميل،
يجب أن نكون قادرين على استخراج هذا الرمز المميز ثم استخدام هذا الرمز المميز في وقت لاحق.
لذلك، عندما يتلقى العميل رسالة الرد من
جانب الخادم ويتم مصادقة المستخدم بنجاح على جانب الخادم،
ستحتوي رسالة الرد على رمز ويب JSON،
والذي يجب استخراجه، وبعد ذلك،
يجب على العميل تضمين رمز ويب JSON هذا
في لكل طلب صادر من جانب العميل.
إذاً، كيف نتعامل مع هذه المجموعة الكاملة من العمليات؟
الآن، هذا هو المكان
الذي سنقوم بتنفيذ خدمة أخرى سيتم استخدامها على جانب العميل،
في عميل Angular الخاص بنا،
يسمى خدمة المصادقة،
وهذا هو المكان الذي سنتعامل مع تسجيل الدخول بالكامل وعمليات الخروج.
الآن، عملية الخروج واضحة إلى حد ما، ولكن
إذا قمنا بتدمير رمز ويب JSON الذي لدينا على جانب
العميل، فلن يتمكن العميل من الوصول إلى الخادم.
لذا، فهي بسيطة مثل مجرد تدمير
رمز ويب JSON على جانب العميل لتسجيل الخروج من هذا العميل.
لذلك، وبالنظر إلى هذا الفهم،
دعونا نرى الخطوات التي تشارك في
القيام مصادقة المستخدم والتعامل مع مصادقة المستخدم على جانب العميل.
لذلك، للتعامل مع مصادقة المستخدم على جانب العميل،
سيقوم العميل بإرسال طلب نشر إلى نقطة النهاية /المستخدمين/تسجيل الدخول،
وسوف يحتوي نص طلب المشاركة على اسم المستخدم وكلمة المرور.
نحن نستخدم مصادقة تسجيل الدخول في هذه الحالة.
الآن، لمصادقة Facebook مرة أخرى
، هذا إعداد مختلف لن أناقشه الآن.
ولكن،
سيحتوي نص الطلب كما سترى للمصادقة المحلية على اسم المستخدم وكلمة المرور.
لذلك، عندما تتم مصادقة المستخدم بنجاح على جانب الخادم،
سيقوم الخادم بالرد مرة أخرى
على العميل من خلال تضمين رمز ويب JSON في رسالة الرد.
لذلك، عندما يتلقى العميل رسالة الرد من جانب الخادم،
فسيتعين على العميل التقاط رمز ويب JSON هذا،
ثم حفظ رمز ويب JSON في التخزين المحلي على جانب العميل.
بعد ذلك، يجب على العميل تضمين هذا الرمز المميز في كل طلب صادر.
إذن، كيف يتم إنجاز ذلك على جانب العميل؟
أولاً وقبل كل شيء، بالطبع،
تحتاج إلى حفظ رمز ويب JSON الوارد في التخزين المحلي،
ويتم ذلك في خدمة المصادقة التي سنقوم بتنفيذها على جانب العميل.
الآن، لكل طلب صادر،
سيقوم العميل بتضمين هذا الرمز المميز في
الرأس، رأس التفويض للطلب الصادر.
الآن، كيف يتم إنجاز هذا؟
لذا، هذا هو المكان الذي سنأخذ فيه مساعدة اعتراض HTTP،
الذي يدعمه HttpClient في Angular.
لذا، مع اعتراض HTTP،
يسمح لنا المعترض باعتراض
كل رسالة طلب صادرة أو حتى
اعتراض كل رسالة رد واردة إذا اخترت ذلك.
ولكن في تطبيق Angular،
سنقوم بتنفيذ اعتراض الطلب،
والذي سأوضح في التمرين لاحقًا.
في اعتراض طلب HTTP،
عند اعتراض رسالة الطلب، سيتم اعتراض
كل رسالة طلب صادرة ومن ثم
سيتم إدراج رمز ويب JSON في رأس التفويض الخاص برسالة الطلب.
ثم بعد ذلك، سيتم تمرير رسالة الطلب إلى جانب الخادم.
لذلك، وبالتالي، فإن كل طلب صادر بعد مصادقة المستخدم على جانب الخادم،
فإن كل طلب صادر من جانب العميل يحمل
رمز ويب JSON في رأس التفويض للطلب الصادر.
الآن، بمجرد تسجيل خروج العميل،
سيتم تدمير رمز ويب JSON على جانب العميل.
لذلك، بعد ذلك، لن تحتوي الطلبات الصادرة على رمز ويب JSON بعد الآن،
لأن رمز ويب JSON غير موجود على جانب العميل.
لذلك، وبالتالي، يفقد المستخدم المصادقة.
لذا، هذه هي الطريقة التي سنتعامل بها مع عملية تسجيل الدخول والخروج على جانب العميل،
من خلال التواصل مع الخادم،
ثم الحصول على رمز ويب JSON،
ثم تضمين رمز ويب JSON في كل طلب صادر.
الآن، مع هذا الفهم لكيفية تفاعل العميل والخادم،
دعونا ننتقل الآن إلى التدريبين التاليين.
أولا، سنقوم بتحديث جانب الخادم مع عدد قليل من الإضافات،
بحيث يمكن أن تتكامل بشكل جيد مع موقع عملائنا.
بعد ذلك، سنقوم بتحديث جانب العميل أو بالأحرى سأعطيك
تطبيق عميل كامل
أخذته من دورة Angular السابقة ثم سأقوم
بتحديثه، والذي يوفر لنا أيضًا القدرة على استخدام اعتراضات HTTP
على كل من الطلبات الصادرة و رسائل الرد الواردة.
لذلك، سوف نتعامل مع كل من هذين في التدريبين المقبلين،
وفي نهاية ذلك، سوف تفهم كيفية
دمج العميل الخاص بك وجانب الخادم.