1
00:00:03,879 --> 00:00:07,577
Permítanme comenzar dándoles una rápida introducción

2
00:00:07,577 --> 00:00:11,705
de 10 minutos a lo esencial de la creación de redes.

3
00:00:11,705 --> 00:00:18,769
Cuanto más enseño inglés, más me doy cuenta de que solo para usar sus características más bonitas

4
00:00:18,769 --> 00:00:23,210
de angular necesitas tener una comprensión de tantas diferentes aletas conectadas

5
00:00:23,210 --> 00:00:27,165
antes de que puedas incluso entender lo que estás haciendo con angular.

6
00:00:27,165 --> 00:00:29,929
En el momento en que empieces a perseguir a cada uno de estos FN,

7
00:00:29,929 --> 00:00:32,890
se convertirán en cursos completos por su cuenta y muy pronto,

8
00:00:32,890 --> 00:00:37,539
terminaré enseñándote todo su currículo de ciencias de la computación.

9
00:00:37,539 --> 00:00:41,174
Pero dado el hecho de que tenemos tiempo limitado,

10
00:00:41,174 --> 00:00:43,554
me concentraré en entregarles lo esencial

11
00:00:43,554 --> 00:00:48,344
que necesitan para entender cada uno de los temas.

12
00:00:48,344 --> 00:00:53,383
Ahora, lo que cubrimos en este módulo en particular requerirá

13
00:00:53,383 --> 00:00:57,829
al menos una comprensión rudimentaria de cómo funciona la red de computadoras

14
00:00:57,829 --> 00:01:01,310
antes de entender por qué necesitamos usar HTTP,

15
00:01:01,310 --> 00:01:03,587
por qué nos comunicamos con un servidor.

16
00:01:03,587 --> 00:01:08,284
Cuál es la razón del retraso es que cuando estás hablando con un servidor,

17
00:01:08,284 --> 00:01:09,394
y así sucesivamente.

18
00:01:09,394 --> 00:01:14,111
Y también, los diversos protocolos que usted necesita tener en cuenta

19
00:01:14,111 --> 00:01:17,420
antes de que incluso pueda comunicarse con un servidor.

20
00:01:17,420 --> 00:01:20,239
Así que, teniendo todo esto en mente,

21
00:01:20,239 --> 00:01:25,950
una introducción rápida de 10 minutos a lo esencial de la creación de redes.

22
00:01:25,950 --> 00:01:30,575
Comenzamos a darnos cuenta de que las aplicaciones web ya no son independientes.

23
00:01:30,575 --> 00:01:38,015
Siempre tienen un back-end de nube comillas que apoya su aplicación web.

24
00:01:38,015 --> 00:01:40,370
Ahora, en estos días todo está en la Nube.

25
00:01:40,370 --> 00:01:46,444
Muy pronto estarás en la Nube también, al menos en la Nube nueve con un forro plateado.

26
00:01:46,444 --> 00:01:55,939
Pero dado que necesitamos un soporte de Silverside para que nuestra aplicación angular funcione correctamente,

27
00:01:55,939 --> 00:01:58,615
allí alojaría el servidor.

28
00:01:58,615 --> 00:02:06,140
Y en estos días alojar el servidor se hace muy fácilmente mediante el uso de uno

29
00:02:06,140 --> 00:02:09,619
de los servicios de infraestructura basados en la nube.

30
00:02:09,619 --> 00:02:15,860
Cosas como Amazon, Web Services o Heroku o Digital Ocean

31
00:02:15,860 --> 00:02:21,650
o muchos otros que proporcionan soporte de servidor basado en la nube

32
00:02:21,650 --> 00:02:26,574
que puede aprovechar para proporcionar soporte de servidor para su aplicación angular.

33
00:02:26,574 --> 00:02:32,363
Entonces, en el lado del servidor, ¿qué está exactamente disponible en el lado del servidor?

34
00:02:32,363 --> 00:02:39,814
Normalmente tiene un servidor front-end que está hablando con su aplicación angular.

35
00:02:39,814 --> 00:02:45,349
Entonces, esa es la lógica del servidor y detrás de escena,

36
00:02:45,349 --> 00:02:52,790
la lógica del servidor se está comunicando con un almacenamiento persistente como una base de datos

37
00:02:52,790 --> 00:02:56,905
donde se almacenan y recuperan sus datos.

38
00:02:56,905 --> 00:03:01,069
Cuando entres en el mundo de las redes, pronto serás bombardeado

