1
00:00:01,300 --> 00:00:03,370
‫Instrutor: Agora vamos dedicar um minuto para aprender sobre

2
00:00:03,370 --> 00:00:06,370
‫a natureza assíncrona do Node. js,

3
00:00:06,370 --> 00:00:09,510
‫que inclui tópicos absolutamente fundamentais,

4
00:00:09,510 --> 00:00:13,010
‫como código síncrono, assíncrono, bloqueador

5
00:00:13,010 --> 00:00:15,140
‫e não bloqueador.

6
00:00:15,140 --> 00:00:17,810
‫E tudo isso será muito importante

7
00:00:17,810 --> 00:00:21,090
‫para entender tudo o que está surgindo ao

8
00:00:21,090 --> 00:00:22,503
‫longo desta seção.

9
00:00:24,240 --> 00:00:27,620
‫Portanto, este trecho de código que escrevemos na última

10
00:00:27,620 --> 00:00:31,830
‫aula, para ler um arquivo e depois salvar seu conteúdo em uma

11
00:00:31,830 --> 00:00:34,400
‫variável, era de uma forma chamada síncrona,

12
00:00:34,400 --> 00:00:36,840
‫o que significa simplesmente que

13
00:00:36,840 --> 00:00:41,330
‫cada instrução é basicamente processada uma após a outra, linha por linha.

14
00:00:41,330 --> 00:00:42,540
‫Neste exemplo, primeiro,

15
00:00:42,540 --> 00:00:45,630
‫o módulo do sistema de arquivos é necessário,

16
00:00:45,630 --> 00:00:47,630
‫em seguida, o arquivo é

17
00:00:47,630 --> 00:00:50,900
‫lido e, em seguida, registramos o resultado no console.

18
00:00:50,900 --> 00:00:53,340
‫Então você vê que cada

19
00:00:53,340 --> 00:00:57,340
‫linha de código basicamente espera pelo resultado da linha anterior.

20
00:00:57,340 --> 00:00:59,440
‫Agora, isso pode se tornar um

21
00:00:59,440 --> 00:01:01,500
‫problema, especialmente com operações lentas,

22
00:01:01,500 --> 00:01:04,190
‫porque cada linha bloqueia a execução do

23
00:01:04,190 --> 00:01:05,710
‫resto do código.

24
00:01:05,710 --> 00:01:08,120
‫E assim, dizemos que o

25
00:01:08,120 --> 00:01:12,290
‫código síncrono também é chamado de código de bloqueio porque,

26
00:01:12,290 --> 00:01:15,080
‫novamente, uma determinada operação só pode ser

27
00:01:15,080 --> 00:01:17,740
‫executada após o término da anterior.

28
00:01:17,740 --> 00:01:20,850
‫E por causa da forma como Node. js foi projetado,

29
00:01:20,850 --> 00:01:24,220
‫isso se torna um grande problema, como veremos

30
00:01:24,220 --> 00:01:26,190
‫em detalhes no próximo slide.

31
00:01:26,190 --> 00:01:28,500
‫Portanto, a solução para esse

32
00:01:28,500 --> 00:01:32,160
‫problema no Node é usar código assíncrono e sem bloqueio.

33
00:01:32,160 --> 00:01:35,380
‫Portanto, no código assíncrono, carregamos um trabalho pesado

34
00:01:35,380 --> 00:01:38,470
‫para ser basicamente trabalhado em segundo plano.

35
00:01:38,470 --> 00:01:40,820
‫E então, uma vez que o trabalho

36
00:01:40,820 --> 00:01:43,370
‫esteja concluído, uma função de retorno de chamada que

37
00:01:43,370 --> 00:01:45,730
‫registramos antes é chamada para tratar o resultado.

38
00:01:45,730 --> 00:01:47,540
‫E durante todo esse

39
00:01:47,540 --> 00:01:50,380
‫tempo, o resto do código ainda pode ser

40
00:01:50,380 --> 00:01:52,910
‫executado sem ser bloqueado pela tarefa pesada,

41
00:01:52,910 --> 00:01:55,820
‫que agora está sendo executada em segundo plano.

42
00:01:55,820 --> 00:01:59,520
‫Então, o que isso significa é que podemos efetivamente

