1
00:00:03,650 --> 00:00:06,795
Ahora que hemos completado

2
00:00:06,795 --> 00:00:11,395
la implementación del servidor REST API usando Express y MongoDB en este curso,

3
00:00:11,395 --> 00:00:14,990
el siguiente pensamiento inmediato que podría ocurrir en su mente es,

4
00:00:14,990 --> 00:00:20,490
ya que ya hemos desarrollado las aplicaciones cliente en los cursos anteriores,

5
00:00:20,490 --> 00:00:24,930
cómo integramos las dos juntas para que nuestra puede

6
00:00:24,930 --> 00:00:30,880
interactuar con el servidor API REST completo que hemos desarrollado en este curso?

7
00:00:30,880 --> 00:00:33,820
Por lo tanto, esto es lo que examinaremos en

8
00:00:33,820 --> 00:00:39,820
esta conferencia y los dos ejercicios que siguen a esta conferencia.

9
00:00:39,820 --> 00:00:41,770
Por lo tanto, al final de esta lección,

10
00:00:41,770 --> 00:00:44,390
tendrá React Client que será

11
00:00:44,390 --> 00:00:47,330
capaz de comunicarse con el servidor que acaba de desarrollar en

12
00:00:47,330 --> 00:00:50,345
este curso y ser capaz de soportar

13
00:00:50,345 --> 00:00:56,510
la vista completa del lado del cliente de toda nuestra aplicación.

14
00:00:56,510 --> 00:00:58,970
Así veremos que hemos desarrollado

15
00:00:58,970 --> 00:01:02,565
la

16
00:01:02,565 --> 00:01:07,795
aplicación completa de extremo a extremo desde el lado del cliente hasta el lado del servidor en este curso.

17
00:01:07,795 --> 00:01:10,910
Para integrar el cliente y el servidor,

18
00:01:10,910 --> 00:01:13,670
como nos hemos dado cuenta de que nuestro servidor ya está

19
00:01:13,670 --> 00:01:17,525
implementado para soportar la API REST completa.

20
00:01:17,525 --> 00:01:19,220
Desde nuestro lado del cliente,

21
00:01:19,220 --> 00:01:20,720
ya sea el cliente angular,

22
00:01:20,720 --> 00:01:23,340
el cliente iónico o el cliente de script nativo,

23
00:01:23,340 --> 00:01:28,240
todos interactúan con el servidor utilizando los extremos de la API REST.

24
00:01:28,240 --> 00:01:33,630
Por lo tanto, cuando el cliente envía la solicitud al servidor en el punto final de la API REST,

25
00:01:33,630 --> 00:01:38,190
el servidor responderá con los datos JSON correspondientes al cliente.

26
00:01:38,190 --> 00:01:44,225
A continuación, el cliente puede hacer uso de los datos JSON para representar las vistas para el usuario.

27
00:01:44,225 --> 00:01:50,450
Por lo tanto, dada esta comprensión de la comunicación entre el cliente y

28
00:01:50,450 --> 00:01:53,745
el servidor, la integración debe ser bastante sencilla.

29
00:01:53,745 --> 00:01:58,475
Ahora que tenemos la autenticación de usuario integrada en nuestro lado del servidor,

30
00:01:58,475 --> 00:02:03,330
necesitamos actualizar nuestras aplicaciones cliente para

31
00:02:03,330 --> 00:02:08,400
permitirles realizar la autenticación de usuario en el lado del servidor

32
00:02:08,400 --> 00:02:12,200
publicando la información de inicio de sesión en el servidor y luego

33
00:02:12,200 --> 00:02:16,010
obteniendo el token de autenticación desde

34
00:02:16,010 --> 00:02:19,120
el lado del servidor y luego comunicarse con el servidor

35
00:02:19,120 --> 00:02:23,700
incluyendo el token de autenticación en el encabezado de los mensajes de solicitud.

36
00:02:23,700 --> 00:02:27,050
Por lo tanto, todo esto significa que tenemos que hacer pequeños ajustes tanto en

37
00:02:27,050 --> 00:02:31,345
el cliente como en el servidor para que los dos puedan comunicarse entre sí.

38
00:02:31,345 --> 00:02:36,530
Un aspecto que no he tratado anteriormente en el ejercicio

39
00:02:36,530 --> 00:02:41,970
es cómo el servidor manejará los parámetros de consulta que vienen desde el lado del cliente.

40
00:02:41,970 --> 00:02:43,480
Entonces, como nos dimos cuenta,