39
00:03:01,069 --> 00:03:04,264
con 304 pequeños acrónimos.

40
00:03:04,264 --> 00:03:08,930
Cosas que pensaste que sabías lo que eran del inglés normal

41
00:03:08,930 --> 00:03:11,509
o que tienen un significado totalmente diferente

42
00:03:11,509 --> 00:03:15,610
o propósito cuando las encuentras en el mundo de las redes.

43
00:03:15,610 --> 00:03:17,764
Por lo tanto, examinemos algunos de ellos.

44
00:03:17,764 --> 00:03:22,159
Por lo tanto, en el mundo de las redes oirás a la gente hablar a través del protocolo HTTP.

45
00:03:22,159 --> 00:03:26,379
El protocolo que se utiliza para la comunicación entre el cliente y el servidor.

46
00:03:26,379 --> 00:03:29,000
Este es un protocolo de capa de aplicación

47
00:03:29,000 --> 00:03:34,409
del que hablaremos brevemente un poco más en el resto de esta conferencia.

48
00:03:34,409 --> 00:03:41,004
El protocolo HTTP para que funcione necesita una URL que se le proporcione,

49
00:03:41,004 --> 00:03:42,955
el Localizador de Recursos Uniforme.

50
00:03:42,955 --> 00:03:51,095
Entonces, esta es una cadena de caracteres separados por barras diagonales con en cada dos puntos TTP,

51
00:03:51,095 --> 00:03:55,694
en un https: adjunto delante de él.

52
00:03:55,694 --> 00:03:58,530
Y estoy seguro de que si se usa la World Wide Web,

53
00:03:58,530 --> 00:04:02,655
está bastante familiarizado con cómo se ven las URL.

54
00:04:02,655 --> 00:04:06,435
Ahora, además, escucharás a la gente hablando de JSON,

55
00:04:06,435 --> 00:04:11,607
no a tu amigo Jason, sino JavaScript Object Notation.

56
00:04:11,607 --> 00:04:19,026
Por lo tanto, la notación de objetos JavaScript es una forma de codificar datos que se envían

57
00:04:19,026 --> 00:04:22,850
desde el lado del servidor al lado del cliente o viceversa.

58
00:04:22,850 --> 00:04:26,038
Y también, oirá a la gente hablar de XML,

59
00:04:26,038 --> 00:04:30,574
otra forma de codificar datos mientras está en tránsito el envío

60
00:04:30,574 --> 00:04:33,240
entre el cliente y el sitio del servidor.

61
00:04:33,240 --> 00:04:41,584
Ahora, y también escucharán a la gente hablar de protocolos de alto nivel llamados SOAP,

62
00:04:41,584 --> 00:04:46,550
no del tipo con el que se toma una ducha, sino SOAP como un protocolo

63
00:04:46,550 --> 00:04:55,034
que permite la comunicación entre entidades de distribución dentro de la red.

64
00:04:55,034 --> 00:04:59,449
Y también, oirás a la gente hablar de REST, no de algo

65
00:04:59,449 --> 00:05:02,479
que obtienes demasiado pasando por este curso en particular.

66
00:05:02,479 --> 00:05:06,057
REST o una Transferencia de Estado Representacional.

67
00:05:06,057 --> 00:05:10,850
Tendré una conferencia más corta dedicada específicamente

68
00:05:10,850 --> 00:05:14,089
a REST un poco más adelante en este módulo.

69
00:05:14,089 --> 00:05:18,410
Y en el mundo HTTP, oirás a la gente hablar de GET,

70
00:05:18,410 --> 00:05:23,449
PUT, POST y DELETE, y te preguntarías,

71
00:05:23,449 --> 00:05:25,235
¿qué significan todos?

72
00:05:25,235 --> 00:05:29,454
Vamos a aprender un poco sobre esto en esta conferencia,

73
00:05:29,454 --> 00:05:34,459
y también la conferencia sobre REST que verá un poco más tarde.

74
00:05:34,459 --> 00:05:38,959
Una cosa importante que debes entender cuando te estás comunicando

75
00:05:38,959 --> 00:05:45,439
con un servidor es que la comunicación del servidor cliente provoca una cantidad inesperada

76
00:05:45,439 --> 00:05:48,350
de retrasos o una cantidad indeterminada de retraso

77
00:05:48,350 --> 00:05:54,454
mientras los datos se están recuperando o cargando en el servidor desde el lado del cliente.

78
00:05:54,454 --> 00:05:57,566
Entonces, lo que significa que dentro de su aplicación cliente-servidor

