1
00:00:03,879 --> 00:00:07,577
Deixe-me começar dando a vocês uma rápida introdução

2
00:00:07,577 --> 00:00:11,705
10 minutos ao essencial da rede.

3
00:00:11,705 --> 00:00:18,769
Quanto mais eu ensino Inglês, mais eu percebo que apenas para usar suas características mais bonitas

4
00:00:18,769 --> 00:00:23,210
de angular você precisa ter uma compreensão de tantas diferentes Fins conectados

5
00:00:23,210 --> 00:00:27,165
antes de você pode sequer entender o que você está fazendo com angular.

6
00:00:27,165 --> 00:00:29,929
No momento em que você começar a perseguir cada uma dessas Fins,

7
00:00:29,929 --> 00:00:32,890
eles vão se tornar cursos inteiros por conta própria e muito em breve,

8
00:00:32,890 --> 00:00:37,539
Eu vou acabar ensinando todo seu currículo de ciência da computação para você.

9
00:00:37,539 --> 00:00:41,174
Mas dado o fato de que temos tempo limitado,

10
00:00:41,174 --> 00:00:43,554
Eu vou me concentrar em entregar-lhe o essencial

11
00:00:43,554 --> 00:00:48,344
que você precisa para entender cada um dos tópicos.

12
00:00:48,344 --> 00:00:53,383
Agora, o que cobrimos neste módulo específico exigirá

13
00:00:53,383 --> 00:00:57,829
pelo menos uma compreensão rudimentar de como a rede de computadores funciona

14
00:00:57,829 --> 00:01:01,310
antes de entendermos por que precisamos usar HTTP,

15
00:01:01,310 --> 00:01:03,587
por que nos comunicamos com um servidor.

16
00:01:03,587 --> 00:01:08,284
Qual é a razão para o atraso é que quando você está falando com um servidor,

17
00:01:08,284 --> 00:01:09,394
e assim por diante.

18
00:01:09,394 --> 00:01:14,111
E também, os vários protocolos que você precisa estar ciente

19
00:01:14,111 --> 00:01:17,420
antes mesmo de poder se comunicar com um servidor.

20
00:01:17,420 --> 00:01:20,239
Então, tendo tudo isso em mente,

21
00:01:20,239 --> 00:01:25,950
uma rápida introdução de 10 minutos ao essencial da rede.

22
00:01:25,950 --> 00:01:30,575
Começamos a perceber que as aplicações web não são mais autônomas.

23
00:01:30,575 --> 00:01:38,015
Eles sempre têm uma cotação unquote cloud back-end suportando sua aplicação web.

24
00:01:38,015 --> 00:01:40,370
Agora, hoje em dia tudo está na Nuvem.

25
00:01:40,370 --> 00:01:46,444
Em breve você estará na nuvem também, pelo menos na nuvem nove com um forro prateado.

26
00:01:46,444 --> 00:01:55,939
Mas dado que precisamos de um suporte Silverside para que nosso aplicativo angular funcione corretamente,

27
00:01:55,939 --> 00:01:58,615
lá você hospedaria o servidor.

28
00:01:58,615 --> 00:02:06,140
E hoje em dia hospedar o servidor é muito facilmente feito usando um

29
00:02:06,140 --> 00:02:09,619
dos serviços de infraestrutura baseados em nuvem.

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

31
00:02:15,860 --> 00:02:21,650
ou muitos outros que fornecem suporte de servidor baseado em nuvem

32
00:02:21,650 --> 00:02:26,574
que você pode aproveitar para fornecer suporte de servidor para seu aplicativo angular.

33
00:02:26,574 --> 00:02:32,363
Então, no lado do servidor, o que exatamente está disponível no lado do servidor?

34
00:02:32,363 --> 00:02:39,814
Normalmente, você tem um servidor front-end que está falando com seu aplicativo angular.

35
00:02:39,814 --> 00:02:45,349
Então, essa é a lógica do servidor e nos bastidores,

36
00:02:45,349 --> 00:02:52,790
a lógica do servidor está se comunicando com um armazenamento persistente como um banco de dados

37
00:02:52,790 --> 00:02:56,905
onde seus dados são armazenados e recuperados.

38
00:02:56,905 --> 00:03:01,069
Quando você entrar no mundo da rede, você será logo bombardeado

39
00:03:01,069 --> 00:03:04,264
com 304 pequenos acrônimos.