41
00:02:43,480 --> 00:02:47,450
cuando el lado del cliente envía una solicitud de

42
00:02:47,450 --> 00:02:53,035
un plato destacado o un líder destacado o una promoción destacada,

43
00:02:53,035 --> 00:02:55,910
vimos que la URL incluye, la

44
00:02:55,910 --> 00:02:59,590
característica de signo de interrogación de platos es igual a

45
00:02:59,590 --> 00:03:04,370
verdadero en la URL de solicitud que proviene del lado del cliente.

46
00:03:04,370 --> 00:03:07,210
Ahora, en los datos en el lado del servidor,

47
00:03:07,210 --> 00:03:09,585
ya vimos que el plato,

48
00:03:09,585 --> 00:03:15,370
la promoción o el líder incluye la bandera destacada ya en los datos JSON.

49
00:03:15,370 --> 00:03:18,649
Por lo tanto, cuando esta solicitud llega al lado del servidor,

50
00:03:18,649 --> 00:03:21,394
entonces el servidor debería poder extraer

51
00:03:21,394 --> 00:03:26,765
este parámetro de consulta de la solicitud entrante y luego

52
00:03:26,765 --> 00:03:32,390
hacer apropiadamente la consulta

53
00:03:32,390 --> 00:03:39,950
del MongoDB y luego obtener solo los resultados donde este indicador destacado se establece en true.

54
00:03:39,950 --> 00:03:41,740
Por lo tanto, para hacer eso como vimos,

55
00:03:41,740 --> 00:03:47,075
la URL que se utiliza para enviar la solicitud al servidor es,

56
00:03:47,075 --> 00:03:52,030
slash platos signo de interrogación presentado es igual a true.

57
00:03:52,030 --> 00:03:57,905
Por lo tanto, así es como proporcionaremos los parámetros de consulta a nuestro lado del servidor.

58
00:03:57,905 --> 00:04:02,610
Ahora, además, cuando se recibe esta información en el lado del servidor,

59
00:04:02,610 --> 00:04:07,430
ahora vimos que antes cuando hicimos la solicitud get en el lado del servidor,

60
00:04:07,430 --> 00:04:10,190
simplemente dijimos que los platos encuentran y luego encontraríamos

61
00:04:10,190 --> 00:04:13,135
todos los platos y luego devolverlos cuando

62
00:04:13,135 --> 00:04:19,745
se envía la solicitud get a la ruta del enrutador plato barra .

63
00:04:19,745 --> 00:04:25,185
La misma lógica se aplica tanto al enrutador promocional como al enrutador líder.

64
00:04:25,185 --> 00:04:30,339
Ahora, cuando incluye un parámetro de consulta como ese en la URL,

65
00:04:30,339 --> 00:04:34,695
¿cómo nuestro servidor podrá extraer este parámetro de consulta?

66
00:04:34,695 --> 00:04:35,980
Entonces, aquí es donde,

67
00:04:35,980 --> 00:04:42,590
cuando la solicitud entrante tiene este parámetro de consulta adjunto a la URL entrante,

68
00:04:42,590 --> 00:04:47,375
el servidor express procesará automáticamente eso y lo convertirá en

69
00:04:47,375 --> 00:04:54,445
un objeto JSON que se carga en un mensaje de solicitud que viene en el lado del servidor.

70
00:04:54,445 --> 00:05:00,710
Ahora, esto está disponible en el lado del servidor en forma de req.query. Por lo

71
00:05:00,710 --> 00:05:06,545
tanto, cualquier parámetro de consulta que incluya en la URL se convertirá en

72
00:05:06,545 --> 00:05:11,480
objetos JSON correspondientes con la información establecida como

73
00:05:11,480 --> 00:05:16,880
se muestra aquí y luego se cargará en el objeto de solicitud en el lado del servidor.

74
00:05:16,880 --> 00:05:19,940
Por lo tanto, mediante el uso de req.query en el lado del servidor,

75
00:05:19,940 --> 00:05:23,625
podremos obtener estos parámetros de consulta.

76
00:05:23,625 --> 00:05:27,935
Por lo tanto, cuando realiza una solicitud get en el lado del servidor, dice

77
00:05:27,935 --> 00:05:34,115
dishes.find y luego incluye el req.query en el hallazgo allí.

78
00:05:34,115 --> 00:05:38,960
Por lo tanto, cuando se

79
00:05:38,960 --> 00:05:44,120
consulta el MongoDB, solo aquellos registros o solo aquellos documentos para los

80
00:05:44,120 --> 00:05:50,390
que el destacado se establece en verdadero serán extraídos del MongoDB y proporcionados de nuevo a