79
00:05:57,566 --> 00:06:00,409
necesita mantener informado al usuario sobre el hecho

80
00:06:00,409 --> 00:06:07,970
de que algo está pasando detrás de las escenas y ser capaz de manejar los retrasos

81
00:06:07,970 --> 00:06:14,149
y posiblemente no ser capaz de obtener los datos del lado del servidor.

82
00:06:14,149 --> 00:06:18,589
Es muy posible que cuando intenta conectarse a un servidor,

83
00:06:18,589 --> 00:06:20,959
la conexión con el servidor puede fallar,

84
00:06:20,959 --> 00:06:27,224
el servidor puede devolver datos incorrectos o puede causar un error en la comunicación.

85
00:06:27,224 --> 00:06:31,129
Todos estos tienen que ser manejados en su lado del cliente de manera adecuada para

86
00:06:31,129 --> 00:06:37,259
que su aplicación siga funcionando incluso en presencia de estos problemas.

87
00:06:37,259 --> 00:06:43,939
Saltando en el protocolo de capa de aplicación más popular utilizado para la comunicación

88
00:06:43,939 --> 00:06:48,569
entre el cliente y el servidor, el Protocolo de transferencia de hipertexto

89
00:06:48,569 --> 00:06:51,785
pero este es un protocolo de comunicación de servidor cliente.

90
00:06:51,785 --> 00:06:54,019
Ahora, eso puede o no tener mucho sentido para ti

91
00:06:54,019 --> 00:06:58,250
a menos que tengas suficiente experiencia en redes, pero este es un protocolo

92
00:06:58,250 --> 00:07:04,189
que se usa para codificar los mensajes que intercambias entre tu aplicación cliente,

93
00:07:04,189 --> 00:07:08,416
que es una aplicación angular en este caso, y un lado del servidor.

94
00:07:08,416 --> 00:07:14,300
Por lo tanto, este protocolo HTTP le permite recuperar documentos basados en hipertexto

95
00:07:14,300 --> 00:07:19,459
desde el lado del servidor cada vez más la información que se descarga

96
00:07:19,459 --> 00:07:25,298
desde el lado del servidor está codificada en uno de los formatos de codificación estándar como JSON o XML.

97
00:07:25,298 --> 00:07:28,759
Y, para poder hablar con un servidor,

98
00:07:28,759 --> 00:07:35,270
tienes el apoyo de varias acciones HTTP,

99
00:07:35,270 --> 00:07:39,295
o lo que nos referimos como verbos HTTP: HEAD, GET, POST,

100
00:07:39,295 --> 00:07:44,634
PUT, DELETE, TRACE, OPTIONS y CONNECT.

101
00:07:44,634 --> 00:07:51,069
Veremos en particular los verbos GET, PUT, POST y DELETE con más detalle

102
00:07:51,069 --> 00:07:57,654
cuando examinemos el resto del protocolo API un poco más tarde.

103
00:07:57,654 --> 00:08:00,904
¿Cómo funciona el protocolo HTTP?

104
00:08:00,904 --> 00:08:08,487
En el protocolo HTTP, está enviando una solicitud desde su aplicación cliente al servidor

105
00:08:08,487 --> 00:08:12,990
y esto está codificado en la forma de un mensaje de solicitud HTTP.

106
00:08:12,990 --> 00:08:18,767
El mensaje de solicitud normalmente lleva una URL en el mensaje de solicitud indicando,

107
00:08:18,767 --> 00:08:22,279
qué es lo que desea que con el lado del servidor le envíe

108
00:08:22,279 --> 00:08:24,920
y esto es normalmente un mensaje GET

109
00:08:24,920 --> 00:08:29,805
si desea que los datos se descarguen del sitio del servidor.

110
00:08:29,805 --> 00:08:35,404
Y también especificará con qué servidor particular se está comunicando.

111
00:08:35,404 --> 00:08:39,320
Cuando el servidor recibe su solicitud, el servidor

112
00:08:39,320 --> 00:08:45,215
recuperará los datos de su almacenamiento de datos, normalmente una base de datos en el lado del servidor,

113
00:08:45,215 --> 00:08:49,160
y luego empaquetará estos datos en un apropiado cuatro atrás,

114
00:08:49,160 --> 00:08:53,595
y le enviará los datos de vuelta en su lado del cliente.

115
00:08:53,595 --> 00:08:58,430
Si está obteniendo código estándar HTML, CSS y javascript desde el lado del servidor,