40
00:03:04,264 --> 00:03:08,930
Coisas que você pensou que sabia o que eram do inglês normal

41
00:03:08,930 --> 00:03:11,509
ou eles têm um significado completamente diferente

42
00:03:11,509 --> 00:03:15,610
ou propósito quando você os encontra no mundo da rede.

43
00:03:15,610 --> 00:03:17,764
Então, vamos examinar alguns deles.

44
00:03:17,764 --> 00:03:22,159
Então, no mundo da rede você ouvirá pessoas falando sobre o protocolo HTTP.

45
00:03:22,159 --> 00:03:26,379
O protocolo usado para comunicação entre o cliente e o servidor.

46
00:03:26,379 --> 00:03:29,000
Este é um protocolo de camada de aplicação

47
00:03:29,000 --> 00:03:34,409
que falaremos brevemente um pouco mais no resto desta palestra.

48
00:03:34,409 --> 00:03:41,004
O protocolo HTTP para que ele funcione precisa de um URL para ser fornecido a ele,

49
00:03:41,004 --> 00:03:42,955
o Uniform Resource Locator.

50
00:03:42,955 --> 00:03:51,095
Então, esta é uma cadeia de caracteres separados por barras com em cada dois-pontos TTP,

51
00:03:51,095 --> 00:03:55,694
em um https: anexado na frente dele.

52
00:03:55,694 --> 00:03:58,530
E eu tenho certeza que se você é usado a world wide web,

53
00:03:58,530 --> 00:04:02,655
você está bastante familiarizado com a aparência dos URLs.

54
00:04:02,655 --> 00:04:06,435
Agora, além disso, você vai ouvir as pessoas falando sobre JSON,

55
00:04:06,435 --> 00:04:11,607
não para seu amigo Jason, mas JavaScript Object Notation.

56
00:04:11,607 --> 00:04:19,026
Então, o JavaScript Object Notation é uma maneira de codificar dados que estão sendo enviados

57
00:04:19,026 --> 00:04:22,850
do lado do servidor para o lado do cliente ou vice-versa.

58
00:04:22,850 --> 00:04:26,038
E também, você ouvirá as pessoas falando sobre XML,

59
00:04:26,038 --> 00:04:30,574
ainda outra maneira de codificar dados enquanto ele está em transporte de trânsito

60
00:04:30,574 --> 00:04:33,240
entre o cliente e o site do servidor.

61
00:04:33,240 --> 00:04:41,584
Agora, e também você vai ouvir as pessoas falando sobre protocolos de nível superior chamados SOAP,

62
00:04:41,584 --> 00:04:46,550
não do tipo com que você toma banho, mas SOAP como um protocolo

63
00:04:46,550 --> 00:04:55,034
que permite a comunicação entre entidades de distribuição dentro da rede.

64
00:04:55,034 --> 00:04:59,449
E também, você vai ouvir as pessoas falando sobre REST, não algo

65
00:04:59,449 --> 00:05:02,479
que você tem muito passando por este curso em particular.

66
00:05:02,479 --> 00:05:06,057
REST ou uma Transferência de Estado Representacional.

67
00:05:06,057 --> 00:05:10,850
Terei uma palestra mais curta especificamente dedicada

68
00:05:10,850 --> 00:05:14,089
para REST um pouco mais tarde neste módulo.

69
00:05:14,089 --> 00:05:18,410
E no mundo HTTP, você vai ouvir as pessoas falando sobre GET,

70
00:05:18,410 --> 00:05:23,449
PUT, POST e DELETE, e você estaria se perguntando,

71
00:05:23,449 --> 00:05:25,235
o que todos eles significam?

72
00:05:25,235 --> 00:05:29,454
Vamos aprender um pouco sobre isso nesta palestra,

73
00:05:29,454 --> 00:05:34,459
e também a palestra sobre REST que você verá um pouco mais tarde.

74
00:05:34,459 --> 00:05:38,959
Uma coisa importante que você precisa entender quando você está se comunicando

75
00:05:38,959 --> 00:05:45,439
com um servidor é que a comunicação do servidor cliente causa quantidade inesperada

76
00:05:45,439 --> 00:05:48,350
de atrasos ou quantidade indeterminada de atraso

77
00:05:48,350 --> 00:05:54,454
enquanto os dados estão sendo obtidos ou carregados para o servidor a partir do lado do cliente.

