1
00:00:00,000 --> 00:00:05,340
الآن بعد أن

2
00:00:05,340 --> 00:00:11,610
أكملنا تنفيذ خادم REST API باستخدام Express و MongoDB في هذه الدورة،

3
00:00:11,610 --> 00:00:14,990
فإن التفكير الفوري التالي الذي قد يحدث في عقلك هو،

4
00:00:14,990 --> 00:00:18,555
نظرًا لأننا قمنا بالفعل بتطوير تطبيقات العميل،

5
00:00:18,555 --> 00:00:21,460
سواء كان تطبيق Angular أو التطبيق الأيوني

6
00:00:21,460 --> 00:00:25,380
أو تطبيق Native Script في الدورات السابقة،

7
00:00:25,380 --> 00:00:29,820
كيف نقوم بدمج الاثنين معًا بحيث يكون تطبيق العميل الخاص بنا قادرًا على

8
00:00:29,820 --> 00:00:35,780
التفاعل مع خادم REST API الكامل الذي قمنا بتطويره في هذه الدورة؟

9
00:00:35,780 --> 00:00:39,605
لذلك، هذا ما سندرسه في هذا الدرس،

10
00:00:39,605 --> 00:00:44,715
في هذه المحاضرة، والممرين اللذين يتابعان هذه المحاضرة.

11
00:00:44,715 --> 00:00:46,655
لذلك، في نهاية هذا الدرس،

12
00:00:46,655 --> 00:00:49,295
سيكون لديك عميل Angular سنكون

13
00:00:49,295 --> 00:00:52,220
قادرين على التواصل مع الخادم الذي قمت بتطويره للتو في

14
00:00:52,220 --> 00:00:55,265
هذه الدورة، وتكون قادرة

15
00:00:55,265 --> 00:01:01,410
على دعم عرض جانب العميل الكامل للتطبيق بأكمله.

16
00:01:01,410 --> 00:01:03,860
لذا، بهذه الطريقة، سنرى أننا قمنا بتطوير

17
00:01:03,860 --> 00:01:11,150
التطبيق الكامل للنهاية من جانب العميل على طول الطريق إلى جانب الخادم.

18
00:01:11,150 --> 00:01:13,895
يمكن أيضًا استخدام نهج مماثل مع

19
00:01:13,895 --> 00:01:17,290
عميل الأيوني الخاص بك أو مع عميل البرنامج النصي الأصلي،

20
00:01:17,290 --> 00:01:20,430
نظرًا لحقيقة أنه تم

21
00:01:20,430 --> 00:01:24,420
تطوير كل من البرنامج النصي الأيوني والأصلي مع محرك Angular خلف الكواليس.

22
00:01:24,420 --> 00:01:31,100
لذا، يجب أن يكون تنفيذ مجموعة مماثلة من الخطوات قادرًا على جعل العميل الأيوني الخاص بك وكذلك

23
00:01:31,100 --> 00:01:35,240
عميل البرنامج النصي الأصلي الخاص بك يتواصل مع

24
00:01:35,240 --> 00:01:40,295
خادم واجهة برمجة التطبيقات Express بالإضافة إلى MongoDB rest API الذي قمنا بتطويره في هذه الدورة.

25
00:01:40,295 --> 00:01:43,415
لدمج العميل والخادم،

26
00:01:43,415 --> 00:01:44,810
كما أدركنا،

27
00:01:44,810 --> 00:01:50,020
يتم تنفيذ خادمنا بالفعل لدعم واجهة برمجة تطبيقات REST كاملة.

28
00:01:50,020 --> 00:01:51,695
من جانب العميل،

29
00:01:51,695 --> 00:01:53,240
سواء كان العميل الزاوي أو العميل

30
00:01:53,240 --> 00:01:55,750
الأيوني أو عميل البرنامج النصي الأصلي،

31
00:01:55,750 --> 00:02:00,740
فإنها تتفاعل جميعها مع الخادم باستخدام نقاط النهاية REST API.

32
00:02:00,740 --> 00:02:06,135
لذلك، عندما يرسل العميل الطلب إلى الخادم عند نقطة نهاية REST API،

