1 00:00:01,270 --> 00:00:04,633 ‫-: Okay, jetzt können wir tatsächlich mit Streams arbeiten. 2 00:00:06,140 --> 00:00:09,363 ‫Und wieder, beginnend mit dem Erstellen einer neuen Datei. 3 00:00:13,160 --> 00:00:16,370 ‫Gut. Nehmen wir nun an, 4 00:00:16,370 --> 00:00:20,440 ‫dass wir aus irgendeinem Grund in unserer Anwendung eine große Textdatei aus 5 00:00:20,440 --> 00:00:23,800 ‫dem Dateisystem lesen und dann an den Client senden müssen. 6 00:00:23,800 --> 00:00:25,640 ‫Also, wie würden wir das machen? 7 00:00:25,640 --> 00:00:28,650 ‫Nun, es gibt mehrere Möglichkeiten, und wir werden 8 00:00:28,650 --> 00:00:31,630 ‫einige davon untersuchen, beginnend mit der 9 00:00:31,630 --> 00:00:35,320 ‫einfachsten bis hin zur besten Methode, dies zu tun. 10 00:00:35,320 --> 00:00:39,090 ‫Okay, als erstes müssen Sie wie 11 00:00:39,090 --> 00:00:43,220 ‫zuvor das Dateisystempaket und auch das HTTP-Modul benötigen. 12 00:00:46,810 --> 00:00:49,600 ‫Lassen Sie mich Ihnen jetzt einen netten Trick zeigen, also 13 00:00:49,600 --> 00:00:52,183 ‫lassen Sie uns einen Server wie diesen erstellen. 14 00:00:53,770 --> 00:00:58,770 ‫Benötigen Sie also das HTTP-Paket, und von hier aus können 15 00:00:59,530 --> 00:01:04,530 ‫wir sofort createServer aufrufen. Also einfach so. 16 00:01:05,550 --> 00:01:09,720 ‫Okay, das Ergebnis der Anforderung von HTTP ist das 17 00:01:09,720 --> 00:01:13,700 ‫HTTP-Objekt und dort können wir dann createServer verwenden. 18 00:01:13,700 --> 00:01:16,690 ‫Einfach so und dann in einer Variablen speichern. 19 00:01:16,690 --> 00:01:19,620 ‫Das ist also eine weitere Möglichkeit, einen neuen Server 20 00:01:19,620 --> 00:01:21,943 ‫mit noch etwas weniger Code zu erstellen. 21 00:01:24,530 --> 00:01:29,530 ‫Okay und so, wie zuvor, listen wir jetzt das 22 00:01:29,970 --> 00:01:34,970 ‫Anfrageereignis auf und geben unseren Rückruf hier an. 23 00:01:38,550 --> 00:01:41,190 ‫Die erste Lösung, die wir verwenden werden, 24 00:01:41,190 --> 00:01:43,600 ‫ist also die einfachste und unkomplizierteste. 25 00:01:43,600 --> 00:01:46,690 ‫Das heißt, Sie lesen die Datei einfach in eine 26 00:01:46,690 --> 00:01:49,350 ‫Variable ein und senden sie dann an 27 00:01:49,350 --> 00:01:52,020 ‫den Client, so wie wir es bereits kennen. 28 00:01:52,020 --> 00:01:54,660 ‫Das ist also ganz einfach, und lassen Sie mich 29 00:01:54,660 --> 00:01:58,410 ‫dazu hier einen Kommentar schreiben. Also Lösung 30 00:01:58,410 --> 00:02:03,410 ‫eins und so fs. readFile dann wieder unsere Testdatei. 31 00:02:09,100 --> 00:02:12,720 ‫Und wenn das fertig ist, rufen wir unsere Callback-Funktion auf, in 32 00:02:12,720 --> 00:02:15,270 ‫der wir Zugriff auf die Daten haben. 33 00:02:15,270 --> 00:02:17,703 ‫Aber zuerst behandeln wir den Fehler. 34 00:02:20,930 --> 00:02:24,880 ‫Also zum Beispiel für den Fall, dass die Datei nicht existiert, und in 35 00:02:24,880 --> 00:02:28,250 ‫diesem Fall protokollieren wir den Fehler einfach in der Konsole. 36 00:02:28,250 --> 00:02:32,340 ‫Aber ansonsten senden wir diese Daten einfach an den Kunden zurück. 37 00:02:32,340 --> 00:02:35,280 ‫Also verwenden wir das Response-Objekt, wie wir es schon 38 00:02:35,280 --> 00:02:40,280 ‫oft getan haben, und dann . Ende und die Daten. 39 00:02:40,610 --> 00:02:44,010 ‫Also, speichern Sie es, und das ist die 40 00:02:44,010 --> 00:02:46,363 ‫erste und einfachste Lösung, oder? 41 00:02:47,450 --> 00:02:50,460 ‫Aber bevor wir das testen können, müssen wir eigentlich auch 42 00:02:51,470 --> 00:02:55,433 ‫noch einen Server starten, oder? Also verwenden wir zuhören, um das zu tun. 43 00:02:56,770 --> 00:03:01,603 ‫Und der Port, der gleiche wie zuvor, dann localhost 44 00:03:03,440 --> 00:03:05,253 ‫und unsere Callback-Funktion. 45 00:03:12,960 --> 00:03:15,353 ‫Okay, mal sehen, ob das wirklich funktioniert. 46 00:03:24,080 --> 00:03:27,880 ‫Und natürlich nicht, denn eigentlich habe ich die Bewerbung gar 47 00:03:27,880 --> 00:03:29,023 ‫nicht gestartet. 48 00:03:31,260 --> 00:03:33,810 ‫Jetzt heißt es also zuhören, und jetzt sehen wir, 49 00:03:33,810 --> 00:03:34,853 ‫was hier passiert. 50 00:03:35,730 --> 00:03:39,565 ‫Und es geht los. Diese Datei ist also riesig, 51 00:03:39,565 --> 00:03:42,960 ‫sie hat Node. js ist am besten darin 52 00:03:42,960 --> 00:03:46,080 ‫geschrieben, etwa 10000 Mal oder so, und daher dauert es 53 00:03:46,080 --> 00:03:49,760 ‫lange, bis es vollständig geladen ist. Und wir sind nicht wirklich daran 54 00:03:49,760 --> 00:03:53,010 ‫interessiert, alles zu laden, also stoppen wir hier und kehren Sie 55 00:03:53,010 --> 00:03:56,430 ‫zu unserem Code zurück. Das funktioniert also gut, die 56 00:03:56,430 --> 00:03:59,480 ‫Lösung, die wir hier in diesem Fall haben, aber das 57 00:03:59,480 --> 00:04:01,970 ‫Problem ist, dass der Knoten bei dieser Lösung 58 00:04:01,970 --> 00:04:04,660 ‫tatsächlich die gesamte Datei in den Speicher laden muss, 59 00:04:04,660 --> 00:04:07,610 ‫da er erst dann die Daten senden kann, wenn 60 00:04:07,610 --> 00:04:10,890 ‫er fertig ist . Dies ist ein Problem, 61 00:04:10,890 --> 00:04:14,120 ‫wenn die Datei groß ist und wenn viele Anfragen 62 00:04:14,120 --> 00:04:17,240 ‫Ihren Server erreichen. Da dem Knotenprozess 63 00:04:17,240 --> 00:04:21,464 ‫sehr schnell die Ressourcen ausgehen und Ihre App nicht mehr 64 00:04:21,464 --> 00:04:25,740 ‫funktioniert, stürzt alles ab und Ihre Benutzer werden nicht glücklich 65 00:04:25,740 --> 00:04:28,940 ‫sein, glauben Sie mir. Diese Lösung hier 66 00:04:28,940 --> 00:04:31,500 ‫funktioniert also, wenn wir beispielsweise nur für 67 00:04:31,500 --> 00:04:33,990 ‫uns selbst etwas Kleines lokal erstellen. 68 00:04:33,990 --> 00:04:37,030 ‫Aber in einer produktionsreifen Anwendung können Sie einen solchen 69 00:04:37,030 --> 00:04:41,270 ‫Code nicht verwenden. Okay? Kommen wir also zu 70 00:04:41,270 --> 00:04:44,070 ‫unserer zweiten Lösung. Und in 71 00:04:44,070 --> 00:04:46,933 ‫dieser Lösung werden wir tatsächlich Streams verwenden. 72 00:04:48,760 --> 00:04:52,420 ‫Okay, kommentieren wir diesen Teil und gehen 73 00:04:52,420 --> 00:04:55,890 ‫Sie zu Lösung Nummer zwei. 74 00:04:55,890 --> 00:04:58,270 ‫Und die Idee dabei ist, dass wir 75 00:04:58,270 --> 00:05:03,000 ‫diese Daten eigentlich nicht wirklich aus der Datei in eine Variable einlesen müssen, oder? 76 00:05:03,000 --> 00:05:05,860 ‫Wir brauchen diese Variable nicht. Anstatt also die 77 00:05:05,860 --> 00:05:09,310 ‫Daten in eine Variable einzulesen und diese Variable im 78 00:05:09,310 --> 00:05:12,710 ‫Speicher zu speichern, erstellen wir einfach einen lesbaren Stream. 79 00:05:12,710 --> 00:05:15,490 ‫Wenn wir dann jeden Datenblock erhalten, senden wir ihn 80 00:05:15,490 --> 00:05:17,920 ‫als Antwort an den Client, bei 81 00:05:17,920 --> 00:05:20,440 ‫der es sich um einen beschreibbaren Stream handelt. 82 00:05:20,440 --> 00:05:22,963 ‫Lassen Sie mich Ihnen nun zeigen, wie wir Streams verwenden können. 83 00:05:24,570 --> 00:05:28,823 ‫Also erstellen wir eine Variable, nennen wir sie hier lesbar, 84 00:05:30,025 --> 00:05:33,437 ‫und dann wieder aus dem Dateisystem, verwenden wir 85 00:05:39,450 --> 00:05:44,450 ‫createReadStream Dann das natürlich klein. Und jetzt der Name der Datei, die 86 00:05:44,820 --> 00:05:49,820 ‫wir zu lesen versuchen. Das ist also wieder Testdatei. TXT. 87 00:05:50,580 --> 00:05:54,130 ‫Okay, perfekt. Dadurch wird nun aus den Daten, die 88 00:05:54,130 --> 00:05:57,090 ‫sich in dieser Textdatei befinden, ein Stream erstellt, den wir dann 89 00:05:57,090 --> 00:06:00,540 ‫Stück für Stück konsumieren können. Also Stück für Stück. 90 00:06:00,540 --> 00:06:03,350 ‫Und wie machen wir das? Nun, erinnern Sie 91 00:06:03,350 --> 00:06:06,600 ‫sich aus der letzten Vorlesung, dass jedes Mal, wenn 92 00:06:06,600 --> 00:06:10,020 ‫wir ein neues Stück Daten konsumieren können, ein lesbarer 93 00:06:10,020 --> 00:06:13,070 ‫Stream das Datenereignis ausgibt. Okay, und damit können wir uns 94 00:06:13,070 --> 00:06:15,313 ‫das anhören, so wie wir es in der Veranstaltungsvorlesung gelernt haben. 95 00:06:17,220 --> 00:06:22,220 ‫Also lesbar. on, data und dann unsere Callback-Funktion. 96 00:06:23,690 --> 00:06:26,910 ‫Und in unserer Callback-Funktion haben wir Zugriff auf diese 97 00:06:26,910 --> 00:06:28,993 ‫Daten, also auf diesen Chunk. 98 00:06:30,160 --> 00:06:32,660 ‫Lassen Sie es mich hier in unserer 99 00:06:33,540 --> 00:06:37,100 ‫Callback-Funktion Chunk nennen, damit wir jetzt mit diesem Datenstück umgehen können. 100 00:06:37,100 --> 00:06:39,060 ‫Und was wir mit diesem 101 00:06:39,060 --> 00:06:42,010 ‫Datenstück, mit diesem Chunk, tun werden, ist, es tatsächlich 102 00:06:42,010 --> 00:06:45,210 ‫in einen beschreibbaren Stream zu schreiben, was die Antwort ist. 103 00:06:45,210 --> 00:06:50,210 ‫Also, res. schreiben, dieser Brocken. Okay? 104 00:06:51,250 --> 00:06:54,080 ‫Denken Sie also noch einmal daran, dass diese 105 00:06:54,080 --> 00:06:57,760 ‫Antwort ein beschreibbarer Stream ist. Also genau wie ich 106 00:06:57,760 --> 00:07:01,540 ‫im vorherigen Video erwähnt habe, oder? Und so können wir jetzt 107 00:07:01,540 --> 00:07:06,110 ‫die Methode write verwenden, um jedes einzelne Datenelement in diesen Stream zu senden. 108 00:07:06,110 --> 00:07:08,920 ‫Okay, und damit streamen wir effektiv 109 00:07:08,920 --> 00:07:12,230 ‫den Inhalt aus der Datei direkt an den Client. 110 00:07:12,230 --> 00:07:14,300 ‫Okay, verstehst du den Unterschied? 111 00:07:14,300 --> 00:07:17,710 ‫Zuvor schreiben wir also alles auf einmal in eine Variable, und 112 00:07:17,710 --> 00:07:21,000 ‫sobald diese fertig war, haben wir die gesamten Daten 113 00:07:21,000 --> 00:07:23,927 ‫an den Client zurückgesendet. Aber in dieser 114 00:07:23,927 --> 00:07:26,370 ‫Situation mit dem Stream ist das anders. 115 00:07:26,370 --> 00:07:29,730 ‫Wir streamen die Datei effektiv, also lesen wir 116 00:07:29,730 --> 00:07:32,670 ‫einen Teil der Datei, und sobald dieser 117 00:07:32,670 --> 00:07:37,440 ‫verfügbar ist, senden wir ihn mit der Schreibmethode des Antwortstreams direkt 118 00:07:37,440 --> 00:07:40,990 ‫an den Client. Wenn dann das nächste 119 00:07:40,990 --> 00:07:44,290 ‫Stück verfügbar ist, wird dieses Stück gesendet, und zwar so 120 00:07:44,290 --> 00:07:48,390 ‫lange, bis die gesamte Datei gelesen und an den Client gestreamt wurde. 121 00:07:48,390 --> 00:07:51,650 ‫Okay, zum Schluss müssen wir noch das Ereignis 122 00:07:51,650 --> 00:07:54,680 ‫verarbeiten, wenn alle Daten gelesen wurden. 123 00:07:54,680 --> 00:07:57,430 ‫Also, wenn der Stream im Grunde fertig ist, die Daten aus der 124 00:07:57,430 --> 00:07:58,263 ‫Datei zu lesen. 125 00:07:59,580 --> 00:08:03,113 ‫In diesem Fall wird also das 126 00:08:05,810 --> 00:08:10,040 ‫Endereignis ausgegeben, und sobald das passiert, werden wir 127 00:08:10,040 --> 00:08:15,040 ‫res tun. Ende, okay? Und wir haben diesen hier 128 00:08:16,430 --> 00:08:21,220 ‫schon einmal verwendet, also haben wir bei der Antwort Ende aufgerufen, das haben wir schon einmal gemacht, oder? 129 00:08:21,220 --> 00:08:25,000 ‫Und jetzt macht es tatsächlich mehr Sinn, denn die 130 00:08:25,000 --> 00:08:28,540 ‫Antwort ist auch wieder ein Stream, und die Endmethode 131 00:08:28,540 --> 00:08:31,820 ‫signalisiert, dass keine Daten mehr in diesen beschreibbaren 132 00:08:31,820 --> 00:08:34,090 ‫Stream geschrieben werden, okay? 133 00:08:34,090 --> 00:08:39,080 ‫Also hier oben haben wir nur res verwendet. mit den darin enthaltenen 134 00:08:39,080 --> 00:08:41,970 ‫Daten enden. Wir haben also kein Streaming 135 00:08:41,970 --> 00:08:44,490 ‫gemacht, sondern am Ende nur ein paar Daten gesendet. 136 00:08:44,490 --> 00:08:46,470 ‫In diesem Fall übergeben wir 137 00:08:46,470 --> 00:08:50,000 ‫nichts an diese end-Methode, da wir bereits alle Daten mit 138 00:08:50,000 --> 00:08:52,930 ‫res gesendet haben. write, Stück für 139 00:08:52,930 --> 00:08:55,550 ‫Stück, und wenn der lesbare Stream damit 140 00:08:55,550 --> 00:08:59,220 ‫fertig ist, seine Datei zu lesen, müssen wir nur noch signalisieren, 141 00:08:59,220 --> 00:09:03,330 ‫dass wir mit res bereit sind. Ende so, okay? 142 00:09:03,330 --> 00:09:07,910 ‫Wir müssen diese Daten und dieses Endereignis also immer hier 143 00:09:07,910 --> 00:09:11,160 ‫nacheinander so verwenden. Denn sonst 144 00:09:11,160 --> 00:09:14,030 ‫wird die Antwort eigentlich nie wirklich 145 00:09:14,030 --> 00:09:17,340 ‫an den Client gesendet. Okay, also ohne dieses Stück 146 00:09:17,340 --> 00:09:20,230 ‫hier würde diese gesamte Lösung nicht wirklich funktionieren, okay? 147 00:09:20,230 --> 00:09:25,000 ‫Also lass uns jetzt dieses schließen, neu beginnen 148 00:09:25,000 --> 00:09:30,000 ‫und noch einmal lesen, und damit du siehst, dass es 149 00:09:30,880 --> 00:09:35,670 ‫tatsächlich wieder funktioniert, okay? Jetzt diesmal ohne die Probleme, die wir 150 00:09:35,670 --> 00:09:39,400 ‫mit der ersten Lösung hatten. Lassen Sie uns dies hier beenden 151 00:09:39,400 --> 00:09:41,770 ‫und zu unserem Code zurückkehren, denn ich möchte 152 00:09:41,770 --> 00:09:44,260 ‫Ihnen jetzt zeigen, dass es ein weiteres Ereignis gibt, 153 00:09:44,260 --> 00:09:47,403 ‫das wir in einem lesbaren Stream anhören können, nämlich das Fehlerereignis. 154 00:09:49,240 --> 00:09:54,240 ‫Also lesbar. on('error') und in dieser Callback-Funktion 155 00:09:55,000 --> 00:09:57,733 ‫haben wir Zugriff auf das Fehlerobjekt. 156 00:09:58,810 --> 00:10:03,683 ‫Okay, in diesem Fall werden wir diesen Fehler in der Konsole 157 00:10:05,970 --> 00:10:10,593 ‫protokollieren und dann das Ergebnis der Datei nicht gefunden senden. 158 00:10:14,400 --> 00:10:17,283 ‫Und wir können den Statuscode auch auf einen Fehler 159 00:10:20,160 --> 00:10:23,772 ‫setzen, also zum Beispiel 500. Normalerweise wird es automatisch auf 160 00:10:23,772 --> 00:10:28,020 ‫200 gesetzt, was in Ordnung bedeutet, aber in diesem Fall haben wir einen 161 00:10:28,020 --> 00:10:31,420 ‫Serverfehler, was bedeutet, dass wir den Code 500 zurücksenden möchten. 162 00:10:31,420 --> 00:10:36,213 ‫Alles klar, also lass uns jetzt... 163 00:10:37,390 --> 00:10:39,313 ‫Eigentlich muss ich damit wieder aufhören. 164 00:10:45,520 --> 00:10:46,970 ‫Schauen wir also, was jetzt passiert. 165 00:10:53,001 --> 00:10:54,870 ‫Oh, wir haben hier bereits einen 166 00:10:54,870 --> 00:10:57,790 ‫Fehler, res. Status ist keine Funktion. Und 167 00:10:57,790 --> 00:11:00,872 ‫ja, eigentlich sein StatusCode. So schreibt man 168 00:11:00,872 --> 00:11:05,100 ‫es also in Express, also bin ich es schon gewohnt, Express so 169 00:11:05,100 --> 00:11:10,100 ‫zu schreiben, also ist Express ein Knoten. js-Framework, das wir im Rest des 170 00:11:10,370 --> 00:11:12,150 ‫Kurses verwenden werden, und in 171 00:11:12,150 --> 00:11:15,060 ‫Express machen Sie es so, und das 172 00:11:15,060 --> 00:11:18,420 ‫war das Problem. Ich bin also schon ein bisschen daran 173 00:11:18,420 --> 00:11:19,673 ‫gewöhnt, Express zu schreiben. 174 00:11:22,460 --> 00:11:26,470 ‫Gehen wir also zurück, und ja, jetzt sehen wir, dass die Datei 175 00:11:26,470 --> 00:11:31,090 ‫nicht gefunden wurde, und wenn wir die Entwicklungstools öffnen, sehen Sie unseren 500-Fehlercode, den wir 176 00:11:31,090 --> 00:11:34,823 ‫gerade gesendet haben, und wenn wir zu unserem Netzwerk-Tab gehen, versuchen 177 00:11:36,440 --> 00:11:39,840 ‫wir es noch einmal. Sie haben hier auch den Statuscode. 178 00:11:39,840 --> 00:11:43,990 ‫Also genau wie wir es in einem der vorherigen Videos in einem 179 00:11:43,990 --> 00:11:47,130 ‫anderen Abschnitt gesehen haben. So können wir diese 180 00:11:47,130 --> 00:11:49,343 ‫Art von Dingen auf der Registerkarte "Netzwerk" überprüfen. 181 00:11:52,530 --> 00:11:57,343 ‫In Ordnung, also lass es hier reparieren, speichern und okay, also 182 00:11:58,300 --> 00:12:03,300 ‫funktioniert das wieder perfekt, aber es gibt immer noch ein Problem mit 183 00:12:03,550 --> 00:12:06,240 ‫diesem Ansatz, den ich dir gerade 184 00:12:06,240 --> 00:12:09,360 ‫gezeigt habe. Und das Problem ist, 185 00:12:09,360 --> 00:12:12,240 ‫dass unser lesbarer Stream, also derjenige, den wir 186 00:12:12,240 --> 00:12:16,100 ‫verwenden, um die Datei von der Festplatte zu lesen, viel schneller 187 00:12:16,100 --> 00:12:19,310 ‫ist, als das Ergebnis tatsächlich mit dem beschreibbaren Antwortstream 188 00:12:19,310 --> 00:12:22,910 ‫über das Netzwerk zu senden. Und dies wird den 189 00:12:22,910 --> 00:12:27,360 ‫Antwortstrom überfordern, der all diese eingehenden Daten nicht so schnell verarbeiten kann. 190 00:12:27,360 --> 00:12:29,920 ‫Und dieses Problem wird als Gegendruck bezeichnet. 191 00:12:29,920 --> 00:12:33,510 ‫Und es ist ein echtes Problem, das in echten Situationen auftreten kann. 192 00:12:33,510 --> 00:12:37,140 ‫In diesem Fall tritt also ein Rückstau auf, wenn die Antwort 193 00:12:37,140 --> 00:12:41,130 ‫die Daten nicht annähernd so schnell senden kann, wie sie sie aus 194 00:12:41,130 --> 00:12:43,620 ‫der Datei empfängt. Ist das sinnvoll? 195 00:12:43,620 --> 00:12:46,050 ‫Also müssen wir diese Lösung 196 00:12:46,050 --> 00:12:48,793 ‫reparieren und eine noch bessere finden. 197 00:12:50,130 --> 00:12:52,813 ‫Und so werden wir Lösung drei 198 00:12:55,120 --> 00:12:57,527 ‫erstellen, und das ist eigentlich 199 00:12:57,527 --> 00:13:01,150 ‫die letzte, OK? Also nicht mehr Lösungen als drei. 200 00:13:01,150 --> 00:13:05,000 ‫Das Geheimnis hier ist also, tatsächlich den Pfeifenoperator zu benutzen, den ich 201 00:13:05,000 --> 00:13:07,405 ‫im letzten Video erwähnt habe, okay? 202 00:13:07,405 --> 00:13:12,405 ‫Der Pipe-Operator ist also für alle lesbaren Streams verfügbar und ermöglicht es 203 00:13:12,960 --> 00:13:16,760 ‫uns, die Ausgabe eines lesbaren Streams direkt 204 00:13:16,760 --> 00:13:20,660 ‫in die Eingabe eines beschreibbaren Streams zu leiten, okay? 205 00:13:20,660 --> 00:13:24,010 ‫Und das wird dann das Problem des Rückstaus 206 00:13:24,010 --> 00:13:27,340 ‫beheben, da es automatisch die Geschwindigkeit der 207 00:13:27,340 --> 00:13:31,260 ‫eingehenden Daten und die Geschwindigkeit der ausgehenden Daten verarbeitet. 208 00:13:31,260 --> 00:13:35,603 ‫Okay, also holen wir uns hier unseren lesbaren Stream. 209 00:13:38,290 --> 00:13:41,290 ‫Okay, das ist unser lesbarer Stream, und 210 00:13:41,290 --> 00:13:45,253 ‫jetzt müssen wir nur noch unseren lesbaren Stream nehmen, 211 00:13:46,280 --> 00:13:50,650 ‫die Pipe-Methode verwenden und dann einen beschreibbaren Stream einfügen, und das 212 00:13:50,650 --> 00:13:53,900 ‫ist die Antwort. Und das ist es tatsächlich. 213 00:13:53,900 --> 00:13:57,460 ‫Das ist alles, was wir für diese Lösung tun müssen, okay? 214 00:13:57,460 --> 00:13:59,960 ‫Damit es immer so funktioniert, lass 215 00:13:59,960 --> 00:14:04,960 ‫es mich hier als Kommentar schreiben. Wir brauchen also im Grunde eine lesbare Quelle, 216 00:14:06,040 --> 00:14:09,310 ‫okay, das ist wieder nur, um es Ihnen zu erklären, 217 00:14:09,310 --> 00:14:12,330 ‫dann können wir die Pipe darauf verwenden, und hier 218 00:14:12,330 --> 00:14:17,010 ‫müssen wir ein beschreibbares Ziel angeben. Von hier kommen also unsere 219 00:14:17,010 --> 00:14:19,980 ‫Daten, und es muss ein lesbarer Stream 220 00:14:19,980 --> 00:14:24,980 ‫sein, und diese Daten können wir dann an ein beschreibbares Ziel weiterleiten. 221 00:14:25,060 --> 00:14:29,520 ‫In diesem Fall ist unser Ziel also die Antwort, okay? 222 00:14:29,520 --> 00:14:32,790 ‫Nun kann dieser Stream hier tatsächlich auch ein Duplex- oder ein 223 00:14:32,790 --> 00:14:35,790 ‫Transformationsstream sein, aber was zählt ist, dass wir in 224 00:14:35,790 --> 00:14:38,930 ‫den Stream schreiben können. Und Antwort ist 225 00:14:38,930 --> 00:14:42,553 ‫natürlich so ein Stream. Wir können also natürlich die 226 00:14:42,553 --> 00:14:45,560 ‫Antwort schreiben, die an den Client gesendet wird, okay? 227 00:14:45,560 --> 00:14:48,890 ‫Der Rohrbetreiber löst also automatisch das Problem 228 00:14:48,890 --> 00:14:51,860 ‫des Gegendrucks, das wir zuvor hatten. 229 00:14:51,860 --> 00:14:54,720 ‫Und es ist eigentlich auch eine viel 230 00:14:54,720 --> 00:14:58,000 ‫elegantere und unkompliziertere Lösung. Was wir hier zuvor 231 00:14:58,000 --> 00:15:01,020 ‫getan haben, war, Ihnen alle Möglichkeiten zu zeigen, 232 00:15:01,020 --> 00:15:05,290 ‫wie wir die Stream-Methoden und -Ereignisse verwenden können, um diese Art von 233 00:15:05,290 --> 00:15:08,520 ‫Lösung zu erstellen, und natürlich gibt es viele Anwendungsfälle, 234 00:15:08,520 --> 00:15:12,044 ‫aber bei einem Problem wie diesem ist die Pipe Betreiber 235 00:15:12,044 --> 00:15:16,060 ‫ist eigentlich die beste Lösung. Hinter den Kulissen macht es 236 00:15:16,060 --> 00:15:17,950 ‫hier eigentlich so etwas, aber 237 00:15:17,950 --> 00:15:20,880 ‫wieder viel einfacher für uns zu schreiben, weil 238 00:15:20,880 --> 00:15:23,000 ‫es all die Dinge intern hinter 239 00:15:23,000 --> 00:15:26,500 ‫den Kulissen behandelt. Ich glaube also, dass Pipe 240 00:15:26,500 --> 00:15:30,370 ‫hier tatsächlich der einfachste Weg ist, Streams zu konsumieren und zu 241 00:15:30,370 --> 00:15:33,410 ‫schreiben, es sei denn, wir brauchen, wie bereits erwähnt, 242 00:15:33,410 --> 00:15:36,670 ‫eine individuellere Lösung. Und dann müssen wir 243 00:15:36,670 --> 00:15:39,910 ‫diese komplizierteren Werkzeuge wie diese Ereignisse und Methoden verwenden, die 244 00:15:39,910 --> 00:15:43,633 ‫ich Ihnen zuvor gezeigt habe. In Ordnung, also 245 00:15:45,270 --> 00:15:50,270 ‫zum Abschluss, beenden wir den Prozess hier, starten ihn erneut und 246 00:15:50,370 --> 00:15:54,350 ‫sehen natürlich, ob er noch funktioniert, was er tut. 247 00:15:54,350 --> 00:15:58,340 ‫Und so wird unsere Arbeit hier erledigt. Damit sind wir mit diesem 248 00:15:58,340 --> 00:16:01,343 ‫Vortrag fertig und können direkt zum nächsten übergehen.