81
00:05:50,390 --> 00:05:57,020
nosotros dentro de este método get aquí y luego pueden ser devueltos al lado del cliente.

82
00:05:57,020 --> 00:06:05,270
Por lo tanto, esto es tan simple como eso en el manejo de los parámetros de consulta en nuestro lado del servidor.

83
00:06:05,270 --> 00:06:10,645
Por lo tanto, esta actualización haremos tanto al enrutador de plato,

84
00:06:10,645 --> 00:06:16,880
al enrutador promocional y al enrutador líder en nuestro lado del servidor.

85
00:06:16,880 --> 00:06:18,430
La siguiente parte es,

86
00:06:18,430 --> 00:06:20,545
por supuesto, Autenticación de Usuario.

87
00:06:20,545 --> 00:06:22,060
Por lo tanto, como nos hemos dado cuenta,

88
00:06:22,060 --> 00:06:24,150
en el lado del servidor ya tenemos

89
00:06:24,150 --> 00:06:29,450
estos puntos finales de API REST que son útiles para la autenticación de usuario,

90
00:06:29,450 --> 00:06:33,260
en particular cuando haces una publicación para reducir los usuarios

91
00:06:33,260 --> 00:06:37,100
el inicio de sesión con el nombre de usuario y

92
00:06:37,100 --> 00:06:41,675
la contraseña, entonces podrás autenticar al usuario en el servidor lado.

93
00:06:41,675 --> 00:06:46,080
Ahora, cuando el usuario se autentica correctamente en el lado del servidor,

94
00:06:46,080 --> 00:06:50,584
el mensaje de respuesta proveniente del lado del servidor incluirá

95
00:06:50,584 --> 00:06:58,880
el token web JSON en el cuerpo de respuesta del mensaje de respuesta entrante desde el lado del servidor.

96
00:06:58,880 --> 00:07:00,350
Por lo tanto, en el lado del cliente,

97
00:07:00,350 --> 00:07:04,700
deberíamos poder extraer este token y luego usar este token posteriormente.

98
00:07:04,700 --> 00:07:08,210
Por lo tanto, cuando el cliente recibe el mensaje de respuesta desde

99
00:07:08,210 --> 00:07:12,560
el lado del servidor y el usuario se autentica correctamente en el lado del servidor,

100
00:07:12,560 --> 00:07:15,220
el mensaje de respuesta contendrá el token web JSON,

101
00:07:15,220 --> 00:07:16,950
que debe extraerse,

102
00:07:16,950 --> 00:07:20,780
y a partir de entonces el cliente debe incluir este token web JSON en

103
00:07:20,780 --> 00:07:26,200
el para cada solicitud saliente desde el lado del cliente.

104
00:07:26,200 --> 00:07:31,205
Esto se logra guardando el token web JSON en el almacenamiento local.

105
00:07:31,205 --> 00:07:35,155
A partir de entonces, para cada solicitud de búsqueda que emita,

106
00:07:35,155 --> 00:07:40,365
podemos configurar el encabezado de autorización para contener el token web JSON.

107
00:07:40,365 --> 00:07:43,815
Ahora, el proceso de cierre de sesión es bastante sencillo,

108
00:07:43,815 --> 00:07:47,865
si destruimos el token web JSON que tenemos en el lado

109
00:07:47,865 --> 00:07:51,210
del cliente, entonces el cliente ya no podrá acceder al servidor.

110
00:07:51,210 --> 00:07:53,930
Por lo tanto, es tan simple como simplemente destruir

111
00:07:53,930 --> 00:07:58,180
el token web JSON en el lado del cliente para cerrar sesión ese cliente.

112
00:07:58,180 --> 00:08:00,530
Por lo tanto, teniendo en cuenta esta comprensión,

113
00:08:00,530 --> 00:08:04,175
veamos los pasos que están involucrados en

114
00:08:04,175 --> 00:08:09,840
hacer la autenticación del usuario en el manejo de la autenticación del usuario en el lado del cliente.

115
00:08:09,840 --> 00:08:13,085
Por lo tanto, para manejar la autenticación del usuario en el lado del cliente,

116
00:08:13,085 --> 00:08:19,000
el cliente enviará una solicitud de publicación al extremo de inicio de sesión de los usuarios de barra diagonal,

117
00:08:19,000 --> 00:08:24,190
y el cuerpo de la solicitud de publicación contendrá el nombre de usuario y la contraseña.