33
00:02:06,135 --> 00:02:10,729
سيستجيب الخادم مع بيانات JSON المقابلة مرة أخرى إلى العميل،

34
00:02:10,729 --> 00:02:16,720
ويمكن للعميل بعد ذلك الاستفادة من بيانات JSON لتقديم طرق العرض للمستخدم.

35
00:02:16,720 --> 00:02:22,970
لذلك، بالنظر إلى هذا الفهم للتواصل بين العميل والخادم،

36
00:02:22,970 --> 00:02:25,780
يجب أن يكون التكامل واضحًا إلى حد ما.

37
00:02:25,780 --> 00:02:26,960
ولكن، الآن بالطبع،

38
00:02:26,960 --> 00:02:30,820
عندما قمنا بتطوير عميل Angular أو الأيونية أو NativeScript،

39
00:02:30,820 --> 00:02:34,990
لم نفعل جزء مصادقة المستخدم الكامل،

40
00:02:34,990 --> 00:02:38,225
لأننا لم يكن لدينا ذلك في خادم JSON الخاص بنا.

41
00:02:38,225 --> 00:02:43,250
الآن بعد أن حصلنا على مصادقة المستخدم المضمنة في جانب الخادم الخاص بنا،

42
00:02:43,250 --> 00:02:47,810
نحتاج إلى تحديث تطبيقات العميل الخاصة بنا

43
00:02:47,810 --> 00:02:52,970
لتمكينها من القيام بمصادقة المستخدم على جانب الخادم،

44
00:02:52,970 --> 00:02:56,660
عن طريق نشر معلومات تسجيل الدخول إلى الخادم ومن ثم

45
00:02:56,660 --> 00:03:01,190
الحصول على رمز المصادقة من جانب الخادم،

46
00:03:01,190 --> 00:03:04,400
وبعد ذلك، التواصل مع الخادم بما

47
00:03:04,400 --> 00:03:08,175
في ذلك رمز المصادقة في رأس رسائل الطلب.

48
00:03:08,175 --> 00:03:10,130
لذلك، كل هذا يعني أننا بحاجة إلى

49
00:03:10,130 --> 00:03:12,860
إجراء تعديلات طفيفة على كل من العميل والخادم،

50
00:03:12,860 --> 00:03:15,860
بحيث يمكن للاثنين التواصل مع بعضها البعض.

51
00:03:15,860 --> 00:03:21,020
أحد الجوانب التي لم أتعامل معها في التمرين سابقًا،

52
00:03:21,020 --> 00:03:26,445
هو كيفية تعامل الخادم مع معلمات الاستعلام التي تأتي من جانب العميل.

53
00:03:26,445 --> 00:03:27,970
لذلك، كما أدركنا،

54
00:03:27,970 --> 00:03:31,925
عندما يرسل جانب العميل طلبًا للحصول

55
00:03:31,925 --> 00:03:37,360
على طبق مميز أو قائد مميز أو ترويج ميزة،

56
00:03:37,360 --> 00:03:41,665
رأينا أن عنوان URL يتضمن أطباق،

57
00:03:41,665 --> 00:03:45,095
ميزة علامة الاستفهام تساوي الصواب في

58
00:03:45,095 --> 00:03:48,840
عنوان URL للطلب الذي يأتي من جانب العميل.

59
00:03:48,840 --> 00:03:51,670
الآن، في البيانات على جانب الخادم،

60
00:03:51,670 --> 00:03:54,040
رأينا بالفعل أن الطبق،

61
00:03:54,040 --> 00:03:56,090
أو الترويج أو القائد،

62
00:03:56,090 --> 00:03:59,835
يتضمن علامة الميزة بالفعل في بيانات JSON.

63
00:03:59,835 --> 00:04:02,975
لذلك، عندما يأتي هذا الطلب إلى جانب الخادم،

64
00:04:02,975 --> 00:04:10,285
فيجب أن يكون الخادم قادرًا على استخراج معلمة الاستعلام هذه من الطلب الوارد،