116
00:08:58,430 --> 00:09:00,746
entonces su navegador puede renderizar esto.

117
00:09:00,746 --> 00:09:05,705
De vuelta con aplicaciones como angular, se está conectando principalmente al servidor

118
00:09:05,705 --> 00:09:12,919
y luego recuperando datos en forma de JSON o XML la mayor parte del tiempo.

119
00:09:12,919 --> 00:09:16,730
Excepto por la descarga inicial de todos los recursos

120
00:09:16,730 --> 00:09:22,259
necesarios para que la aplicación angular se ejecute dentro de su navegador.

121
00:09:22,259 --> 00:09:29,929
Por lo tanto, como vimos anteriormente, la aplicación HTTP requiere que se envíen mensajes

122
00:09:29,929 --> 00:09:31,954
entre el cliente y el servidor.

123
00:09:31,954 --> 00:09:36,524
Un mensaje de solicitud normalmente enviado desde el cliente al servidor,

124
00:09:36,524 --> 00:09:42,600
y el mensaje de solicitud consiste en una línea de solicitud más un montón de encabezados

125
00:09:42,600 --> 00:09:47,309
donde se proporciona información adicional para calificar la solicitud.

126
00:09:47,309 --> 00:09:49,889
Veremos el uso de varios encabezados

127
00:09:49,889 --> 00:09:53,129
y ajustes en los encabezados a medida que vamos a través de algunos

128
00:09:53,129 --> 00:09:56,634
de los ejercicios en este módulo en particular.

129
00:09:56,634 --> 00:09:59,159
La línea de solicitud y los encabezados están separados

130
00:09:59,159 --> 00:10:04,500
del cuerpo del mensaje de solicitud por una línea en blanco.

131
00:10:04,500 --> 00:10:08,279
El cuerpo del mensaje puede contener datos adicionales, especialmente

132
00:10:08,279 --> 00:10:11,754
si sus clientes están enviando datos al lado del servidor.

133
00:10:11,754 --> 00:10:13,769
Por ejemplo, cuando envía un formulario,

134
00:10:13,769 --> 00:10:20,819
la información dentro del formulario se codifica a un formato JSON

135
00:10:20,819 --> 00:10:24,409
y luego se envía al lado del servidor desde el lado del cliente.

136
00:10:24,409 --> 00:10:28,860
Entonces, eso se hará usando un mensaje POST o PUT.

137
00:10:28,860 --> 00:10:33,610
Mirando un poco más de detalles del mensaje de solicitud HTTP,

138
00:10:33,610 --> 00:10:38,134
el mensaje de solicitud típico en la línea de solicitud contendrá el Método,

139
00:10:38,134 --> 00:10:39,011
que es GET, PUT, PAUSE, DELETE

140
00:10:39,011 --> 00:10:43,455
o algunos de los otros verbos que ha visto anteriormente.

141
00:10:43,455 --> 00:10:48,360
Y luego, seguido de la URL y la versión del protocolo HTTP

142
00:10:48,360 --> 00:10:52,500
que está utilizando para comunicarse desde el cliente al servidor.

143
00:10:52,500 --> 00:10:57,120
El campo de encabezado suele contener un nombre de campo de encabezado, dos puntos,

144
00:10:57,120 --> 00:11:00,539
y el valor de ese campo de encabezado.

145
00:11:00,539 --> 00:11:08,100
Y el contenido del cuerpo, como mencioné, podría codificarse en formato JSON o XML.

146
00:11:08,100 --> 00:11:16,419
Aquí hay un ejemplo de un mensaje de solicitud HTTP típico

147
00:11:16,419 --> 00:11:19,294
que se puede enviar al servidor desde el cliente.

148
00:11:19,294 --> 00:11:23,169
Por lo tanto, en este mensaje de solicitud en particular, estamos pidiendo al servidor que conserve la página

149
00:11:23,169 --> 00:11:28,090
e index.hmtl desde el lado del servidor al lado del cliente para

150
00:11:28,090 --> 00:11:31,320
que se pueda representar en el navegador en el lado del cliente.

151
00:11:31,320 --> 00:11:37,029
Una solicitud como esta normalmente tendría un cuerpo vacío en el mensaje de solicitud.

152
00:11:37,029 --> 00:11:42,309
La mayor parte de la información se codificará en la línea de solicitud más los encabezados

153
00:11:42,309 --> 00:11:44,559
del mensaje de solicitud.