43
00:01:59,520 --> 00:02:01,620
‫adiar ou reagir no

44
00:02:01,620 --> 00:02:04,530
‫futuro a fim de tornar o código

45
00:02:04,530 --> 00:02:07,676
‫sem bloqueio e isso é, obviamente, muito melhor.

46
00:02:07,676 --> 00:02:09,287
‫Faz sentido?

47
00:02:09,287 --> 00:02:12,203
‫Portanto, neste exemplo, usamos a função

48
00:02:12,203 --> 00:02:16,390
‫readFile assíncrona, que aceita uma função de retorno de chamada.

49
00:02:16,390 --> 00:02:19,120
‫Isso iniciará a leitura do arquivo em

50
00:02:19,120 --> 00:02:22,360
‫segundo plano e, em seguida, passará imediatamente para a próxima

51
00:02:22,360 --> 00:02:25,830
‫instrução, imprimindo no console o arquivo de leitura de string.

52
00:02:25,830 --> 00:02:30,530
‫Então, novamente, você vê, não estamos bloqueando a execução aqui.

53
00:02:30,530 --> 00:02:33,860
‫Então, quando o arquivo finalmente for completamente lido, a

54
00:02:33,860 --> 00:02:35,870
‫função de retorno de

55
00:02:35,870 --> 00:02:38,100
‫chamada será chamada e, assim, os

56
00:02:38,100 --> 00:02:40,270
‫dados lidos serão impressos no console.

57
00:02:40,270 --> 00:02:41,890
‫Então isso é bem

58
00:02:41,890 --> 00:02:43,893
‫diferente da versão síncrona, não é?

59
00:02:44,870 --> 00:02:46,710
‫Agora, a questão aqui

60
00:02:46,710 --> 00:02:49,490
‫é: por que realmente tem que ser assim?

61
00:02:49,490 --> 00:02:53,940
‫Qual é o problema em bloquear a execução de código no Node. js?

62
00:02:53,940 --> 00:02:57,030
‫Ou, em outras palavras, por que realmente usamos callback tantas

63
00:02:57,030 --> 00:02:59,770
‫vezes no Node. js?

64
00:02:59,770 --> 00:03:01,523
‫Bem, vamos descobrir.

65
00:03:03,110 --> 00:03:05,930
‫E para entender essas questões, a primeira coisa

66
00:03:05,930 --> 00:03:08,220
‫que precisamos entender é o fato de

67
00:03:08,220 --> 00:03:11,260
‫que um Nodo. processo js, que

68
00:03:11,260 --> 00:03:13,760
‫é onde nosso aplicativo está sendo

69
00:03:13,760 --> 00:03:16,410
‫executado, há apenas um único thread.

70
00:03:16,410 --> 00:03:19,720
‫E o thread é como um conjunto de instruções que

71
00:03:19,720 --> 00:03:22,200
‫é executado na CPU do computador.

72
00:03:22,200 --> 00:03:25,200
‫Então, basicamente, o thread é onde

73
00:03:25,200 --> 00:03:29,270
‫nosso código é realmente executado no processador de uma máquina.

74
00:03:29,270 --> 00:03:33,120
‫Então, lembre-se, Node. js é basicamente single-threaded

75
00:03:33,120 --> 00:03:36,980
‫e, portanto, para cada aplicativo, há apenas um thread.

76
00:03:36,980 --> 00:03:40,300
‫É assim que Node. js foi projetado.

77
00:03:40,300 --> 00:03:43,050
‫Agora, o que isso significa é que

78
00:03:43,050 --> 00:03:46,960
‫todos os usuários que acessam seu aplicativo estão todos usando o

79
00:03:46,960 --> 00:03:50,040
‫mesmo thread, portanto, basicamente, acessando o mesmo thread.

80
00:03:50,040 --> 00:03:53,410
‫E assim, sempre que eles estiverem interagindo com o aplicativo,

81
00:03:53,410 --> 00:03:55,860
‫o código que é executado para

82
00:03:55,860 --> 00:03:59,810
‫cada usuário será executado todo no mesmo thread e no mesmo

83
00:03:59,810 --> 00:04:02,490
‫local no computador que executa o aplicativo.

84
00:04:02,490 --> 00:04:04,900
‫E isso é verdade, não importa