65
00:04:10,285 --> 00:04:16,865
ثم قم بإجراء استعلام

66
00:04:16,865 --> 00:04:24,485
MongoDB بشكل مناسب ثم الحصول على النتائج فقط حيث يتم تعيين هذه العلامة المميزة إلى true.

67
00:04:24,485 --> 00:04:26,365
لذلك، للقيام بذلك كما رأينا،

68
00:04:26,365 --> 00:04:36,380
عنوان URL الذي يتم استخدامه لإرسال الطلب إلى الخادم هو/الأطباق؟ ميزة = صحيح.

69
00:04:36,380 --> 00:04:42,365
لذا، هذه هي الطريقة التي سنقوم بتزويد معلمات الاستعلام إلى جانب الخادم الخاص بنا.

70
00:04:42,365 --> 00:04:47,510
الآن، بالإضافة إلى ذلك، عندما يتم تلقي هذه المعلومات على جانب الخادم،

71
00:04:47,510 --> 00:04:51,890
الآن، رأينا أنه في وقت سابق عندما فعلنا طلب الحصول على على جانب الخادم،

72
00:04:51,890 --> 00:04:56,975
قلنا ببساطة أطباق تجد وبعد ذلك سوف نجد جميع الأطباق ومن ثم إعادتها

73
00:04:56,975 --> 00:05:03,675
عندما يتم إرسال طلب الحصول إلى DishRouterRoute/.

74
00:05:03,675 --> 00:05:09,470
وينطبق نفس المنطق على كل من جهاز التوجيه الترويجي وكذلك على جهاز التوجيه الزعيم.

75
00:05:09,470 --> 00:05:14,805
الآن، عندما تقوم بتضمين معلمة استعلام مثل ذلك في عنوان URL،

76
00:05:14,805 --> 00:05:19,270
كيف سيتمكن جانب الخادم من استخراج معلمة الاستعلام هذه؟

77
00:05:19,270 --> 00:05:22,730
لذلك، هذا هو المكان الذي يحتوي فيه الطلب الوارد

78
00:05:22,730 --> 00:05:27,055
على معلمة الاستعلام هذه المرفقة بعنوان URL الوارد،

79
00:05:27,055 --> 00:05:31,835
سيقوم الخادم السريع بمعالجة ذلك تلقائيًا وتحويله إلى

80
00:05:31,835 --> 00:05:38,910
كائن JSON يتم تحميله على رسالة طلب قادمة على جانب الخادم.

81
00:05:38,910 --> 00:05:45,185
الآن، هذا متاح على جانب الخادم في شكل req.query.

82
00:05:45,185 --> 00:05:49,665
لذلك، مهما كانت معلمات الاستعلام التي تضمينها في عنوان URL،

83
00:05:49,665 --> 00:05:56,860
سيتم تحويلها إلى كائنات JSON المقابلة مع مجموعة المعلومات كما هو موضح هنا،

84
00:05:56,860 --> 00:06:01,350
ثم تحميلها على كائن الطلب على جانب الخادم.

85
00:06:01,350 --> 00:06:04,670
لذلك، باستخدام req.query على جانب الخادم،

86
00:06:04,670 --> 00:06:08,105
سنكون قادرين على الحصول على معلمات الاستعلام هذه.

87
00:06:08,105 --> 00:06:11,840
لذلك، عند إجراء طلب الحصول على جانب الخادم،

88
00:06:11,840 --> 00:06:18,635
وتقول dishes.find ثم تقوم بتضمين req.query في البحث هناك.

89
00:06:18,635 --> 00:06:25,040
لذلك، عندما يتم الاستعلام عن MongoDB، عندئذ،

90
00:06:25,040 --> 00:06:31,160
فقط تلك السجلات أو فقط تلك الوثائق التي تم تعيين المميز لها إلى true سيتم

91
00:06:31,160 --> 00:06:38,270
استخراجها من MongoDB وتوفيرها مرة أخرى لنا داخل طريقة الحصول هنا،