118
00:08:24,190 --> 00:08:26,720
Estamos utilizando la autenticación de inicio de sesión en este caso.

119
00:08:26,720 --> 00:08:28,695
Ahora, para la autenticación de Facebook, de nuevo,

120
00:08:28,695 --> 00:08:32,425
esa es una configuración diferente que no voy a discutir en este momento.

121
00:08:32,425 --> 00:08:35,570
Pero el cuerpo de la solicitud tal como ve para la

122
00:08:35,570 --> 00:08:38,780
autenticación local contendrá el nombre de usuario y la contraseña.

123
00:08:38,780 --> 00:08:43,220
Por lo tanto, cuando el usuario se autentica correctamente en el lado

124
00:08:43,220 --> 00:08:46,460
del servidor, el servidor responderá de nuevo

125
00:08:46,460 --> 00:08:51,490
al cliente incluyendo el token web JSON en el mensaje de respuesta.

126
00:08:51,490 --> 00:08:56,150
Por lo tanto, cuando el cliente recibe el mensaje de respuesta desde el lado del servidor,

127
00:08:56,150 --> 00:09:00,320
entonces el cliente tendrá que capturar este JSON Web Token y luego

128
00:09:00,320 --> 00:09:05,080
guardar el JSON Web Token en el almacenamiento local en el lado del cliente.

129
00:09:05,080 --> 00:09:11,300
A partir de entonces, el cliente debe incluir este token en cada solicitud saliente.

130
00:09:11,300 --> 00:09:14,495
Entonces, ¿cómo se logra esto en el lado del cliente?

131
00:09:14,495 --> 00:09:20,285
En primer lugar, necesitamos guardar el token web JSON en el almacenamiento local.

132
00:09:20,285 --> 00:09:25,670
Ahora, esto se logra dentro del creador de acciones que maneja el proceso de inicio de sesión del usuario.

133
00:09:25,670 --> 00:09:32,685
Por lo tanto, cuando la publicación se realiza en el servidor desde el creador de inducción del lado del cliente

134
00:09:32,685 --> 00:09:36,020
, el mensaje de respuesta contendrá el token,

135
00:09:36,020 --> 00:09:41,540
y este token se guarda en el creador de acción que maneja el proceso de inicio de sesión del usuario.

136
00:09:41,540 --> 00:09:45,875
Ahora a partir de entonces, cuando se realiza cualquier solicitud de recuperación,

137
00:09:45,875 --> 00:09:52,829
entonces podemos establecer fácilmente el encabezado de autorización en la solicitud de recuperación saliente.

138
00:09:52,829 --> 00:09:56,005
Ahora, una vez que el cliente cierra la sesión,

139
00:09:56,005 --> 00:09:59,930
el token web JSON se destruirá en el lado del cliente.

140
00:09:59,930 --> 00:10:03,050
Entonces, a partir de entonces, las solicitudes salientes

141
00:10:03,050 --> 00:10:07,490
ya no contendrán el token web JSON porque el token web JSON no existe en el lado del cliente.

142
00:10:07,490 --> 00:10:10,790
Por lo tanto, el usuario pierde la autenticación.

143
00:10:10,790 --> 00:10:17,455
Por lo tanto, así es como manejaremos el proceso de inicio de sesión y cierre de sesión en el lado del cliente.

144
00:10:17,455 --> 00:10:21,890
Al comunicarse con el servidor y luego obtener el token web JSON y

145
00:10:21,890 --> 00:10:26,185
luego incluir el token web JSON en cada solicitud saliente.

146
00:10:26,185 --> 00:10:31,570
Ahora, con esta comprensión de cómo interactuarán el cliente y el servidor,

147
00:10:31,570 --> 00:10:35,540
procedamos ahora a los siguientes dos ejercicios.

148
00:10:35,540 --> 00:10:40,410
Primero, actualizaremos el lado del servidor con algunas adiciones para

149
00:10:40,410 --> 00:10:45,550
que pueda integrarse bien con nuestro lado cliente.

150
00:10:45,550 --> 00:10:50,075
A partir de entonces, actualizaremos el lado del cliente o más bien le daré

151
00:10:50,075 --> 00:10:54,200
una aplicación cliente completa que he tomado

152
00:10:54,200 --> 00:10:58,875
de la fuerza de reacción anterior y la adapté, la actualizé.

153
00:10:58,875 --> 00:11:03,080
Por lo tanto, trataremos ambos en los próximos dos ejercicios,

154
00:11:03,080 --> 00:11:09,460
y al final de esto comprenderá cómo integrar su lado cliente y servidor.