85
00:04:04,900 --> 00:04:09,900
‫se você tem cinco usuários, como neste diagrama, ou 5.000 ou 5 milhões.

86
00:04:10,610 --> 00:04:12,080
‫Tudo bem?

87
00:04:12,080 --> 00:04:15,310
‫Agora, o que isso também significa é que quando

88
00:04:15,310 --> 00:04:17,960
‫um usuário bloqueia o thread único com

89
00:04:17,960 --> 00:04:19,640
‫código síncrono, como acabamos

90
00:04:19,640 --> 00:04:22,280
‫de ver, todos os outros usuários terão

91
00:04:22,280 --> 00:04:24,680
‫que esperar que a execução termine.

92
00:04:24,680 --> 00:04:27,010
‫E isso pode não ser um

93
00:04:27,010 --> 00:04:29,800
‫grande problema se você tiver cinco usuários,

94
00:04:29,800 --> 00:04:33,350
‫mas definitivamente será para milhares ou até milhões de

95
00:04:33,350 --> 00:04:35,393
‫usuários ao mesmo tempo.

96
00:04:36,440 --> 00:04:39,830
‫Então, imagine que há um usuário acessando seu aplicativo

97
00:04:39,830 --> 00:04:43,280
‫e há um enorme arquivo síncrono lido em seu código

98
00:04:43,280 --> 00:04:46,630
‫que levará cerca de um segundo para carregar.

99
00:04:46,630 --> 00:04:49,920
‫Isso significará, é claro, que por aquele

100
00:04:49,920 --> 00:04:52,370
‫segundo, todos os outros usuários

101
00:04:52,370 --> 00:04:57,370
‫terão que esperar porque toda a execução é bloqueada naquele segundo.

102
00:04:57,490 --> 00:05:00,680
‫Portanto, se esses outros usuários quiserem fazer algumas tarefas

103
00:05:00,680 --> 00:05:02,940
‫simples, como efetuar login em

104
00:05:02,940 --> 00:05:06,900
‫seu aplicativo ou apenas solicitar alguns dados, eles não poderão fazê-lo.

105
00:05:06,900 --> 00:05:11,150
‫Eles terão que esperar até que a leitura do arquivo seja concluída.

106
00:05:11,150 --> 00:05:15,130
‫Somente quando isso acontecer, eles finalmente poderão realizar as tarefas

107
00:05:15,130 --> 00:05:18,113
‫mais simples, uma após a outra.

108
00:05:19,260 --> 00:05:23,290
‫Agora, observe que esta é uma versão muito simplificada do que realmente

109
00:05:23,290 --> 00:05:27,010
‫acontece nos bastidores do Node. js, é por

110
00:05:27,010 --> 00:05:29,880
‫isso que voltaremos a tudo isso

111
00:05:29,880 --> 00:05:33,760
‫na próxima seção e obteremos uma compreensão ainda mais

112
00:05:33,760 --> 00:05:38,090
‫profunda de como o Node. js lida com código assíncrono nos bastidores.

113
00:05:38,090 --> 00:05:39,370
‫Mas, neste ponto,

114
00:05:39,370 --> 00:05:42,170
‫isso é o suficiente para você entender o conceito.

115
00:05:42,170 --> 00:05:44,560
‫É melhor seguir passo a

116
00:05:44,560 --> 00:05:46,520
‫passo aqui e não

117
00:05:46,520 --> 00:05:49,220
‫confundir muito desde o início, ok?

118
00:05:49,220 --> 00:05:51,660
‫De qualquer forma, é assim que

119
00:05:51,660 --> 00:05:54,620
‫a situação aconteceria com o código de bloqueio

120
00:05:54,620 --> 00:05:58,460
‫síncrono, o que obviamente é uma experiência terrível para seus usuários.

121
00:05:58,460 --> 00:06:01,180
‫Portanto, é realmente seu trabalho como desenvolvedor

122
00:06:01,180 --> 00:06:03,260
‫evitar esses tipos de situações

123
00:06:03,260 --> 00:06:05,113
‫usando código assíncrono.

124
00:06:07,150 --> 00:06:10,180
‫Portanto, para a mesma situação, devemos, é claro, usar

125
00:06:10,180 --> 00:06:12,780
‫a função de leitura de arquivo assíncrona,