92
00:06:38,270 --> 00:06:41,625
وبعد ذلك، يمكن إرجاعها إلى جانب العميل.

93
00:06:41,625 --> 00:06:49,745
لذا، هذا بسيط مثل ذلك في التعامل مع معلمات الاستعلام على جانب الخادم الخاص بنا.

94
00:06:49,745 --> 00:06:55,135
لذلك، هذا التحديث سوف نفعل لكل من جهاز التوجيه طبق، جهاز

95
00:06:55,135 --> 00:07:01,225
التوجيه الترويجي، وجهاز التوجيه زعيم على جانب الخادم لدينا.

96
00:07:01,225 --> 00:07:04,880
الجزء التالي هو بالطبع، مصادقة المستخدم.

97
00:07:04,880 --> 00:07:07,530
لذلك، كما أدركنا على جانب الخادم،

98
00:07:07,530 --> 00:07:11,095
لدينا بالفعل نقاط النهاية REST API هذه،

99
00:07:11,095 --> 00:07:13,780
والتي هي مفيدة لمصادقة المستخدم. على

100
00:07:13,780 --> 00:07:18,855
وجه الخصوص، عند إجراء مشاركة إلى/المستخدمين/تسجيل الدخول،

101
00:07:18,855 --> 00:07:22,040
مع اسم المستخدم وكلمة المرور، ثم،

102
00:07:22,040 --> 00:07:26,140
سوف تكون قادرة على مصادقة المستخدم على جانب الخادم.

103
00:07:26,140 --> 00:07:30,535
الآن، عندما تتم مصادقة المستخدم على جانب الخادم بنجاح،

104
00:07:30,535 --> 00:07:35,059
فإن رسالة الرد القادمة من جانب الخادم ستتضمن

105
00:07:35,059 --> 00:07:43,345
رمز ويب JSON في نص الرد الخاص برسالة الرد الواردة من جانب الخادم.

106
00:07:43,345 --> 00:07:44,810
لذلك، على جانب العميل،

107
00:07:44,810 --> 00:07:49,210
يجب أن نكون قادرين على استخراج هذا الرمز المميز ثم استخدام هذا الرمز المميز في وقت لاحق.

108
00:07:49,210 --> 00:07:52,700
لذلك، عندما يتلقى العميل رسالة الرد من

109
00:07:52,700 --> 00:07:57,140
جانب الخادم ويتم مصادقة المستخدم بنجاح على جانب الخادم،

110
00:07:57,140 --> 00:07:59,690
ستحتوي رسالة الرد على رمز ويب JSON،

111
00:07:59,690 --> 00:08:02,290
والذي يجب استخراجه، وبعد ذلك،

112
00:08:02,290 --> 00:08:05,240
يجب على العميل تضمين رمز ويب JSON هذا

113
00:08:05,240 --> 00:08:10,620
في لكل طلب صادر من جانب العميل.

114
00:08:10,620 --> 00:08:13,585
إذاً، كيف نتعامل مع هذه المجموعة الكاملة من العمليات؟

115
00:08:13,585 --> 00:08:15,800
الآن، هذا هو المكان

116
00:08:15,800 --> 00:08:20,255
الذي سنقوم بتنفيذ خدمة أخرى سيتم استخدامها على جانب العميل،

117
00:08:20,255 --> 00:08:21,720
في عميل Angular الخاص بنا،

118
00:08:21,720 --> 00:08:23,810
يسمى خدمة المصادقة،

119
00:08:23,810 --> 00:08:30,185
وهذا هو المكان الذي سنتعامل مع تسجيل الدخول بالكامل وعمليات الخروج.

120
00:08:30,185 --> 00:08:33,850
الآن، عملية الخروج واضحة إلى حد ما، ولكن

121
00:08:33,850 --> 00:08:37,840
إذا قمنا بتدمير رمز ويب JSON الذي لدينا على جانب

122
00:08:37,840 --> 00:08:41,160
العميل، فلن يتمكن العميل من الوصول إلى الخادم.

123
00:08:41,160 --> 00:08:43,850
لذا، فهي بسيطة مثل مجرد تدمير