78
00:05:54,454 --> 00:05:57,566
Então, o que significa que dentro de seu aplicativo cliente-servidor

79
00:05:57,566 --> 00:06:00,409
você precisa manter o usuário informado sobre o fato

80
00:06:00,409 --> 00:06:07,970
de que algo está acontecendo nos bastidores e ser capaz de lidar com os atrasos

81
00:06:07,970 --> 00:06:14,149
e possivelmente não ser capaz de obter os dados do lado do servidor.

82
00:06:14,149 --> 00:06:18,589
É bem possível que quando você tentou se conectar a um servidor,

83
00:06:18,589 --> 00:06:20,959
a conexão com o servidor pode falhar,

84
00:06:20,959 --> 00:06:27,224
o servidor pode retornar dados incorretos ou pode causar um erro na comunicação.

85
00:06:27,224 --> 00:06:31,129
Todos estes têm de ser tratados do lado do cliente de forma adequada para

86
00:06:31,129 --> 00:06:37,259
que o seu aplicativo ainda esteja funcionando mesmo na presença desses problemas.

87
00:06:37,259 --> 00:06:43,939
Entrando no protocolo de camada de aplicativo mais popular usado para comunicar

88
00:06:43,939 --> 00:06:48,569
entre o cliente e o servidor, o Hypertext Transfer Protocol

89
00:06:48,569 --> 00:06:51,785
, mas este é um protocolo de comunicação de servidor cliente.

90
00:06:51,785 --> 00:06:54,019
Agora, isso pode ou não fazer muito sentido para você

91
00:06:54,019 --> 00:06:58,250
a menos que você tenha antecedentes suficientes em rede, mas este é um protocolo

92
00:06:58,250 --> 00:07:04,189
que é usado para codificar as mensagens que você troca entre seu aplicativo cliente,

93
00:07:04,189 --> 00:07:08,416
que é uma aplicação angular neste caso, e um lado do servidor.

94
00:07:08,416 --> 00:07:14,300
Então, este protocolo HTTP permite que você recupere documentos baseados em hipertexto

95
00:07:14,300 --> 00:07:19,459
do lado do servidor cada vez mais a informação que está sendo baixada

96
00:07:19,459 --> 00:07:25,298
do lado do servidor é codificada em um dos formatos de codificação padrão como JSON ou XML.

97
00:07:25,298 --> 00:07:28,759
E, para poder falar com um servidor,

98
00:07:28,759 --> 00:07:35,270
você tem o apoio de várias ações HTTP,

99
00:07:35,270 --> 00:07:39,295
ou o que chamamos de verbos HTTP: o HEAD, GET, POST,

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

101
00:07:44,634 --> 00:07:51,069
Veremos em particular os verbos GET, PUT, POST e DELETE em mais detalhes

102
00:07:51,069 --> 00:07:57,654
quando examinarmos o protocolo API restante um pouco mais tarde.

103
00:07:57,654 --> 00:08:00,904
Como funciona o protocolo HTTP?

104
00:08:00,904 --> 00:08:08,487
No protocolo HTTP, você está enviando uma solicitação de seu aplicativo cliente para o servidor

105
00:08:08,487 --> 00:08:12,990
e isso é codificado na forma de uma mensagem de solicitação HTTP.

106
00:08:12,990 --> 00:08:18,767
A mensagem de solicitação normalmente carrega um URL na mensagem de solicitação indicando,

107
00:08:18,767 --> 00:08:22,279
o que é que você deseja com o lado do servidor para enviar para você

108
00:08:22,279 --> 00:08:24,920
e isso geralmente é uma mensagem GET

109
00:08:24,920 --> 00:08:29,805
se você deseja que os dados sejam baixados do site do servidor.

110
00:08:29,805 --> 00:08:35,404
E você também especificará com qual servidor específico você está se comunicando.

111
00:08:35,404 --> 00:08:39,320
Quando o servidor recebe sua solicitação, o servidor irá

112
00:08:39,320 --> 00:08:45,215
recuperar os dados de seu armazenamento de dados, normalmente um banco de dados no lado do servidor,

113
00:08:45,215 --> 00:08:49,160
e, em seguida, empacotar esses dados em um apropriado quatro volta,

114
00:08:49,160 --> 00:08:53,595
e enviar os dados de volta para você no lado do cliente.

115
00:08:53,595 --> 00:08:58,430
Se você estiver obtendo código HTML, CSS e javascript padrão do lado do servidor,