126
00:06:12,780 --> 00:06:15,190
‫que em vez de bloquear

127
00:06:15,190 --> 00:06:17,700
‫o thread único, faz o trabalho pesado

128
00:06:17,700 --> 00:06:20,170
‫em segundo plano, onde basicamente permanece até

129
00:06:20,170 --> 00:06:22,700
‫terminar de ler os dados do arquivo.

130
00:06:22,700 --> 00:06:25,950
‫Obviamente, também registramos uma função de retorno de

131
00:06:25,950 --> 00:06:29,490
‫chamada a ser chamada assim que os dados estiverem disponíveis.

132
00:06:29,490 --> 00:06:32,130
‫E, neste cenário, todos os outros usuários

133
00:06:32,130 --> 00:06:35,100
‫podem realizar suas tarefas em um único thread,

134
00:06:35,100 --> 00:06:38,710
‫um após o outro, enquanto o arquivo ainda está sendo

135
00:06:38,710 --> 00:06:40,390
‫lido em segundo plano.

136
00:06:40,390 --> 00:06:43,870
‫Agora, uma vez que os dados são lidos, nossa função de

137
00:06:43,870 --> 00:06:46,240
‫retorno de chamada, é claro, será

138
00:06:46,240 --> 00:06:51,240
‫chamada para ser executada no único thread principal a fim de processar os dados lidos.

139
00:06:51,380 --> 00:06:52,460
‫E é isso.

140
00:06:52,460 --> 00:06:54,720
‫Essa é uma visão geral de como o Node. js lida

141
00:06:54,720 --> 00:06:58,000
‫com o comportamento assíncrono para implementar o modelo

142
00:06:58,000 --> 00:07:00,850
‫de E / S sem bloqueio de

143
00:07:00,850 --> 00:07:03,670
‫que falamos na aula de introdução, certo?

144
00:07:03,670 --> 00:07:07,240
‫E I / O significa simplesmente entrada-saída, que é

145
00:07:07,240 --> 00:07:10,810
‫basicamente coisas como acessar o sistema de arquivos

146
00:07:10,810 --> 00:07:13,500
‫e lidar com solicitações de rede.

147
00:07:13,500 --> 00:07:16,470
‫Este é realmente o motivo pelo qual o Node. js é totalmente

148
00:07:16,470 --> 00:07:18,830
‫projetado em torno de retornos de chamada,

149
00:07:18,830 --> 00:07:21,190
‫como você verá ao longo do curso.

150
00:07:21,190 --> 00:07:24,090
‫Em outras linguagens de programação, como PHP, funciona

151
00:07:24,090 --> 00:07:27,260
‫de maneira muito diferente porque você obtém, basicamente, um

152
00:07:27,260 --> 00:07:29,640
‫novo thread para cada novo usuário,

153
00:07:29,640 --> 00:07:32,020
‫que é um paradigma completamente diferente

154
00:07:32,020 --> 00:07:34,600
‫e realmente funciona de forma completamente diferente.

155
00:07:34,600 --> 00:07:37,620
‫Mas o criador do Node. js descobriu que

156
00:07:37,620 --> 00:07:40,660
‫esse modelo é a melhor solução para construir aplicativos

157
00:07:40,660 --> 00:07:42,980
‫da web de alto desempenho e escalonáveis.

158
00:07:42,980 --> 00:07:46,810
‫Agora, apenas como uma nota final aqui, é importante

159
00:07:46,810 --> 00:07:48,830
‫saber que, quando usamos

160
00:07:48,830 --> 00:07:53,380
‫callbacks em nosso código, isso não o torna automaticamente assíncrono, certo?

161
00:07:53,380 --> 00:07:56,520
‫Portanto, passar funções para outras funções

162
00:07:56,520 --> 00:07:58,780
‫é bastante comum

163
00:07:58,780 --> 00:08:01,830
‫em JavaScript, mas é claro, novamente,

164
00:08:01,830 --> 00:08:05,110
‫isso não as torna assíncronas automaticamente, certo?

165
00:08:05,110 --> 00:08:09,150
‫Funciona dessa maneira apenas para algumas funções na API do Node,

166
00:08:09,150 --> 00:08:11,210
‫como a função readFile e