124
00:08:43,850 --> 00:08:48,095
رمز ويب JSON على جانب العميل لتسجيل الخروج من هذا العميل.

125
00:08:48,095 --> 00:08:50,460
لذلك، وبالنظر إلى هذا الفهم،

126
00:08:50,460 --> 00:08:54,110
دعونا نرى الخطوات التي تشارك في

127
00:08:54,110 --> 00:08:59,760
القيام مصادقة المستخدم والتعامل مع مصادقة المستخدم على جانب العميل.

128
00:08:59,760 --> 00:09:03,320
لذلك، للتعامل مع مصادقة المستخدم على جانب العميل،

129
00:09:03,320 --> 00:09:08,945
سيقوم العميل بإرسال طلب نشر إلى نقطة النهاية /المستخدمين/تسجيل الدخول،

130
00:09:08,945 --> 00:09:14,110
وسوف يحتوي نص طلب المشاركة على اسم المستخدم وكلمة المرور.

131
00:09:14,110 --> 00:09:16,660
نحن نستخدم مصادقة تسجيل الدخول في هذه الحالة.

132
00:09:16,660 --> 00:09:18,650
الآن، لمصادقة Facebook مرة أخرى

133
00:09:18,650 --> 00:09:22,355
، هذا إعداد مختلف لن أناقشه الآن.

134
00:09:22,355 --> 00:09:26,465
ولكن،

135
00:09:26,465 --> 00:09:28,730
سيحتوي نص الطلب كما سترى للمصادقة المحلية على اسم المستخدم وكلمة المرور.

136
00:09:28,730 --> 00:09:33,170
لذلك، عندما تتم مصادقة المستخدم بنجاح على جانب الخادم،

137
00:09:33,170 --> 00:09:36,410
سيقوم الخادم بالرد مرة أخرى

138
00:09:36,410 --> 00:09:41,425
على العميل من خلال تضمين رمز ويب JSON في رسالة الرد.

139
00:09:41,425 --> 00:09:46,070
لذلك، عندما يتلقى العميل رسالة الرد من جانب الخادم،

140
00:09:46,070 --> 00:09:49,790
فسيتعين على العميل التقاط رمز ويب JSON هذا،

141
00:09:49,790 --> 00:09:55,025
ثم حفظ رمز ويب JSON في التخزين المحلي على جانب العميل.

142
00:09:55,025 --> 00:10:01,250
بعد ذلك، يجب على العميل تضمين هذا الرمز المميز في كل طلب صادر.

143
00:10:01,250 --> 00:10:04,455
إذن، كيف يتم إنجاز ذلك على جانب العميل؟

144
00:10:04,455 --> 00:10:06,155
أولاً وقبل كل شيء، بالطبع،

145
00:10:06,155 --> 00:10:11,980
تحتاج إلى حفظ رمز ويب JSON الوارد في التخزين المحلي،

146
00:10:11,980 --> 00:10:16,790
ويتم ذلك في خدمة المصادقة التي سنقوم بتنفيذها على جانب العميل.

147
00:10:16,790 --> 00:10:19,975
الآن، لكل طلب صادر،

148
00:10:19,975 --> 00:10:22,850
سيقوم العميل بتضمين هذا الرمز المميز في

149
00:10:22,850 --> 00:10:27,100
الرأس، رأس التفويض للطلب الصادر.

150
00:10:27,100 --> 00:10:28,555
الآن، كيف يتم إنجاز هذا؟

151
00:10:28,555 --> 00:10:33,935
لذا، هذا هو المكان الذي سنأخذ فيه مساعدة اعتراض HTTP،

152
00:10:33,935 --> 00:10:37,265
الذي يدعمه HttpClient في Angular.

153
00:10:37,265 --> 00:10:39,675
لذا، مع اعتراض HTTP،

154
00:10:39,675 --> 00:10:42,305
يسمح لنا المعترض باعتراض

155
00:10:42,305 --> 00:10:45,875
كل رسالة طلب صادرة أو حتى