116
00:08:58,430 --> 00:09:00,746
então seu navegador é capaz de processar isso.

117
00:09:00,746 --> 00:09:05,705
De volta com aplicativos como angular, você está se conectando principalmente ao servidor

118
00:09:05,705 --> 00:09:12,919
e, em seguida, recuperando dados na forma de JSON ou XML na maioria das vezes.

119
00:09:12,919 --> 00:09:16,730
Exceto para o download inicial de todos os recursos

120
00:09:16,730 --> 00:09:22,259
necessários para que o aplicativo angular seja executado dentro do seu navegador.

121
00:09:22,259 --> 00:09:29,929
Então, como vimos anteriormente, o aplicativo HTTP requer que mensagens sejam enviadas

122
00:09:29,929 --> 00:09:31,954
entre o cliente e o servidor.

123
00:09:31,954 --> 00:09:36,524
Uma mensagem de solicitação normalmente enviada do cliente para o servidor,

124
00:09:36,524 --> 00:09:42,600
e a mensagem de solicitação consiste em uma linha de solicitação mais um monte de cabeçalhos

125
00:09:42,600 --> 00:09:47,309
onde você fornece informações adicionais para qualificar a solicitação.

126
00:09:47,309 --> 00:09:49,889
Vamos ver o uso de vários cabeçalhos

127
00:09:49,889 --> 00:09:53,129
e configurações nos cabeçalhos à medida que passamos por alguns

128
00:09:53,129 --> 00:09:56,634
dos exercícios neste módulo particular.

129
00:09:56,634 --> 00:09:59,159
A linha de solicitação e os cabeçalhos são separados

130
00:09:59,159 --> 00:10:04,500
do corpo da mensagem de solicitação por uma linha em branco.

131
00:10:04,500 --> 00:10:08,279
O corpo da mensagem pode conter dados adicionais especialmente

132
00:10:08,279 --> 00:10:11,754
se seus clientes estiverem enviando dados para o lado do servidor.

133
00:10:11,754 --> 00:10:13,769
Por exemplo, quando você envia um formulário,

134
00:10:13,769 --> 00:10:20,819
as informações dentro do formulário são codificadas para um formato JSON

135
00:10:20,819 --> 00:10:24,409
e, em seguida, enviadas para o lado do servidor do lado do cliente.

136
00:10:24,409 --> 00:10:28,860
Então, isso será feito usando um POST ou uma mensagem PUT.

137
00:10:28,860 --> 00:10:33,610
Olhando para um pouco mais de detalhes da mensagem de solicitação HTTP,

138
00:10:33,610 --> 00:10:38,134
a mensagem de solicitação típica na linha de solicitação conterá o Método,

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

140
00:10:39,011 --> 00:10:43,455
ou alguns dos outros verbos que você já viu anteriormente.

141
00:10:43,455 --> 00:10:48,360
E, em seguida, seguido pelo URL e a versão do protocolo HTTP

142
00:10:48,360 --> 00:10:52,500
que você está usando para se comunicar do cliente para o lado do servidor.

143
00:10:52,500 --> 00:10:57,120
O campo de cabeçalho geralmente contém um nome de campo de cabeçalho, dois pontos,

144
00:10:57,120 --> 00:11:00,539
e o valor para esse campo de cabeçalho.

145
00:11:00,539 --> 00:11:08,100
E o conteúdo do corpo, como mencionei, pode ser codificado em formato JSON ou XML.

146
00:11:08,100 --> 00:11:16,419
Aqui está um exemplo de uma típica mensagem de solicitação HTTP

147
00:11:16,419 --> 00:11:19,294
que pode ser enviada para o servidor a partir do cliente.

148
00:11:19,294 --> 00:11:23,169
Então, nesta mensagem de solicitação particular, estamos pedindo ao servidor para reter

149
00:11:23,169 --> 00:11:28,090
e index.hmtl página do lado do servidor para o lado do cliente para

150
00:11:28,090 --> 00:11:31,320
que ele pode ser renderizado no navegador no lado do cliente.

151
00:11:31,320 --> 00:11:37,029
Uma solicitação como esta normalmente teria um corpo vazio na mensagem de solicitação.

152
00:11:37,029 --> 00:11:42,309
A maioria das informações serão codificadas na linha de solicitação mais os cabeçalhos

153
00:11:42,309 --> 00:11:44,559
da mensagem de solicitação.