167
00:08:11,210 --> 00:08:14,823
‫muitas, muitas outras, conforme as pessoas explorarem no futuro.

168
00:08:16,610 --> 00:08:18,500
‫E agora, só para terminar,

169
00:08:18,500 --> 00:08:21,200
‫já que estamos falando de código assíncrono aqui,

170
00:08:21,200 --> 00:08:24,630
‫apenas uma última observação sobre funções de retorno de chamada.

171
00:08:24,630 --> 00:08:27,670
‫Portanto, esse modelo de retorno de chamada que acabamos

172
00:08:27,670 --> 00:08:29,370
‫de discutir, em que

173
00:08:29,370 --> 00:08:32,300
‫uma função é chamada assim que a anterior terminar

174
00:08:32,300 --> 00:08:36,970
‫seu trabalho, pode levar rapidamente a algum código difícil de ler e não gerenciável.

175
00:08:36,970 --> 00:08:39,830
‫Basta pegar este exemplo onde o segundo arquivo

176
00:08:39,830 --> 00:08:41,870
‫lido depende do primeiro,

177
00:08:41,870 --> 00:08:44,800
‫então, o terceiro arquivo lido depende do segundo

178
00:08:44,800 --> 00:08:47,560
‫e, finalmente, queremos usar os dados finais

179
00:08:47,560 --> 00:08:49,700
‫para escrever um arquivo como resultado.

180
00:08:49,700 --> 00:08:52,690
‫Isso parece muito confuso, certo?

181
00:08:52,690 --> 00:08:54,950
‫Quer dizer, vai funcionar muito

182
00:08:54,950 --> 00:08:57,330
‫bem, mas é difícil de raciocinar e

183
00:08:57,330 --> 00:09:00,110
‫isso ocorre apenas com quatro níveis de profundidade.

184
00:09:00,110 --> 00:09:02,980
‫Imagine que você tivesse cerca de 10 ou 20

185
00:09:02,980 --> 00:09:05,850
‫níveis, o que na verdade não é tão incomum.

186
00:09:05,850 --> 00:09:09,440
‫De qualquer forma, isso é o que chamamos de inferno de callback.

187
00:09:09,440 --> 00:09:11,370
‫É um problema tão

188
00:09:11,370 --> 00:09:13,780
‫comum que já tem nome próprio.

189
00:09:13,780 --> 00:09:16,920
‫E você percebe esta forma triangular aqui?

190
00:09:16,920 --> 00:09:20,840
‫Isso é um sinal muito claro de que você está no inferno com o retorno de chamada.

191
00:09:20,840 --> 00:09:24,350
‫Agora, como podemos realmente escapar do inferno de callback?

192
00:09:24,350 --> 00:09:27,600
‫Bem, podemos usar ferramentas mais avançadas para

193
00:09:27,600 --> 00:09:30,730
‫lidar com código assíncrono, como promessas

194
00:09:30,730 --> 00:09:34,150
‫ES6 ou ainda melhor, ES8 async / await.

195
00:09:34,150 --> 00:09:36,320
‫Agora, o modelo que acabamos de falar

196
00:09:36,320 --> 00:09:37,890
‫ainda será o mesmo.

197
00:09:37,890 --> 00:09:39,960
‫Nós apenas temos maneiras mais

198
00:09:39,960 --> 00:09:43,370
‫elegantes de lidar com o próprio código e escrevê-lo.

199
00:09:43,370 --> 00:09:45,830
‫E há toda uma seção opcional

200
00:09:45,830 --> 00:09:50,090
‫disso mais tarde no curso sobre promessas e também, assíncrono / aguardar,

201
00:09:50,090 --> 00:09:52,590
‫caso você não esteja familiarizado com eles.

202
00:09:52,590 --> 00:09:55,140
‫Mas, por enquanto, continuaremos usando callbacks porque

203
00:09:55,140 --> 00:09:57,900
‫é isso que o Node originalmente usava e

204
00:09:57,900 --> 00:10:00,100
‫foi projetado em torno disso.

205
00:10:00,100 --> 00:10:02,030
‫E agora, dito

206
00:10:02,030 --> 00:10:05,240
‫isso, vamos prosseguir e usar esse modelo assíncrono

207
00:10:05,240 --> 00:10:07,233
‫na prática pela primeira vez.