156
00:10:45,875 --> 00:10:50,010
اعتراض كل رسالة رد واردة إذا اخترت ذلك.

157
00:10:50,010 --> 00:10:52,175
ولكن في تطبيق Angular،

158
00:10:52,175 --> 00:10:56,215
سنقوم بتنفيذ اعتراض الطلب،

159
00:10:56,215 --> 00:10:59,540
والذي سأوضح في التمرين لاحقًا.

160
00:10:59,540 --> 00:11:02,460
في اعتراض طلب HTTP،

161
00:11:02,460 --> 00:11:04,375
عند اعتراض رسالة الطلب، سيتم اعتراض

162
00:11:04,375 --> 00:11:09,915
كل رسالة طلب صادرة ومن ثم

163
00:11:09,915 --> 00:11:15,650
سيتم إدراج رمز ويب JSON في رأس التفويض الخاص برسالة الطلب.

164
00:11:15,650 --> 00:11:20,290
ثم بعد ذلك، سيتم تمرير رسالة الطلب إلى جانب الخادم.

165
00:11:20,290 --> 00:11:26,825
لذلك، وبالتالي، فإن كل طلب صادر بعد مصادقة المستخدم على جانب الخادم،

166
00:11:26,825 --> 00:11:30,620
فإن كل طلب صادر من جانب العميل يحمل

167
00:11:30,620 --> 00:11:35,590
رمز ويب JSON في رأس التفويض للطلب الصادر.

168
00:11:35,590 --> 00:11:38,600
الآن، بمجرد تسجيل خروج العميل،

169
00:11:38,600 --> 00:11:42,595
سيتم تدمير رمز ويب JSON على جانب العميل.

170
00:11:42,595 --> 00:11:47,215
لذلك، بعد ذلك، لن تحتوي الطلبات الصادرة على رمز ويب JSON بعد الآن،

171
00:11:47,215 --> 00:11:50,160
لأن رمز ويب JSON غير موجود على جانب العميل.

172
00:11:50,160 --> 00:11:53,240
لذلك، وبالتالي، يفقد المستخدم المصادقة.

173
00:11:53,240 --> 00:12:00,030
لذا، هذه هي الطريقة التي سنتعامل بها مع عملية تسجيل الدخول والخروج على جانب العميل،

174
00:12:00,030 --> 00:12:02,290
من خلال التواصل مع الخادم،

175
00:12:02,290 --> 00:12:04,225
ثم الحصول على رمز ويب JSON،

176
00:12:04,225 --> 00:12:08,845
ثم تضمين رمز ويب JSON في كل طلب صادر.

177
00:12:08,845 --> 00:12:14,250
الآن، مع هذا الفهم لكيفية تفاعل العميل والخادم،

178
00:12:14,250 --> 00:12:18,205
دعونا ننتقل الآن إلى التدريبين التاليين.

179
00:12:18,205 --> 00:12:22,540
أولا، سنقوم بتحديث جانب الخادم مع عدد قليل من الإضافات،

180
00:12:22,540 --> 00:12:28,220
بحيث يمكن أن تتكامل بشكل جيد مع موقع عملائنا.

181
00:12:28,220 --> 00:12:32,750
بعد ذلك، سنقوم بتحديث جانب العميل أو بالأحرى سأعطيك

182
00:12:32,750 --> 00:12:36,215
تطبيق عميل كامل

183
00:12:36,215 --> 00:12:40,795
أخذته من دورة Angular السابقة ثم سأقوم

184
00:12:40,795 --> 00:12:45,875
بتحديثه، والذي يوفر لنا أيضًا القدرة على استخدام اعتراضات HTTP

185
00:12:45,875 --> 00:12:51,595
على كل من الطلبات الصادرة و رسائل الرد الواردة.

186
00:12:51,595 --> 00:12:56,090
لذلك، سوف نتعامل مع كل من هذين في التدريبين المقبلين،

187
00:12:56,090 --> 00:12:58,370
وفي نهاية ذلك، سوف تفهم كيفية

188
00:12:58,370 --> 00:13:02,530
دمج العميل الخاص بك وجانب الخادم.