154
00:11:44,559 --> 00:11:49,179
Quando o cliente envia a solicitação para o servidor,

155
00:11:49,179 --> 00:11:55,355
o servidor processará a solicitação e, em seguida, enviará de volta uma resposta para o lado do cliente.

156
00:11:55,355 --> 00:11:59,379
A mensagem de resposta está organizada em, novamente, três partes.

157
00:11:59,379 --> 00:12:05,679
Uma linha de status com algumas informações sobre como a solicitação foi processada

158
00:12:05,679 --> 00:12:08,940
e o que está sendo enviado de volta para o cliente é armazenada.

159
00:12:08,940 --> 00:12:16,149
Os cabeçalhos conterão detalhes adicionais do que está contido na mensagem de resposta,

160
00:12:16,149 --> 00:12:22,654
e seguidos por uma linha em branco e, em seguida, o corpo real da mensagem.

161
00:12:22,654 --> 00:12:28,750
Um exemplo do que normalmente estaria contido em uma mensagem de resposta HTTP.

162
00:12:28,750 --> 00:12:32,766
Neste caso, esta mensagem de resposta está voltando com um 200

163
00:12:32,766 --> 00:12:36,549
que é um código de status da mensagem.

164
00:12:36,549 --> 00:12:40,644
Se você vir aqui, 200 na linha de solicitação como um código de status.

165
00:12:40,644 --> 00:12:43,360
Isso significa que sua solicitação foi bem-sucedida

166
00:12:43,360 --> 00:12:50,169
e o servidor é capaz de retornar os dados que você solicitou do lado do servidor.

167
00:12:50,169 --> 00:12:56,544
E, em seguida, o cabeçalho conterá direções adicionais para o lado do cliente,

168
00:12:56,544 --> 00:13:02,735
incluindo informações sobre como o corpo real da mensagem é codificado.

169
00:13:02,735 --> 00:13:07,099
Em seguida, o corpo pode conter, se você tiver solicitado a página HTML índice,

170
00:13:07,099 --> 00:13:12,399
o corpo da mensagem conterá o código HTML

171
00:13:12,399 --> 00:13:18,534
para a página HTML inicial do índice como você vê neste exemplo aqui.

172
00:13:18,534 --> 00:13:27,210
Uma das informações na linha de status a que me refiro como esse código de status.

173
00:13:27,210 --> 00:13:31,304
Se o servidor for capaz de processar seu pedido corretamente,

174
00:13:31,304 --> 00:13:34,990
ele enviará de volta uma resposta com uma pontuação de estado de 200,

175
00:13:34,990 --> 00:13:37,450
o que significa que tudo está bem no lado do servidor,

176
00:13:37,450 --> 00:13:40,914
e o lado do servidor está retornando os dados corretamente.

177
00:13:40,914 --> 00:13:45,294
Se o servidor não puder processar a solicitação por qualquer motivo,

178
00:13:45,294 --> 00:13:50,259
então essa informação será codificada no código de status em

179
00:13:50,259 --> 00:13:53,309
essa linha de status da mensagem de resposta.

180
00:13:53,309 --> 00:13:56,950
Os vários códigos de status, normalmente, que você encontrará

181
00:13:56,950 --> 00:13:59,210
quando você receber uma resposta do lado do servidor,

182
00:13:59,210 --> 00:14:05,864
incluem um 201, o que significa que quando você tenta criar um objeto no lado do servidor,

183
00:14:05,864 --> 00:14:11,230
ele foi criado com sucesso ou um 301 o que significa que o que você está solicitando

184
00:14:11,230 --> 00:14:13,750
tem movido permanentemente para um novo local,

185
00:14:13,750 --> 00:14:17,889
e que você está no novo local desse recurso

186
00:14:17,889 --> 00:14:20,205
será devolvido ao lado do cliente.

187
00:14:20,205 --> 00:14:26,014
400s e 500s normalmente indicam que existem alguns problemas no lado do servidor.

188
00:14:26,014 --> 00:14:31,210
A 404 é algo que você costuma encontrar quando você solicita

189
00:14:31,210 --> 00:14:35,110
para algo que não existe no lado do servidor.

190
00:14:35,110 --> 00:14:38,860
Da mesma forma, um 500 significa que o servidor está apenas desistindo,

191
00:14:38,860 --> 00:14:43,620
é incapaz de processar sua solicitação e, em seguida, envia de volta um erro interno do servidor.

