1 00:00:01,270 --> 00:00:04,633 ‫-: Tudo bem, agora vamos trabalhar com streams. 2 00:00:06,140 --> 00:00:09,363 ‫E novamente, começando pela criação de um novo arquivo. 3 00:00:13,160 --> 00:00:16,370 ‫Tudo bem. Agora, digamos que por 4 00:00:16,370 --> 00:00:20,440 ‫algum motivo em nosso aplicativo, precisamos ler um grande arquivo de texto 5 00:00:20,440 --> 00:00:23,800 ‫do sistema de arquivos e, em seguida, enviá-lo ao cliente. 6 00:00:23,800 --> 00:00:25,640 ‫Então, como faríamos isso? 7 00:00:25,640 --> 00:00:28,650 ‫Bem, existem várias maneiras e vamos explorar algumas 8 00:00:28,650 --> 00:00:31,630 ‫delas, começando com a mais básica 9 00:00:31,630 --> 00:00:35,320 ‫e avançando até a melhor maneira de fazer isso. 10 00:00:35,320 --> 00:00:39,090 ‫Ok, então a primeira coisa é exigir o pacote 11 00:00:39,090 --> 00:00:43,220 ‫do sistema de arquivos como antes, e também o módulo HTTP. 12 00:00:46,810 --> 00:00:49,600 ‫Deixe-me mostrar um bom truque, então vamos 13 00:00:49,600 --> 00:00:52,183 ‫criar um servidor como este. 14 00:00:53,770 --> 00:00:58,770 ‫Portanto, exija o pacote HTTP e, a partir daqui, 15 00:00:59,530 --> 00:01:04,530 ‫podemos chamar createServer imediatamente. Então, assim. 16 00:01:05,550 --> 00:01:09,720 ‫Ok, então o resultado de requerer HTTP, é o 17 00:01:09,720 --> 00:01:13,700 ‫objeto HTTP e nele podemos então usar createServer. 18 00:01:13,700 --> 00:01:16,690 ‫Assim, e depois salve em uma variável. 19 00:01:16,690 --> 00:01:19,620 ‫Portanto, essa é mais uma maneira de criar um novo 20 00:01:19,620 --> 00:01:21,943 ‫servidor escrevendo um pouco menos de código. 21 00:01:24,530 --> 00:01:29,530 ‫Ok e assim como antes, vamos agora listar o evento 22 00:01:29,970 --> 00:01:34,970 ‫de solicitação e especificar nosso retorno de chamada aqui. 23 00:01:38,550 --> 00:01:41,190 ‫Portanto, a primeira solução que vamos usar 24 00:01:41,190 --> 00:01:43,600 ‫é a mais fácil e direta. 25 00:01:43,600 --> 00:01:46,690 ‫Que é simplesmente ler o arquivo em uma variável 26 00:01:46,690 --> 00:01:49,350 ‫e, uma vez feito isso, enviá-lo 27 00:01:49,350 --> 00:01:52,020 ‫ao cliente da maneira que já sabemos fazer. 28 00:01:52,020 --> 00:01:54,660 ‫Então esse é muito simples, e deixe-me escrever 29 00:01:54,660 --> 00:01:58,410 ‫um comentário aqui para isso. Portanto, solução um 30 00:01:58,410 --> 00:02:03,410 ‫e assim por diante. leiaFile e então nosso arquivo de teste novamente. 31 00:02:09,100 --> 00:02:12,720 ‫E então, quando estiver pronto, chamamos nossa função de retorno de 32 00:02:12,720 --> 00:02:15,270 ‫chamada na qual temos acesso aos dados. 33 00:02:15,270 --> 00:02:17,703 ‫Mas primeiro vamos lidar com o erro. 34 00:02:20,930 --> 00:02:24,880 ‫Assim, por exemplo, no caso de o arquivo não existir, 35 00:02:24,880 --> 00:02:28,250 ‫nesse caso, simplesmente registramos o erro no console. 36 00:02:28,250 --> 00:02:32,340 ‫Caso contrário, simplesmente enviamos esses dados de volta ao cliente. 37 00:02:32,340 --> 00:02:35,280 ‫Portanto, usamos o objeto de resposta exatamente como 38 00:02:35,280 --> 00:02:40,280 ‫fizemos antes, muitas vezes, e então. fim e os dados. 39 00:02:40,610 --> 00:02:44,010 ‫Então, salve, e essa é a primeira e 40 00:02:44,010 --> 00:02:46,363 ‫mais simples solução, certo? 41 00:02:47,450 --> 00:02:50,460 ‫Mas antes de podermos testar isso, precisamos 42 00:02:51,470 --> 00:02:55,433 ‫iniciar um servidor, certo? Então, usamos a escuta para fazer isso. 43 00:02:56,770 --> 00:03:01,603 ‫E a porta, a mesma de antes, então localhost e nossa função 44 00:03:03,440 --> 00:03:05,253 ‫de retorno de chamada. 45 00:03:12,960 --> 00:03:15,353 ‫Ok, então vamos ver se isso realmente funciona. 46 00:03:24,080 --> 00:03:27,880 ‫E claro que não, porque eu nem mesmo iniciei 47 00:03:27,880 --> 00:03:29,023 ‫o aplicativo. 48 00:03:31,260 --> 00:03:33,810 ‫Agora diz ouvir e agora vamos ver o 49 00:03:33,810 --> 00:03:34,853 ‫que acontece aqui. 50 00:03:35,730 --> 00:03:39,565 ‫E aqui vamos nós. Então esse arquivo é 51 00:03:39,565 --> 00:03:42,960 ‫enorme, tem Node. js é o melhor escrito 52 00:03:42,960 --> 00:03:46,080 ‫nele como 10.000 vezes ou algo assim, e por isso leva 53 00:03:46,080 --> 00:03:49,760 ‫muito tempo até que carregue completamente. E não estamos realmente interessados 54 00:03:49,760 --> 00:03:53,010 ‫em carregar tudo, então vamos parar com isso e 55 00:03:53,010 --> 00:03:56,430 ‫voltar ao nosso código. Então isso funciona muito bem, 56 00:03:56,430 --> 00:03:59,480 ‫a solução que temos aqui neste caso, mas o problema 57 00:03:59,480 --> 00:04:01,970 ‫é que com essa solução, o nó 58 00:04:01,970 --> 00:04:04,660 ‫realmente terá que carregar o arquivo inteiro na 59 00:04:04,660 --> 00:04:07,610 ‫memória, porque somente depois que estiver pronto, ele pode 60 00:04:07,610 --> 00:04:10,890 ‫enviar esses dados . Agora, isso é um problema quando 61 00:04:10,890 --> 00:04:14,120 ‫o arquivo é grande e também quando há uma tonelada de solicitações 62 00:04:14,120 --> 00:04:17,240 ‫chegando ao seu servidor. Como o processo 63 00:04:17,240 --> 00:04:21,464 ‫de nó ficará sem recursos muito rapidamente e seu aplicativo irá 64 00:04:21,464 --> 00:04:25,740 ‫parar de funcionar, tudo irá travar e seus usuários não ficarão 65 00:04:25,740 --> 00:04:28,940 ‫felizes, acredite em mim. Portanto, esta solução 66 00:04:28,940 --> 00:04:31,500 ‫aqui funciona quando estamos apenas criando algo 67 00:04:31,500 --> 00:04:33,990 ‫pequeno localmente apenas para nós, por exemplo. 68 00:04:33,990 --> 00:04:37,030 ‫Mas em um aplicativo pronto para produção, você não pode usar um 69 00:04:37,030 --> 00:04:41,270 ‫trecho de código como este. OK? Então, vamos prosseguir para 70 00:04:41,270 --> 00:04:44,070 ‫nossa segunda solução. E nessa 71 00:04:44,070 --> 00:04:46,933 ‫solução, vamos realmente usar streams. 72 00:04:48,760 --> 00:04:52,420 ‫Ok, então vamos comentar esta parte e 73 00:04:52,420 --> 00:04:55,890 ‫passar para a solução número dois. 74 00:04:55,890 --> 00:04:58,270 ‫E a ideia aqui é que 75 00:04:58,270 --> 00:05:03,000 ‫realmente não precisamos ler esses dados do arquivo em uma variável, certo? 76 00:05:03,000 --> 00:05:05,860 ‫Não precisamos dessa variável. Portanto, em vez de 77 00:05:05,860 --> 00:05:09,310 ‫ler os dados em uma variável e ter que armazenar 78 00:05:09,310 --> 00:05:12,710 ‫essa variável na memória, vamos apenas criar um fluxo legível. 79 00:05:12,710 --> 00:05:15,490 ‫Então, conforme recebemos cada bloco de dados, nós 80 00:05:15,490 --> 00:05:17,920 ‫os enviamos ao cliente como uma 81 00:05:17,920 --> 00:05:20,440 ‫resposta que é um fluxo gravável, lembre-se. 82 00:05:20,440 --> 00:05:22,963 ‫Deixe-me mostrar como podemos usar streams. 83 00:05:24,570 --> 00:05:28,823 ‫Portanto, criamos uma variável, vamos chamá-la de legível aqui e, a 84 00:05:30,025 --> 00:05:33,437 ‫partir do sistema de arquivos novamente, usamos createReadStream. 85 00:05:39,450 --> 00:05:44,450 ‫Então, isso é claro, pequeno. E agora o nome do arquivo 86 00:05:44,820 --> 00:05:49,820 ‫que estamos tentando ler. Então, isso é novamente, arquivo de teste. TXT. 87 00:05:50,580 --> 00:05:54,130 ‫Ok, perfeito. Isso agora cria um fluxo dos 88 00:05:54,130 --> 00:05:57,090 ‫dados que estão neste arquivo de texto, que podemos 89 00:05:57,090 --> 00:06:00,540 ‫consumir peça por peça. Então, pedaço por pedaço. 90 00:06:00,540 --> 00:06:03,350 ‫E como nós fazemos isso? Bem, lembre-se da 91 00:06:03,350 --> 00:06:06,600 ‫última aula, que cada vez que há um 92 00:06:06,600 --> 00:06:10,020 ‫novo dado que podemos consumir, um fluxo legível emite 93 00:06:10,020 --> 00:06:13,070 ‫o evento de dados. Ok, então podemos ouvir 94 00:06:13,070 --> 00:06:15,313 ‫isso, assim como aprendemos na palestra de eventos. 95 00:06:17,220 --> 00:06:22,220 ‫Tão legível. on, data e, em seguida, nossa função de retorno de chamada. 96 00:06:23,690 --> 00:06:26,910 ‫E em nossa função de retorno de chamada, temos acesso a 97 00:06:26,910 --> 00:06:28,993 ‫esses dados, portanto, a esse pedaço. 98 00:06:30,160 --> 00:06:32,660 ‫Deixe-me chamá-lo de chunk aqui em nossa 99 00:06:33,540 --> 00:06:37,100 ‫função de retorno de chamada e agora podemos lidar com esse dado. 100 00:06:37,100 --> 00:06:39,060 ‫E o que vamos fazer 101 00:06:39,060 --> 00:06:42,010 ‫com esse pedaço de dados, com esse pedaço, é 102 00:06:42,010 --> 00:06:45,210 ‫realmente gravá-lo em um fluxo gravável, que é a resposta. 103 00:06:45,210 --> 00:06:50,210 ‫Então, res. escrever, este pedaço. OK? 104 00:06:51,250 --> 00:06:54,080 ‫Portanto, lembre-se novamente de que essa resposta 105 00:06:54,080 --> 00:06:57,760 ‫é um fluxo gravável. Assim como mencionei 106 00:06:57,760 --> 00:07:01,540 ‫no vídeo anterior, certo? E agora podemos usar 107 00:07:01,540 --> 00:07:06,110 ‫o método write para enviar cada pedaço de dados para esse fluxo. 108 00:07:06,110 --> 00:07:08,920 ‫Ok, e com isso efetivamente estamos 109 00:07:08,920 --> 00:07:12,230 ‫transmitindo o conteúdo do arquivo direto para o cliente. 110 00:07:12,230 --> 00:07:14,300 ‫Ok, você entende a diferença? 111 00:07:14,300 --> 00:07:17,710 ‫Portanto, antes, escrevemos tudo de uma vez em uma variável e, 112 00:07:17,710 --> 00:07:21,000 ‫quando ela estava pronta, enviamos todos os dados de 113 00:07:21,000 --> 00:07:23,927 ‫volta para o cliente. Mas nessa 114 00:07:23,927 --> 00:07:26,370 ‫situação, com o riacho, é diferente. 115 00:07:26,370 --> 00:07:29,730 ‫Estamos efetivamente fazendo streaming do arquivo, então lemos 116 00:07:29,730 --> 00:07:32,670 ‫uma parte do arquivo e, assim que 117 00:07:32,670 --> 00:07:37,440 ‫estiver disponível, enviamos direto para o cliente, usando o método write do 118 00:07:37,440 --> 00:07:40,990 ‫fluxo de resposta. Então, quando a próxima 119 00:07:40,990 --> 00:07:44,290 ‫parte estiver disponível, essa parte será enviada, e todo o 120 00:07:44,290 --> 00:07:48,390 ‫caminho até que todo o arquivo seja lido e transmitido ao cliente. 121 00:07:48,390 --> 00:07:51,650 ‫Ok, agora só para terminar, também temos que lidar com 122 00:07:51,650 --> 00:07:54,680 ‫o evento quando todos os dados forem lidos. 123 00:07:54,680 --> 00:07:57,430 ‫Então, quando o fluxo basicamente terminar de ler os dados 124 00:07:57,430 --> 00:07:58,263 ‫do arquivo. 125 00:07:59,580 --> 00:08:03,113 ‫Nesse caso, o evento final será emitido 126 00:08:05,810 --> 00:08:10,040 ‫e, assim que isso acontecer, o que faremos é 127 00:08:10,040 --> 00:08:15,040 ‫fazer res. fim ok? E nós usamos 128 00:08:16,430 --> 00:08:21,220 ‫este antes, então encerrando a resposta, fizemos isso antes, certo? 129 00:08:21,220 --> 00:08:25,000 ‫E agora, na verdade, faz mais sentido, porque, novamente, 130 00:08:25,000 --> 00:08:28,540 ‫a resposta também é um fluxo e o método 131 00:08:28,540 --> 00:08:31,820 ‫final sinaliza que nenhum outro dado será gravado 132 00:08:31,820 --> 00:08:34,090 ‫neste fluxo gravável, certo? 133 00:08:34,090 --> 00:08:39,080 ‫Então aqui tudo o que fizemos foi usar res. terminar com os dados 134 00:08:39,080 --> 00:08:41,970 ‫nele. Então não fizemos streaming, 135 00:08:41,970 --> 00:08:44,490 ‫tudo o que fizemos foi enviar alguns dados. 136 00:08:44,490 --> 00:08:46,470 ‫Agora, neste caso, não estamos passando 137 00:08:46,470 --> 00:08:50,000 ‫nada para este método end, porque já enviamos todos os 138 00:08:50,000 --> 00:08:52,930 ‫dados usando res. escrever, pedaço por 139 00:08:52,930 --> 00:08:55,550 ‫pedaço, e então quando o fluxo legível terminar 140 00:08:55,550 --> 00:08:59,220 ‫de ler seu arquivo, tudo o que temos que fazer é 141 00:08:59,220 --> 00:09:03,330 ‫sinalizar que estamos prontos usando res. acabar assim, ok? 142 00:09:03,330 --> 00:09:07,910 ‫Portanto, sempre precisamos usar esses dados e esse evento final aqui, um 143 00:09:07,910 --> 00:09:11,160 ‫após o outro, assim. Caso contrário, 144 00:09:11,160 --> 00:09:14,030 ‫a resposta nunca será realmente 145 00:09:14,030 --> 00:09:17,340 ‫enviada ao cliente. Ok, então sem esta 146 00:09:17,340 --> 00:09:20,230 ‫peça aqui, toda a solução não funcionaria, ok? 147 00:09:20,230 --> 00:09:25,000 ‫Então, vamos fechar este aqui, começar de novo 148 00:09:25,000 --> 00:09:30,000 ‫e ler novamente, e você verá que está realmente 149 00:09:30,880 --> 00:09:35,670 ‫funcionando de novo, ok? Agora desta vez sem os problemas que 150 00:09:35,670 --> 00:09:39,400 ‫tivemos com a primeira solução. Vamos parar com isso aqui 151 00:09:39,400 --> 00:09:41,770 ‫e voltar ao nosso código, porque quero mostrar 152 00:09:41,770 --> 00:09:44,260 ‫a vocês agora que há outro evento que podemos 153 00:09:44,260 --> 00:09:47,403 ‫ouvir em um fluxo legível, que é o evento de erro. 154 00:09:49,240 --> 00:09:54,240 ‫Tão legível. on ('erro') e nesta função de retorno 155 00:09:55,000 --> 00:09:57,733 ‫de chamada, temos acesso ao objeto de erro. 156 00:09:58,810 --> 00:10:03,683 ‫Ok então neste caso iremos registrar este erro no console, 157 00:10:05,970 --> 00:10:10,593 ‫e então enviaremos o resultado do arquivo não encontrado. 158 00:10:14,400 --> 00:10:17,283 ‫E também podemos definir o código de status para um 159 00:10:20,160 --> 00:10:23,772 ‫erro, então 500, por exemplo. Normalmente, é definido automaticamente como 160 00:10:23,772 --> 00:10:28,020 ‫200, o que significa que está tudo bem, mas, neste caso, temos um erro de 161 00:10:28,020 --> 00:10:31,420 ‫servidor, o que significa que queremos enviar de volta o código 500. 162 00:10:31,420 --> 00:10:36,213 ‫Tudo bem, então vamos agora ... 163 00:10:37,390 --> 00:10:39,313 ‫Na verdade, preciso parar com isso novamente. 164 00:10:45,520 --> 00:10:46,970 ‫Então vamos ver o que acontece agora. 165 00:10:53,001 --> 00:10:54,870 ‫Ah, já temos um erro bem 166 00:10:54,870 --> 00:10:57,790 ‫aqui, res. o status não é uma função. E sim, 167 00:10:57,790 --> 00:11:00,872 ‫na verdade é statusCode. Portanto, esta é a 168 00:11:00,872 --> 00:11:05,100 ‫maneira que você escreve no expresso, então eu já estou acostumado a escrever 169 00:11:05,100 --> 00:11:10,100 ‫tanto no expresso, então expresso é um nó. js framework que vamos usar no 170 00:11:10,370 --> 00:11:12,150 ‫resto do curso e 171 00:11:12,150 --> 00:11:15,060 ‫expressamente você faz assim, então esse era 172 00:11:15,060 --> 00:11:18,420 ‫o problema. Então, já estou um pouco acostumado 173 00:11:18,420 --> 00:11:19,673 ‫a escrever expresso. 174 00:11:22,460 --> 00:11:26,470 ‫Vamos voltar e agora vemos o arquivo não encontrado, e se abrirmos 175 00:11:26,470 --> 00:11:31,090 ‫as ferramentas de desenvolvimento, você verá nosso código de erro 500 que acabamos de 176 00:11:31,090 --> 00:11:34,823 ‫enviar e, se formos para a guia da rede, vamos tentar 177 00:11:36,440 --> 00:11:39,840 ‫novamente, você tem o código de status aqui também. 178 00:11:39,840 --> 00:11:43,990 ‫Assim como vimos em um dos vídeos anteriores em outra 179 00:11:43,990 --> 00:11:47,130 ‫seção, na verdade. É assim que podemos 180 00:11:47,130 --> 00:11:49,343 ‫inspecionar esse tipo de coisa na guia rede. 181 00:11:52,530 --> 00:11:57,343 ‫Tudo bem, então vamos consertar aqui, salvá-lo, e tudo bem, 182 00:11:58,300 --> 00:12:03,300 ‫isso novamente funciona perfeitamente, mas ainda há um problema com 183 00:12:03,550 --> 00:12:06,240 ‫essa abordagem que acabei de mostrar 184 00:12:06,240 --> 00:12:09,360 ‫a vocês. E o problema 185 00:12:09,360 --> 00:12:12,240 ‫é que nosso fluxo legível, então aquele que 186 00:12:12,240 --> 00:12:16,100 ‫estamos usando para ler o arquivo do disco, é muito mais 187 00:12:16,100 --> 00:12:19,310 ‫rápido do que enviar o resultado com o fluxo 188 00:12:19,310 --> 00:12:22,910 ‫gravável de resposta pela rede. E isso sobrecarregará o fluxo 189 00:12:22,910 --> 00:12:27,360 ‫de resposta, que não pode lidar com todos esses dados recebidos tão rapidamente. 190 00:12:27,360 --> 00:12:29,920 ‫E esse problema é chamado de contrapressão. 191 00:12:29,920 --> 00:12:33,510 ‫E é um problema real que pode acontecer em situações reais. 192 00:12:33,510 --> 00:12:37,140 ‫Portanto, neste caso, a contrapressão ocorre quando a resposta 193 00:12:37,140 --> 00:12:41,130 ‫não consegue enviar os dados tão rápido quanto os está 194 00:12:41,130 --> 00:12:43,620 ‫recebendo do arquivo, isso faz sentido? 195 00:12:43,620 --> 00:12:46,050 ‫Portanto, temos que consertar essa 196 00:12:46,050 --> 00:12:48,793 ‫solução e encontrar uma ainda melhor. 197 00:12:50,130 --> 00:12:52,813 ‫E então, vamos criar a solução 198 00:12:55,120 --> 00:12:57,527 ‫três, e essa é realmente 199 00:12:57,527 --> 00:13:01,150 ‫a última, certo? Portanto, não há mais soluções do que três. 200 00:13:01,150 --> 00:13:05,000 ‫Então, o segredo aqui é realmente usar aquele operador de pipe 201 00:13:05,000 --> 00:13:07,405 ‫que mencionei no último vídeo, certo? 202 00:13:07,405 --> 00:13:12,405 ‫Portanto, o operador pipe está disponível em todos os streams legíveis e 203 00:13:12,960 --> 00:13:16,760 ‫nos permite canalizar a saída de um stream 204 00:13:16,760 --> 00:13:20,660 ‫legível diretamente para a entrada de um stream gravável, certo? 205 00:13:20,660 --> 00:13:24,010 ‫E isso resolverá o problema de contrapressão, porque 206 00:13:24,010 --> 00:13:27,340 ‫controlará automaticamente a velocidade basicamente dos dados 207 00:13:27,340 --> 00:13:31,260 ‫que entram e a velocidade dos dados que saem. 208 00:13:31,260 --> 00:13:35,603 ‫Ok, então vamos pegar nosso stream legível aqui. 209 00:13:38,290 --> 00:13:41,290 ‫Ok, então esse é nosso fluxo legível e 210 00:13:41,290 --> 00:13:45,253 ‫agora tudo o que temos a fazer é pegar nosso fluxo legível, 211 00:13:46,280 --> 00:13:50,650 ‫usar o método pipe nele e, em seguida, colocar um fluxo gravável e 212 00:13:50,650 --> 00:13:53,900 ‫essa é a resposta. E é isso mesmo. 213 00:13:53,900 --> 00:13:57,460 ‫É tudo o que precisamos fazer para essa solução, certo? 214 00:13:57,460 --> 00:13:59,960 ‫Então sempre funciona assim, deixe-me 215 00:13:59,960 --> 00:14:04,960 ‫escrever aqui como um comentário. Basicamente, precisamos de uma fonte legível, ok, 216 00:14:06,040 --> 00:14:09,310 ‫de novo, isso é apenas para explicar a você, 217 00:14:09,310 --> 00:14:12,330 ‫então podemos usar o pipe nela, e aqui teremos 218 00:14:12,330 --> 00:14:17,010 ‫que colocar um destino gravável. Portanto, é daí que 219 00:14:17,010 --> 00:14:19,980 ‫nossos dados vêm, e deve ser um 220 00:14:19,980 --> 00:14:24,980 ‫fluxo legível, e esses dados podemos canalizar para um destino gravável. 221 00:14:25,060 --> 00:14:29,520 ‫Então, neste caso, nosso destino é a resposta, certo? 222 00:14:29,520 --> 00:14:32,790 ‫Agora, este stream aqui pode ser um duplex ou um stream 223 00:14:32,790 --> 00:14:35,790 ‫de transformação também, mas o que importa é que 224 00:14:35,790 --> 00:14:38,930 ‫podemos escrever no stream. E a resposta, 225 00:14:38,930 --> 00:14:42,553 ‫claro, é esse fluxo. Portanto, podemos escrever para 226 00:14:42,553 --> 00:14:45,560 ‫a resposta que será enviada ao cliente, certo? 227 00:14:45,560 --> 00:14:48,890 ‫Assim, o operador de tubo resolve automaticamente o 228 00:14:48,890 --> 00:14:51,860 ‫problema de contrapressão que tínhamos anteriormente. 229 00:14:51,860 --> 00:14:54,720 ‫E também é uma solução muito mais 230 00:14:54,720 --> 00:14:58,000 ‫elegante e direta. Então, o que fizemos 231 00:14:58,000 --> 00:15:01,020 ‫aqui antes foi apenas mostrar a vocês todas as 232 00:15:01,020 --> 00:15:05,290 ‫maneiras pelas quais podemos usar os métodos e eventos de fluxo para criar 233 00:15:05,290 --> 00:15:08,520 ‫esse tipo de solução e, claro, eles têm muitos casos 234 00:15:08,520 --> 00:15:12,044 ‫de uso, mas em um problema como este, o tubo operador 235 00:15:12,044 --> 00:15:16,060 ‫é realmente a melhor solução. Nos bastidores, ele faz algo 236 00:15:16,060 --> 00:15:17,950 ‫assim aqui, na verdade, mas 237 00:15:17,950 --> 00:15:20,880 ‫novamente de uma maneira muito mais direta para 238 00:15:20,880 --> 00:15:23,000 ‫escrevermos, porque lida com todas as 239 00:15:23,000 --> 00:15:26,500 ‫coisas internamente nos bastidores. Portanto, acredito que o pipe 240 00:15:26,500 --> 00:15:30,370 ‫aqui seja na verdade a maneira mais fácil de consumir e 241 00:15:30,370 --> 00:15:33,410 ‫escrever streams, a menos que, claro, como mencionei, precisemos 242 00:15:33,410 --> 00:15:36,670 ‫de soluções mais customizadas. E então, temos 243 00:15:36,670 --> 00:15:39,910 ‫que usar essas ferramentas mais complicadas, como esses eventos 244 00:15:39,910 --> 00:15:43,633 ‫e métodos que mostrei antes. Tudo bem, então 245 00:15:45,270 --> 00:15:50,270 ‫para terminar, vamos encerrar o processo aqui, reiniciá-lo e, claro, 246 00:15:50,370 --> 00:15:54,350 ‫ver se ainda funciona, o que está funcionando. 247 00:15:54,350 --> 00:15:58,340 ‫E assim, nosso trabalho é feito aqui. Portanto, terminamos esta palestra e 248 00:15:58,340 --> 00:16:01,343 ‫estamos prontos para ir direto para a próxima.