154
00:11:44,559 --> 00:11:49,179
Cuando el cliente envía la solicitud al servidor,

155
00:11:49,179 --> 00:11:55,355
el servidor procesará la solicitud y luego enviará una respuesta al lado del cliente.

156
00:11:55,355 --> 00:11:59,379
El mensaje de respuesta está organizado en, de nuevo, tres partes.

157
00:11:59,379 --> 00:12:05,679
Se almacena una línea de estado con cierta información sobre cómo se ha procesado la solicitud

158
00:12:05,679 --> 00:12:08,940
y qué se está enviando al cliente.

159
00:12:08,940 --> 00:12:16,149
Los encabezados contendrán detalles adicionales de lo que está contenido en el mensaje de respuesta,

160
00:12:16,149 --> 00:12:22,654
y luego seguido de una línea en blanco y, a continuación, el cuerpo real del mensaje.

161
00:12:22,654 --> 00:12:28,750
Un ejemplo de lo que normalmente estaría contenido en un mensaje de respuesta HTTP.

162
00:12:28,750 --> 00:12:32,766
En este caso, este mensaje de respuesta vuelve con un 200

163
00:12:32,766 --> 00:12:36,549
que es un código de estado del mensaje.

164
00:12:36,549 --> 00:12:40,644
Si ves aquí, 200 en la línea de solicitud como código de estado.

165
00:12:40,644 --> 00:12:43,360
Significa que su solicitud fue exitosa

166
00:12:43,360 --> 00:12:50,169
y el servidor puede devolver los datos que ha solicitado desde el lado del servidor.

167
00:12:50,169 --> 00:12:56,544
Y luego, el encabezado contendrá instrucciones adicionales al lado del cliente,

168
00:12:56,544 --> 00:13:02,735
incluyendo información sobre cómo se codifica el cuerpo real del mensaje.

169
00:13:02,735 --> 00:13:07,099
A continuación, el cuerpo puede contener, si ha solicitado la página HTML del índice,

170
00:13:07,099 --> 00:13:12,399
el cuerpo del mensaje contendrá el código HTML

171
00:13:12,399 --> 00:13:18,534
para la página HTML de inicio del índice como se ve en este ejemplo aquí.

172
00:13:18,534 --> 00:13:27,210
Una de las piezas de información en la línea de estado a la que me refiero como ese código de estado.

173
00:13:27,210 --> 00:13:31,304
Si el servidor es capaz de procesar su solicitud correctamente,

174
00:13:31,304 --> 00:13:34,990
enviará una respuesta con una puntuación de estado de 200,

175
00:13:34,990 --> 00:13:37,450
lo que significa que todo está bien en el lado del servidor,

176
00:13:37,450 --> 00:13:40,914
y el lado del servidor devuelve los datos correctamente.

177
00:13:40,914 --> 00:13:45,294
Si el servidor no puede procesar la solicitud por cualquier motivo,

178
00:13:45,294 --> 00:13:50,259
entonces esa información se codificará en el código de estado en

179
00:13:50,259 --> 00:13:53,309
esa línea de estado del mensaje de respuesta.

180
00:13:53,309 --> 00:13:56,950
Los diversos códigos de estado, típicamente, que encontrará

181
00:13:56,950 --> 00:13:59,210
cuando reciba una respuesta del lado del servidor,

182
00:13:59,210 --> 00:14:05,864
incluyen un 201 lo que significa que cuando intenta crear un objeto en el lado del servidor,

183
00:14:05,864 --> 00:14:11,230
se ha creado con éxito o un 301 lo que significa que lo que está solicitando

184
00:14:11,230 --> 00:14:13,750
tiene movido permanentemente a una nueva ubicación,

185
00:14:13,750 --> 00:14:17,889
y que se encuentra en la nueva ubicación de ese recurso

186
00:14:17,889 --> 00:14:20,205
será devuelto a su lado cliente.

187
00:14:20,205 --> 00:14:26,014
400 y 500 típicamente indican que hay algunos problemas en el lado del servidor.

188
00:14:26,014 --> 00:14:31,210
Un 404 es algo que a menudo se encuentra cuando solicita

189
00:14:31,210 --> 00:14:35,110
para algo que no existe en el lado del servidor.

190
00:14:35,110 --> 00:14:38,860
Del mismo modo, un 500 significa que el servidor está renunciando,

191
00:14:38,860 --> 00:14:43,620
no puede procesar su solicitud y luego envía un error interno del servidor.