192
00:14:43,620 --> 00:14:47,575
Estes são dois códigos de erro comuns que você encontrará.

193
00:14:47,575 --> 00:14:53,629
Os restantes têm um significado específico conforme listado nesta tabela aqui.

194
00:14:53,629 --> 00:14:57,625
Há mais do que os códigos de status que eu lhe dei nesta tabela

195
00:14:57,625 --> 00:15:00,519
, mas estes são alguns dos códigos de status mais comuns

196
00:15:00,519 --> 00:15:06,220
que você encontrará em uma mensagem de resposta vindo do lado do servidor.

197
00:15:06,220 --> 00:15:13,044
Outro ponto que mencionei é o fato de que o servidor pode codificar os dados

198
00:15:13,044 --> 00:15:21,534
em um formato específico como XML ou eXtensible Markup Language ou JSON, o JavaScript

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

200
00:15:24,085 --> 00:15:28,690
Agora, tipicamente neste curso em particular estaremos lidando com os dados

201
00:15:28,690 --> 00:15:31,164
que são codificados principalmente em JSON.

202
00:15:31,164 --> 00:15:38,544
A maioria dos aplicativos, aplicativos do lado do cliente incluindo aplicativos móveis atualmente,

203
00:15:38,544 --> 00:15:40,450
geralmente se comunicam com o servidor

204
00:15:40,450 --> 00:15:49,240
e o formato de troca de dados é JSON por padrão na maioria dos casos.

205
00:15:49,240 --> 00:15:54,968
Essa é a razão pela qual vou passar alguns minutos explicando para você sobre JSON.

206
00:15:54,968 --> 00:16:01,000
A notação de objeto javascript, ou JSON, é um formato leve de intercâmbio de dados.

207
00:16:01,000 --> 00:16:09,279
A razão pela qual o formato de dados JSON é especificamente de interesse para nós neste curso é

208
00:16:09,279 --> 00:16:13,955
porque a notação de objeto javascript, como o nome indica,

209
00:16:13,955 --> 00:16:20,480
facilmente mapeia em um objeto javascript que você usa com qualquer um dos códigos javascript.

210
00:16:20,480 --> 00:16:24,890
Então, converter um objeto javascript em notação JSON,

211
00:16:24,890 --> 00:16:26,924
e vice-versa, é muito simples.

212
00:16:26,924 --> 00:16:30,350
Essa notação JSON é uma, o que chamamos,

213
00:16:30,350 --> 00:16:35,045
como uma notação auto-descritiva e muito fácil de entender.

214
00:16:35,045 --> 00:16:38,230
No formato de notação de objeto javascript,

215
00:16:38,230 --> 00:16:44,335
os dados são estruturados de uma maneira especificada muito limpa.

216
00:16:44,335 --> 00:16:47,810
Esta é estruturada como uma coleção de pares nome/valor,

217
00:16:47,810 --> 00:16:52,855
e esta é estruturada como uma lista ordenada de valores.

218
00:16:52,855 --> 00:16:56,674
Você pode ver um exemplo disso no lado direito aqui,

219
00:16:56,674 --> 00:17:03,980
nós realmente usamos esses dados JSON com nossa aplicação angular já anteriormente.

220
00:17:03,980 --> 00:17:08,809
Então, agora você vê por que os dados são estruturados dessa maneira.

221
00:17:08,809 --> 00:17:15,503
E você também percebe que é muito fácil ser capaz de lidar com esses dados

222
00:17:15,503 --> 00:17:21,335
dentro de seu áudio javascript, typescript é pego em sua aplicação angular.

223
00:17:21,335 --> 00:17:27,484
Com isso, concluo uma rápida visão geral dos essenciais de rede.

224
00:17:27,484 --> 00:17:33,109
Agora vamos passar para e exercitar onde vamos configurar um servidor rudimentar

225
00:17:33,109 --> 00:17:39,080
que foi servir alguns dados que podemos nos conectar a partir da nossa aplicação angular

226
00:17:39,080 --> 00:17:42,140
e, em seguida, trocar dados com um servidor.

227
00:17:42,140 --> 00:17:48,079
Agora, vamos desenvolver um servidor de pleno direito em um dos cursos posteriores,

228
00:17:48,079 --> 00:17:52,400
o código de nó JS e curso de desenvolvimento do lado do servidor

229
00:17:52,400 --> 00:17:56,669
que viria como um último curso nesta especialização.