1 00:00:01,270 --> 00:00:04,633 ‫- : Très bien, maintenant travaillons avec les flux. 2 00:00:06,140 --> 00:00:09,363 ‫Et encore, en commençant par créer un nouveau fichier. 3 00:00:13,160 --> 00:00:16,370 ‫D'accord. Disons maintenant que pour 4 00:00:16,370 --> 00:00:20,440 ‫une raison quelconque dans notre application, nous devons lire un gros fichier texte 5 00:00:20,440 --> 00:00:23,800 ‫à partir du système de fichiers, puis l'envoyer au client. 6 00:00:23,800 --> 00:00:25,640 ‫Alors, comment ferions-nous cela? 7 00:00:25,640 --> 00:00:28,650 ‫Eh bien, il existe plusieurs façons et nous allons 8 00:00:28,650 --> 00:00:31,630 ‫en explorer quelques-unes en commençant par la plus 9 00:00:31,630 --> 00:00:35,320 ‫basique et en allant jusqu'à la meilleure façon de le faire. 10 00:00:35,320 --> 00:00:39,090 ‫D'accord, la première chose à faire est d'exiger le package 11 00:00:39,090 --> 00:00:43,220 ‫du système de fichiers comme avant, ainsi que le module HTTP. 12 00:00:46,810 --> 00:00:49,600 ‫Permettez-moi maintenant de vous montrer une astuce intéressante, alors 13 00:00:49,600 --> 00:00:52,183 ‫créons en fait un serveur comme celui-ci. 14 00:00:53,770 --> 00:00:58,770 ‫Donc, exigez le package HTTP, puis à partir de là, 15 00:00:59,530 --> 00:01:04,530 ‫nous pouvons immédiatement appeler createServer. Alors juste comme ça. 16 00:01:05,550 --> 00:01:09,720 ‫D'accord, donc le résultat de l'exigence de HTTP est l'objet 17 00:01:09,720 --> 00:01:13,700 ‫HTTP et là-bas, nous pouvons ensuite utiliser createServer. 18 00:01:13,700 --> 00:01:16,690 ‫Juste comme ça, puis enregistrez-le dans une variable. 19 00:01:16,690 --> 00:01:19,620 ‫C'est donc une autre façon de créer un nouveau serveur en 20 00:01:19,620 --> 00:01:21,943 ‫écrivant encore un peu moins de code. 21 00:01:24,530 --> 00:01:29,530 ‫D'accord et comme avant, listons maintenant l'événement 22 00:01:29,970 --> 00:01:34,970 ‫de demande et spécifions notre rappel ici. 23 00:01:38,550 --> 00:01:41,190 ‫Ainsi, la première solution que nous allons utiliser est 24 00:01:41,190 --> 00:01:43,600 ‫la plus simple et la plus directe. 25 00:01:43,600 --> 00:01:46,690 ‫Ce qui consiste simplement à lire le fichier dans une variable, 26 00:01:46,690 --> 00:01:49,350 ‫puis une fois cela fait, à l'envoyer au 27 00:01:49,350 --> 00:01:52,020 ‫client de la manière dont nous savons déjà le faire. 28 00:01:52,020 --> 00:01:54,660 ‫Alors celui-là est très simple, et permettez-moi d'écrire 29 00:01:54,660 --> 00:01:58,410 ‫un commentaire ici pour cela. Donc solution 30 00:01:58,410 --> 00:02:03,410 ‫un, et donc fs. readFile puis à nouveau notre fichier de test. 31 00:02:09,100 --> 00:02:12,720 ‫Et puis une fois que c'est prêt, nous appelons notre fonction de 32 00:02:12,720 --> 00:02:15,270 ‫rappel dans laquelle nous avons accès aux données. 33 00:02:15,270 --> 00:02:17,703 ‫Mais gérons d'abord l'erreur. 34 00:02:20,930 --> 00:02:24,880 ‫Donc par exemple dans le cas où le fichier n'existe pas, et 35 00:02:24,880 --> 00:02:28,250 ‫dans ce cas on enregistre simplement l'erreur dans la console. 36 00:02:28,250 --> 00:02:32,340 ‫Mais sinon, nous renvoyons simplement ces données au client. 37 00:02:32,340 --> 00:02:35,280 ‫Nous utilisons donc l'objet de réponse comme nous l'avons 38 00:02:35,280 --> 00:02:40,280 ‫fait plusieurs fois auparavant, puis . fin et les données. 39 00:02:40,610 --> 00:02:44,010 ‫Alors, faites une sauvegarde, et c'est donc la première et la 40 00:02:44,010 --> 00:02:46,363 ‫plus simple des solutions, n'est-ce pas ? 41 00:02:47,450 --> 00:02:50,460 ‫Mais avant de pouvoir tester cela, nous devons également démarrer 42 00:02:51,470 --> 00:02:55,433 ‫un serveur, n'est-ce pas ? Nous utilisons donc listen pour le faire. 43 00:02:56,770 --> 00:03:01,603 ‫Et le port, le même qu'avant, puis localhost et notre 44 00:03:03,440 --> 00:03:05,253 ‫fonction de rappel. 45 00:03:12,960 --> 00:03:15,353 ‫Bon, voyons si cela fonctionne réellement. 46 00:03:24,080 --> 00:03:27,880 ‫Et bien sûr que non, car je n'ai même pas 47 00:03:27,880 --> 00:03:29,023 ‫lancé l'application. 48 00:03:31,260 --> 00:03:33,810 ‫Alors maintenant, il est dit d'écouter, et maintenant voyons ce 49 00:03:33,810 --> 00:03:34,853 ‫qui se passe ici. 50 00:03:35,730 --> 00:03:39,565 ‫Et c'est reparti. Donc ce fichier est énorme, 51 00:03:39,565 --> 00:03:42,960 ‫il a Node. js est le mieux écrit dedans, 52 00:03:42,960 --> 00:03:46,080 ‫environ 10000 fois ou quelque chose du genre, et il faut donc beaucoup 53 00:03:46,080 --> 00:03:49,760 ‫de temps jusqu'à ce qu'il se charge entièrement. Et nous ne sommes pas 54 00:03:49,760 --> 00:03:53,010 ‫vraiment intéressés à tout charger, alors arrêtons cela ici et 55 00:03:53,010 --> 00:03:56,430 ‫revenons à notre code. Cela fonctionne donc très bien, 56 00:03:56,430 --> 00:03:59,480 ‫la solution que nous avons ici dans ce cas, mais 57 00:03:59,480 --> 00:04:01,970 ‫le problème est qu'avec cette solution, le nœud 58 00:04:01,970 --> 00:04:04,660 ‫devra en fait charger l'intégralité du fichier en 59 00:04:04,660 --> 00:04:07,610 ‫mémoire, car ce n'est qu'une fois prêt qu'il pourra 60 00:04:07,610 --> 00:04:10,890 ‫envoyer ces données . Maintenant, c'est un problème lorsque le 61 00:04:10,890 --> 00:04:14,120 ‫fichier est volumineux, et aussi lorsqu'il y a une tonne de demandes 62 00:04:14,120 --> 00:04:17,240 ‫qui arrivent sur votre serveur. Parce que le 63 00:04:17,240 --> 00:04:21,464 ‫processus de nœud manquera très rapidement de ressources et que votre 64 00:04:21,464 --> 00:04:25,740 ‫application cessera de fonctionner, tout se bloquera et vos utilisateurs ne 65 00:04:25,740 --> 00:04:28,940 ‫seront pas satisfaits, croyez-moi. Donc, cette solution ici 66 00:04:28,940 --> 00:04:31,500 ‫fonctionne lorsque nous créons simplement quelque chose 67 00:04:31,500 --> 00:04:33,990 ‫de petit localement pour nous-mêmes, par exemple. 68 00:04:33,990 --> 00:04:37,030 ‫Mais dans une application prête pour la production, vous ne pouvez pas utiliser 69 00:04:37,030 --> 00:04:41,270 ‫un morceau de code comme celui-ci. D'accord? Passons donc à notre 70 00:04:41,270 --> 00:04:44,070 ‫deuxième solution. Et dans cette 71 00:04:44,070 --> 00:04:46,933 ‫solution, nous utiliserons en fait des flux. 72 00:04:48,760 --> 00:04:52,420 ‫D'accord, commentons cette partie et passons 73 00:04:52,420 --> 00:04:55,890 ‫à la solution numéro deux. 74 00:04:55,890 --> 00:04:58,270 ‫Et l'idée ici est que nous n'avons 75 00:04:58,270 --> 00:05:03,000 ‫pas vraiment besoin de lire ces données du fichier dans une variable, n'est-ce pas ? 76 00:05:03,000 --> 00:05:05,860 ‫Nous n'avons pas besoin de cette variable. Ainsi, au lieu de 77 00:05:05,860 --> 00:05:09,310 ‫lire les données dans une variable et de devoir stocker cette 78 00:05:09,310 --> 00:05:12,710 ‫variable en mémoire, nous allons simplement créer un flux lisible. 79 00:05:12,710 --> 00:05:15,490 ‫Ensuite, au fur et à mesure que nous recevons chaque bloc 80 00:05:15,490 --> 00:05:17,920 ‫de données, nous l'envoyons au client en tant 81 00:05:17,920 --> 00:05:20,440 ‫que réponse qui est un flux inscriptible à retenir. 82 00:05:20,440 --> 00:05:22,963 ‫Alors laissez-moi maintenant vous montrer comment nous pouvons utiliser les flux. 83 00:05:24,570 --> 00:05:28,823 ‫Nous créons donc une variable, appelons-la lisible ici, puis à partir 84 00:05:30,025 --> 00:05:33,437 ‫du système de fichiers à nouveau, nous utilisons 85 00:05:39,450 --> 00:05:44,450 ‫createReadStream Ensuite, bien sûr, petit. Et maintenant le nom du fichier que 86 00:05:44,820 --> 00:05:49,820 ‫nous essayons de lire. C'est donc encore une fois, test-file. SMS. 87 00:05:50,580 --> 00:05:54,130 ‫D'accord, parfait. Cela crée donc maintenant un flux à 88 00:05:54,130 --> 00:05:57,090 ‫partir des données qui se trouvent dans ce fichier texte, que nous 89 00:05:57,090 --> 00:06:00,540 ‫pouvons ensuite consommer pièce par pièce. Donc morceau par morceau. 90 00:06:00,540 --> 00:06:03,350 ‫Et comment fait-on ? Eh bien, rappelez-vous 91 00:06:03,350 --> 00:06:06,600 ‫de la dernière conférence, qu'à chaque fois qu'il y 92 00:06:06,600 --> 00:06:10,020 ‫a une nouvelle donnée que nous pouvons consommer, un flux 93 00:06:10,020 --> 00:06:13,070 ‫lisible émet l'événement de données. D'accord, et donc nous pouvons écouter 94 00:06:13,070 --> 00:06:15,313 ‫ça, comme nous l'avons appris dans la conférence sur les événements. 95 00:06:17,220 --> 00:06:22,220 ‫Tellement lisible. on, data, puis notre fonction de rappel. 96 00:06:23,690 --> 00:06:26,910 ‫Et dans notre fonction de rappel, nous avons accès à 97 00:06:26,910 --> 00:06:28,993 ‫cette donnée, donc à ce morceau. 98 00:06:30,160 --> 00:06:32,660 ‫Permettez-moi de l'appeler morceau ici dans notre 99 00:06:33,540 --> 00:06:37,100 ‫fonction de rappel et nous pouvons maintenant gérer cette donnée. 100 00:06:37,100 --> 00:06:39,060 ‫Et ce que nous allons 101 00:06:39,060 --> 00:06:42,010 ‫faire avec cette donnée, avec ce morceau, c'est en 102 00:06:42,010 --> 00:06:45,210 ‫fait l'écrire dans un flux inscriptible, qui est la réponse. 103 00:06:45,210 --> 00:06:50,210 ‫Donc, rés. écrire, ce morceau. D'accord? 104 00:06:51,250 --> 00:06:54,080 ‫Rappelez-vous donc encore une fois que cette réponse 105 00:06:54,080 --> 00:06:57,760 ‫est un flux inscriptible. Comme je l'ai mentionné dans 106 00:06:57,760 --> 00:07:01,540 ‫la vidéo précédente, n'est-ce pas ? Et nous pouvons maintenant 107 00:07:01,540 --> 00:07:06,110 ‫utiliser la méthode d'écriture pour envoyer chaque élément de données dans ce flux. 108 00:07:06,110 --> 00:07:08,920 ‫D'accord, et avec cela, nous diffusons 109 00:07:08,920 --> 00:07:12,230 ‫efficacement le contenu du fichier directement vers le client. 110 00:07:12,230 --> 00:07:14,300 ‫Bon, tu comprends la différence ? 111 00:07:14,300 --> 00:07:17,710 ‫Donc avant, nous écrivions tout d'un coup dans une variable, et 112 00:07:17,710 --> 00:07:21,000 ‫une fois que c'était prêt, nous renvoyions ensuite toute 113 00:07:21,000 --> 00:07:23,927 ‫cette donnée au client. Mais dans cette 114 00:07:23,927 --> 00:07:26,370 ‫situation, avec le stream, c'est différent. 115 00:07:26,370 --> 00:07:29,730 ‫Nous diffusons effectivement le fichier en continu, nous lisons 116 00:07:29,730 --> 00:07:32,670 ‫donc une partie du fichier et dès 117 00:07:32,670 --> 00:07:37,440 ‫qu'elle est disponible, nous l'envoyons directement au client, en utilisant la méthode d'écriture 118 00:07:37,440 --> 00:07:40,990 ‫du flux de réponse. Ensuite, lorsque la pièce 119 00:07:40,990 --> 00:07:44,290 ‫suivante est disponible, cette pièce sera envoyée, et tout le 120 00:07:44,290 --> 00:07:48,390 ‫chemin jusqu'à ce que l'intégralité du fichier soit lu et diffusé au client. 121 00:07:48,390 --> 00:07:51,650 ‫Bon, maintenant juste pour finir, nous devons également gérer 122 00:07:51,650 --> 00:07:54,680 ‫l'événement lorsque toutes les données sont lues. 123 00:07:54,680 --> 00:07:57,430 ‫Ainsi, lorsque le flux a essentiellement fini de lire les 124 00:07:57,430 --> 00:07:58,263 ‫données du fichier. 125 00:07:59,580 --> 00:08:03,113 ‫Donc, dans ce cas, l'événement de fin 126 00:08:05,810 --> 00:08:10,040 ‫sera émis, et dès que cela se produira, nous 127 00:08:10,040 --> 00:08:15,040 ‫allons faire res. fin, d'accord ? Et nous avons utilisé celui-ci 128 00:08:16,430 --> 00:08:21,220 ‫avant, donc appeler la fin de la réponse, nous l'avons fait avant, n'est-ce pas ? 129 00:08:21,220 --> 00:08:25,000 ‫Et maintenant, cela a en fait plus de sens, car encore 130 00:08:25,000 --> 00:08:28,540 ‫une fois, la réponse est également un flux, et la 131 00:08:28,540 --> 00:08:31,820 ‫méthode end signale qu'aucune autre donnée ne sera écrite 132 00:08:31,820 --> 00:08:34,090 ‫dans ce flux inscriptible, d'accord ? 133 00:08:34,090 --> 00:08:39,080 ‫Donc, ici, tout ce que nous avons fait était d'utiliser res. terminer avec les données 134 00:08:39,080 --> 00:08:41,970 ‫qu'il contient. Nous n'avons donc pas fait 135 00:08:41,970 --> 00:08:44,490 ‫de streaming, nous n'avons finalement fait qu'envoyer des données. 136 00:08:44,490 --> 00:08:46,470 ‫Maintenant, dans ce cas, nous ne transmettons 137 00:08:46,470 --> 00:08:50,000 ‫rien à cette méthode de fin, car nous avons déjà envoyé toutes les 138 00:08:50,000 --> 00:08:52,930 ‫données à l'aide de res. écrire, morceau par morceau, 139 00:08:52,930 --> 00:08:55,550 ‫et donc lorsque le flux lisible a fini de 140 00:08:55,550 --> 00:08:59,220 ‫lire son fichier, eh bien, tout ce que nous avons à faire est de 141 00:08:59,220 --> 00:09:03,330 ‫signaler que nous sommes prêts en utilisant res. finir comme ça, d'accord ? 142 00:09:03,330 --> 00:09:07,910 ‫Nous devons donc toujours utiliser ces données et cet événement final ici l'un 143 00:09:07,910 --> 00:09:11,160 ‫après l'autre comme ceci. Car sinon, 144 00:09:11,160 --> 00:09:14,030 ‫la réponse ne sera en fait jamais 145 00:09:14,030 --> 00:09:17,340 ‫vraiment envoyée au client. D'accord, donc sans cette pièce 146 00:09:17,340 --> 00:09:20,230 ‫ici, toute cette solution ne fonctionnerait pas vraiment, d'accord ? 147 00:09:20,230 --> 00:09:25,000 ‫Alors maintenant, fermez celui-ci, recommencez et relisez, 148 00:09:25,000 --> 00:09:30,000 ‫et vous verrez que cela fonctionne à 149 00:09:30,880 --> 00:09:35,670 ‫nouveau, d'accord ? Maintenant cette fois sans les problèmes que nous 150 00:09:35,670 --> 00:09:39,400 ‫avions avec la première solution. Arrêtons cela ici et revenons 151 00:09:39,400 --> 00:09:41,770 ‫à notre code, car je veux vous montrer 152 00:09:41,770 --> 00:09:44,260 ‫maintenant qu'il existe un autre événement que nous 153 00:09:44,260 --> 00:09:47,403 ‫pouvons écouter sur un flux lisible, qui est l'événement d'erreur. 154 00:09:49,240 --> 00:09:54,240 ‫Tellement lisible. on('error') et dans cette fonction de 155 00:09:55,000 --> 00:09:57,733 ‫rappel, nous avons accès à l'objet d'erreur. 156 00:09:58,810 --> 00:10:03,683 ‫Bon, dans ce cas, nous allons enregistrer cette erreur sur 157 00:10:05,970 --> 00:10:10,593 ‫la console, puis envoyer le résultat du fichier introuvable. 158 00:10:14,400 --> 00:10:17,283 ‫Et on peut aussi mettre le code d'état sur une 159 00:10:20,160 --> 00:10:23,772 ‫erreur, donc 500 par exemple. Donc, généralement, il est automatiquement défini 160 00:10:23,772 --> 00:10:28,020 ‫sur 200, ce qui signifie que d'accord, mais dans ce cas, nous avons une erreur 161 00:10:28,020 --> 00:10:31,420 ‫de serveur, ce qui signifie que nous voulons renvoyer le code 500. 162 00:10:31,420 --> 00:10:36,213 ‫Très bien, alors allons maintenant... 163 00:10:37,390 --> 00:10:39,313 ‫En fait, je dois à nouveau arrêter ça. 164 00:10:45,520 --> 00:10:46,970 ‫Voyons donc ce qui se passe maintenant. 165 00:10:53,001 --> 00:10:54,870 ‫Oh, nous avons déjà une erreur 166 00:10:54,870 --> 00:10:57,790 ‫ici, res. le statut n'est pas une fonction. Et oui, 167 00:10:57,790 --> 00:11:00,872 ‫en fait son statusCode. C'est donc ainsi 168 00:11:00,872 --> 00:11:05,100 ‫que vous l'écrivez dans express, donc je suis déjà habitué à écrire 169 00:11:05,100 --> 00:11:10,100 ‫tellement express, donc express est un nœud. js que nous allons utiliser dans le 170 00:11:10,370 --> 00:11:12,150 ‫reste du cours et dans 171 00:11:12,150 --> 00:11:15,060 ‫express vous le faites comme ça, et c'était 172 00:11:15,060 --> 00:11:18,420 ‫donc le problème. Je suis donc déjà un peu trop 173 00:11:18,420 --> 00:11:19,673 ‫habituée à écrire en express. 174 00:11:22,460 --> 00:11:26,470 ‫Alors revenons en arrière, et oui, maintenant nous voyons le fichier introuvable, et 175 00:11:26,470 --> 00:11:31,090 ‫si nous ouvrons les outils de développement, vous voyez notre code d'erreur 500 que nous 176 00:11:31,090 --> 00:11:34,823 ‫venons d'envoyer auparavant, et si nous allons dans notre onglet réseau, 177 00:11:36,440 --> 00:11:39,840 ‫essayons à nouveau, vous avez également le code d'état ici. 178 00:11:39,840 --> 00:11:43,990 ‫Donc, tout comme nous l'avons vu dans l'une des vidéos précédentes dans une 179 00:11:43,990 --> 00:11:47,130 ‫autre section en fait. Voici donc comment nous pouvons 180 00:11:47,130 --> 00:11:49,343 ‫inspecter ce genre de choses dans l'onglet réseau. 181 00:11:52,530 --> 00:11:57,343 ‫Très bien, réparons-le ici, sauvegardons-le, et d'accord, cela fonctionne à 182 00:11:58,300 --> 00:12:03,300 ‫nouveau parfaitement, mais il y a toujours un problème avec 183 00:12:03,550 --> 00:12:06,240 ‫cette approche que je viens de 184 00:12:06,240 --> 00:12:09,360 ‫vous montrer. Et le problème est 185 00:12:09,360 --> 00:12:12,240 ‫que notre flux lisible, donc celui que nous 186 00:12:12,240 --> 00:12:16,100 ‫utilisons pour lire le fichier à partir du disque, est beaucoup plus 187 00:12:16,100 --> 00:12:19,310 ‫rapide que d'envoyer le résultat avec le flux inscriptible 188 00:12:19,310 --> 00:12:22,910 ‫de réponse sur le réseau. Et cela submergera le flux 189 00:12:22,910 --> 00:12:27,360 ‫de réponse, qui ne peut pas gérer toutes ces données entrantes si rapidement. 190 00:12:27,360 --> 00:12:29,920 ‫Et ce problème s'appelle la contre-pression. 191 00:12:29,920 --> 00:12:33,510 ‫Et c'est un vrai problème qui peut arriver dans des situations réelles. 192 00:12:33,510 --> 00:12:37,140 ‫Donc, dans ce cas, la contre-pression se produit lorsque la réponse ne 193 00:12:37,140 --> 00:12:41,130 ‫peut pas envoyer les données presque aussi vite qu'elle les reçoit du fichier, 194 00:12:41,130 --> 00:12:43,620 ‫est-ce que cela a du sens ? 195 00:12:43,620 --> 00:12:46,050 ‫Nous devons donc corriger cette 196 00:12:46,050 --> 00:12:48,793 ‫solution et en trouver une encore meilleure. 197 00:12:50,130 --> 00:12:52,813 ‫Et donc, nous allons créer la solution 198 00:12:55,120 --> 00:12:57,527 ‫trois, et c'est en fait la 199 00:12:57,527 --> 00:13:01,150 ‫dernière, d'accord ? Donc pas plus de solutions que trois. 200 00:13:01,150 --> 00:13:05,000 ‫Donc le secret ici est d'utiliser cet opérateur de tuyau que j'ai 201 00:13:05,000 --> 00:13:07,405 ‫mentionné dans la dernière vidéo, d'accord ? 202 00:13:07,405 --> 00:13:12,405 ‫L'opérateur pipe est donc disponible sur tous les flux lisibles, et il 203 00:13:12,960 --> 00:13:16,760 ‫nous permet de diriger la sortie d'un flux 204 00:13:16,760 --> 00:13:20,660 ‫lisible directement dans l'entrée d'un flux inscriptible, d'accord ? 205 00:13:20,660 --> 00:13:24,010 ‫Et cela résoudra ensuite le problème de contre-pression 206 00:13:24,010 --> 00:13:27,340 ‫car il gérera automatiquement la vitesse 207 00:13:27,340 --> 00:13:31,260 ‫des données entrantes et la vitesse des données sortantes. 208 00:13:31,260 --> 00:13:35,603 ‫D'accord, obtenons en fait notre flux lisible ici. 209 00:13:38,290 --> 00:13:41,290 ‫D'accord, c'est donc notre flux lisible, et maintenant 210 00:13:41,290 --> 00:13:45,253 ‫tout ce que nous avons à faire est de prendre notre 211 00:13:46,280 --> 00:13:50,650 ‫flux lisible, d'utiliser la méthode pipe dessus, puis de mettre un flux inscriptible 212 00:13:50,650 --> 00:13:53,900 ‫et c'est la réponse. Et c'est en fait ça. 213 00:13:53,900 --> 00:13:57,460 ‫C'est tout ce que nous avons à faire pour cette solution, d'accord ? 214 00:13:57,460 --> 00:13:59,960 ‫Donc ça marche toujours comme ça, 215 00:13:59,960 --> 00:14:04,960 ‫laissez-moi l'écrire ici en commentaire. Nous avons donc besoin d'une source lisible en 216 00:14:06,040 --> 00:14:09,310 ‫gros, d'accord, encore une fois, c'est juste pour vous l'expliquer, 217 00:14:09,310 --> 00:14:12,330 ‫puis nous pouvons utiliser le tuyau dessus, et ici nous 218 00:14:12,330 --> 00:14:17,010 ‫devrons mettre une destination en écriture. C'est donc de là que proviennent 219 00:14:17,010 --> 00:14:19,980 ‫nos données, et il doit s'agir d'un flux 220 00:14:19,980 --> 00:14:24,980 ‫lisible, et nous pouvons ensuite diriger ces données vers une destination accessible en écriture. 221 00:14:25,060 --> 00:14:29,520 ‫Donc, dans ce cas, notre destination est la réponse, d'accord ? 222 00:14:29,520 --> 00:14:32,790 ‫Maintenant, ce flux ici peut également être un duplex ou un 223 00:14:32,790 --> 00:14:35,790 ‫flux de transformation, mais ce qui compte, c'est que nous 224 00:14:35,790 --> 00:14:38,930 ‫puissions écrire dans le flux. Et la réponse, bien 225 00:14:38,930 --> 00:14:42,553 ‫sûr, est un tel flux. Donc on peut bien sûr écrire 226 00:14:42,553 --> 00:14:45,560 ‫à la réponse qui sera envoyée au client, d'accord ? 227 00:14:45,560 --> 00:14:48,890 ‫Ainsi, l'opérateur de canalisation résout automatiquement le problème 228 00:14:48,890 --> 00:14:51,860 ‫de contre-pression que nous avions auparavant. 229 00:14:51,860 --> 00:14:54,720 ‫Et c'est aussi en fait une solution beaucoup 230 00:14:54,720 --> 00:14:58,000 ‫plus élégante et simple. Donc, ce que nous 231 00:14:58,000 --> 00:15:01,020 ‫avons fait ici auparavant était juste de vous montrer toutes 232 00:15:01,020 --> 00:15:05,290 ‫les manières dont nous pouvons utiliser les méthodes et les événements de flux afin 233 00:15:05,290 --> 00:15:08,520 ‫de créer ce type de solution et bien sûr, ils ont 234 00:15:08,520 --> 00:15:12,044 ‫de nombreux cas d'utilisation, mais dans un problème comme celui-ci, le tuyau 235 00:15:12,044 --> 00:15:16,060 ‫opérateur est en fait la meilleure solution. Dans les coulisses, il fait quelque 236 00:15:16,060 --> 00:15:17,950 ‫chose comme ça ici en fait, 237 00:15:17,950 --> 00:15:20,880 ‫mais encore une fois d'une manière beaucoup plus simple pour 238 00:15:20,880 --> 00:15:23,000 ‫nous d'écrire, car il gère tout en 239 00:15:23,000 --> 00:15:26,500 ‫interne dans les coulisses. Je pense donc que le pipe ici 240 00:15:26,500 --> 00:15:30,370 ‫est en fait le moyen le plus simple de consommer et d'écrire des flux, 241 00:15:30,370 --> 00:15:33,410 ‫à moins bien sûr, comme je l'ai mentionné, que nous ayons 242 00:15:33,410 --> 00:15:36,670 ‫besoin de solutions plus personnalisées. Et puis, nous devons 243 00:15:36,670 --> 00:15:39,910 ‫utiliser ces outils plus compliqués comme ces événements et méthodes 244 00:15:39,910 --> 00:15:43,633 ‫que je vous ai montrés auparavant. Très bien, donc 245 00:15:45,270 --> 00:15:50,270 ‫juste pour finir, quittons le processus ici, redémarrez-le, et bien sûr, voyons 246 00:15:50,370 --> 00:15:54,350 ‫si cela fonctionne toujours, ce qui est le cas. 247 00:15:54,350 --> 00:15:58,340 ‫Et donc, notre travail est fait ici. Nous avons donc terminé cette 248 00:15:58,340 --> 00:16:01,343 ‫conférence et prêts à passer directement à la suivante.