192
00:14:43,620 --> 00:14:47,575
Estos son dos códigos de error comunes que encontrará.

193
00:14:47,575 --> 00:14:53,629
Los restantes tienen un significado específico como se enumeran en esta tabla aquí.

194
00:14:53,629 --> 00:14:57,625
Hay más que los códigos de estado que te di en esta tabla

195
00:14:57,625 --> 00:15:00,519
, pero estos son algunos de los códigos de estado más comunes

196
00:15:00,519 --> 00:15:06,220
que encontrarás en un mensaje de respuesta procedente del lado del servidor.

197
00:15:06,220 --> 00:15:13,044
Otro punto que mencioné es el hecho de que el servidor puede codificar los datos

198
00:15:13,044 --> 00:15:21,534
en un formato específico como XML o Extensible Markup Language o JSON, el JavaScript

199
00:15:21,534 --> 00:15:24,085
Object Notation para eso.

200
00:15:24,085 --> 00:15:28,690
Ahora, normalmente en este curso en particular vamos a tratar con los datos

201
00:15:28,690 --> 00:15:31,164
que están codificados principalmente en JSON.

202
00:15:31,164 --> 00:15:38,544
La mayoría de las aplicaciones, aplicaciones del lado del cliente incluyendo aplicaciones móviles en estos días,

203
00:15:38,544 --> 00:15:40,450
normalmente se comunican con el servidor

204
00:15:40,450 --> 00:15:49,240
y el formato de intercambio de datos es JSON por defecto en la mayoría de los casos.

205
00:15:49,240 --> 00:15:54,968
Esa es la razón por la que pasaré unos minutos explicándote sobre JSON.

206
00:15:54,968 --> 00:16:01,000
La notación de objeto javascript, o JSON, es un formato de intercambio de datos ligero.

207
00:16:01,000 --> 00:16:09,279
La razón por la que el formato de datos JSON es específicamente de interés para nosotros en este curso es

208
00:16:09,279 --> 00:16:13,955
porque la notación de objetos javascript, como su nombre lo indica,

209
00:16:13,955 --> 00:16:20,480
se asigna muy fácilmente a un objeto javascript que se utiliza con cualquiera de los códigos javascript.

210
00:16:20,480 --> 00:16:24,890
Entonces, convertir un objeto javascript en notación JSON,

211
00:16:24,890 --> 00:16:26,924
y viceversa, es muy sencillo.

212
00:16:26,924 --> 00:16:30,350
Esa notación JSON es una, lo que llamamos,

213
00:16:30,350 --> 00:16:35,045
como una notación autodescriptiva y muy fácil de entender.

214
00:16:35,045 --> 00:16:38,230
En el formato de notación de objeto javascript,

215
00:16:38,230 --> 00:16:44,335
los datos se estructuran de una manera especificada muy limpia.

216
00:16:44,335 --> 00:16:47,810
Esto se estructura como una colección de pares nombre/valor,

217
00:16:47,810 --> 00:16:52,855
y esto se estructura como una lista ordenada de valores.

218
00:16:52,855 --> 00:16:56,674
Puede ver un ejemplo de esto en el lado derecho aquí,

219
00:16:56,674 --> 00:17:03,980
en realidad hemos utilizado estos datos JSON con nuestra aplicación angular ya antes.

220
00:17:03,980 --> 00:17:08,809
Entonces, ahora ves por qué los datos están estructurados de esa manera.

221
00:17:08,809 --> 00:17:15,503
Y también te das cuenta de que es muy fácil poder lidiar con estos datos

222
00:17:15,503 --> 00:17:21,335
dentro de tu audio javascript, la mecanografía está atrapada en tu aplicación angular.

223
00:17:21,335 --> 00:17:27,484
Con esto completaré una breve descripción de los elementos esenciales de la red.

224
00:17:27,484 --> 00:17:33,109
Ahora vamos a pasar y hacer ejercicio donde vamos a configurar un servidor rudimentario

225
00:17:33,109 --> 00:17:39,080
que fue servir algunos datos a los que podemos conectar desde nuestra aplicación angular

226
00:17:39,080 --> 00:17:42,140
y luego intercambiar datos con un servidor.

227
00:17:42,140 --> 00:17:48,079
Ahora, vamos a desarrollar un servidor completo en uno de los cursos posteriores,

228
00:17:48,079 --> 00:17:52,400
el código de nodo JS y el curso de desarrollo del lado del servidor

229
00:17:52,400 --> 00:17:56,669
que vendría como un último curso en esta especialización.