1 00:00:01,300 --> 00:00:03,370 ‫Instruktur: Sekarang mari luangkan waktu sebentar untuk mempelajari 2 00:00:03,370 --> 00:00:06,370 ‫tentang sifat asinkron dari Node.js. js, 3 00:00:06,370 --> 00:00:09,510 ‫yang mencakup topik yang sangat 4 00:00:09,510 --> 00:00:13,010 ‫mendasar, seperti kode sinkron, asinkron, 5 00:00:13,010 --> 00:00:15,140 ‫pemblokiran, dan non-pemblokiran. 6 00:00:15,140 --> 00:00:17,810 ‫Dan semua ini akan sangat penting 7 00:00:17,810 --> 00:00:21,090 ‫untuk memahami segala sesuatu yang muncul di seluruh 8 00:00:21,090 --> 00:00:22,503 ‫bagian ini. 9 00:00:24,240 --> 00:00:27,620 ‫Jadi potongan kode yang kita tulis di 10 00:00:27,620 --> 00:00:31,830 ‫kuliah terakhir, untuk membaca file dan kemudian, menyimpan isinya ke 11 00:00:31,830 --> 00:00:34,400 ‫dalam variabel, disebut dengan cara sinkron, 12 00:00:34,400 --> 00:00:36,840 ‫yang berarti bahwa setiap 13 00:00:36,840 --> 00:00:41,330 ‫pernyataan pada dasarnya diproses satu demi satu, baris dengan garis. 14 00:00:41,330 --> 00:00:42,540 ‫Dalam 15 00:00:42,540 --> 00:00:45,630 ‫contoh ini, pertama, modul sistem file 16 00:00:45,630 --> 00:00:47,630 ‫diperlukan, kemudian, file dibaca, 17 00:00:47,630 --> 00:00:50,900 ‫dan kemudian, kami mencatat hasilnya ke konsol. 18 00:00:50,900 --> 00:00:53,340 ‫Jadi Anda melihat bahwa setiap 19 00:00:53,340 --> 00:00:57,340 ‫baris kode pada dasarnya menunggu hasil dari baris sebelumnya. 20 00:00:57,340 --> 00:00:59,440 ‫Sekarang, ini bisa menjadi masalah, 21 00:00:59,440 --> 00:01:01,500 ‫terutama dengan operasi yang 22 00:01:01,500 --> 00:01:04,190 ‫lambat, karena setiap baris memblokir eksekusi 23 00:01:04,190 --> 00:01:05,710 ‫kode lainnya. 24 00:01:05,710 --> 00:01:08,120 ‫Jadi, kami mengatakan bahwa 25 00:01:08,120 --> 00:01:12,290 ‫kode sinkron juga disebut kode pemblokiran karena, sekali 26 00:01:12,290 --> 00:01:15,080 ‫lagi, operasi tertentu hanya dapat 27 00:01:15,080 --> 00:01:17,740 ‫dijalankan setelah yang sebelumnya selesai. 28 00:01:17,740 --> 00:01:20,850 ‫Dan karena cara Node. js dirancang, ini 29 00:01:20,850 --> 00:01:24,220 ‫berubah menjadi masalah besar, seperti yang akan kita lihat 30 00:01:24,220 --> 00:01:26,190 ‫secara detail di slide berikutnya. 31 00:01:26,190 --> 00:01:28,500 ‫Jadi solusi untuk masalah ini 32 00:01:28,500 --> 00:01:32,160 ‫di Node adalah dengan menggunakan kode non-blocking asynchronous. 33 00:01:32,160 --> 00:01:35,380 ‫Jadi dalam kode asinkron, kami mengunggah pekerjaan 34 00:01:35,380 --> 00:01:38,470 ‫berat untuk dikerjakan di latar belakang. 35 00:01:38,470 --> 00:01:40,820 ‫Dan kemudian, setelah pekerjaan itu 36 00:01:40,820 --> 00:01:43,370 ‫selesai, fungsi panggilan balik yang kita 37 00:01:43,370 --> 00:01:45,730 ‫daftarkan sebelumnya dipanggil untuk menangani hasilnya. 38 00:01:45,730 --> 00:01:47,540 ‫Dan selama 39 00:01:47,540 --> 00:01:50,380 ‫itu, sisa kode masih bisa dieksekusi 40 00:01:50,380 --> 00:01:52,910 ‫tanpa terhalang oleh tugas berat, 41 00:01:52,910 --> 00:01:55,820 ‫yang sekarang berjalan di latar belakang. 42 00:01:55,820 --> 00:01:59,520 ‫Jadi ini berarti bahwa kita dapat secara efektif 43 00:01:59,520 --> 00:02:01,620 ‫menunda atau bereaksi ke 44 00:02:01,620 --> 00:02:04,530 ‫masa depan untuk membuat kode non-blocking 45 00:02:04,530 --> 00:02:07,676 ‫dan ini, tentu saja, jauh lebih baik. 46 00:02:07,676 --> 00:02:09,287 ‫Masuk akal? 47 00:02:09,287 --> 00:02:12,203 ‫Jadi, dalam contoh ini, kami 48 00:02:12,203 --> 00:02:16,390 ‫menggunakan fungsi readFile asinkron, yang menerima fungsi panggilan balik. 49 00:02:16,390 --> 00:02:19,120 ‫Ini akan mulai membaca file 50 00:02:19,120 --> 00:02:22,360 ‫di latar belakang dan kemudian, segera beralih ke 51 00:02:22,360 --> 00:02:25,830 ‫pernyataan berikutnya, mencetak file pembacaan string ke konsol. 52 00:02:25,830 --> 00:02:30,530 ‫Jadi, sekali lagi, kami tidak memblokir eksekusi di sini. 53 00:02:30,530 --> 00:02:33,860 ‫Kemudian, ketika file akhirnya selesai dibaca, fungsi 54 00:02:33,860 --> 00:02:35,870 ‫panggilan balik akan 55 00:02:35,870 --> 00:02:38,100 ‫dipanggil, dan data yang telah 56 00:02:38,100 --> 00:02:40,270 ‫dibaca akan dicetak ke konsol. 57 00:02:40,270 --> 00:02:41,890 ‫Jadi itu sangat 58 00:02:41,890 --> 00:02:43,893 ‫berbeda dari versi sinkron, bukan? 59 00:02:44,870 --> 00:02:46,710 ‫Sekarang, pertanyaannya di 60 00:02:46,710 --> 00:02:49,490 ‫sini adalah, mengapa sebenarnya harus seperti ini? 61 00:02:49,490 --> 00:02:53,940 ‫Apa masalah dengan memblokir eksekusi kode di Node.js? js? 62 00:02:53,940 --> 00:02:57,030 ‫Atau, dengan kata lain, mengapa kita benar-benar menggunakan panggilan balik 63 00:02:57,030 --> 00:02:59,770 ‫berkali-kali di Node.js? js? 64 00:02:59,770 --> 00:03:01,523 ‫Nah, mari kita cari tahu. 65 00:03:03,110 --> 00:03:05,930 ‫Dan untuk memahami pertanyaan-pertanyaan ini, hal pertama 66 00:03:05,930 --> 00:03:08,220 ‫yang perlu kita pahami adalah 67 00:03:08,220 --> 00:03:11,260 ‫fakta bahwa Node.js. js, yang 68 00:03:11,260 --> 00:03:13,760 ‫merupakan tempat aplikasi kita 69 00:03:13,760 --> 00:03:16,410 ‫berjalan, hanya ada satu utas. 70 00:03:16,410 --> 00:03:19,720 ‫Dan utasnya seperti sekumpulan instruksi yang 71 00:03:19,720 --> 00:03:22,200 ‫dijalankan di CPU komputer. 72 00:03:22,200 --> 00:03:25,200 ‫Jadi pada dasarnya, utas adalah 73 00:03:25,200 --> 00:03:29,270 ‫tempat kode kita sebenarnya dieksekusi di prosesor mesin. 74 00:03:29,270 --> 00:03:33,120 ‫Jadi, ingat, Node. js pada dasarnya adalah 75 00:03:33,120 --> 00:03:36,980 ‫utas tunggal dan karenanya, untuk setiap aplikasi, hanya ada satu utas. 76 00:03:36,980 --> 00:03:40,300 ‫Begitulah cara Node.js. js dirancang. 77 00:03:40,300 --> 00:03:43,050 ‫Sekarang, artinya semua pengguna yang 78 00:03:43,050 --> 00:03:46,960 ‫mengakses aplikasi Anda menggunakan utas yang sama, jadi, 79 00:03:46,960 --> 00:03:50,040 ‫pada dasarnya, mengakses utas yang sama. 80 00:03:50,040 --> 00:03:53,410 ‫Jadi, setiap kali mereka berinteraksi dengan aplikasi, kode 81 00:03:53,410 --> 00:03:55,860 ‫yang dijalankan untuk setiap pengguna 82 00:03:55,860 --> 00:03:59,810 ‫akan dieksekusi semua di utas yang sama di tempat yang 83 00:03:59,810 --> 00:04:02,490 ‫sama di komputer yang menjalankan aplikasi. 84 00:04:02,490 --> 00:04:04,900 ‫Dan itu benar tidak peduli jika 85 00:04:04,900 --> 00:04:09,900 ‫Anda memiliki lima pengguna, seperti dalam diagram ini, atau 5.000 atau 5 juta. 86 00:04:10,610 --> 00:04:12,080 ‫Baiklah? 87 00:04:12,080 --> 00:04:15,310 ‫Sekarang, ini juga berarti bahwa ketika satu pengguna 88 00:04:15,310 --> 00:04:17,960 ‫mengunci satu utas dengan kode sinkron, 89 00:04:17,960 --> 00:04:19,640 ‫seperti yang baru 90 00:04:19,640 --> 00:04:22,280 ‫saja kita lihat, maka semua pengguna 91 00:04:22,280 --> 00:04:24,680 ‫lain harus menunggu eksekusi itu selesai. 92 00:04:24,680 --> 00:04:27,010 ‫Dan itu mungkin bukan masalah besar 93 00:04:27,010 --> 00:04:29,800 ‫jika Anda memiliki lima pengguna, tetapi itu 94 00:04:29,800 --> 00:04:33,350 ‫pasti akan terjadi pada ribuan atau bahkan jutaan pengguna 95 00:04:33,350 --> 00:04:35,393 ‫pada saat yang bersamaan. 96 00:04:36,440 --> 00:04:39,830 ‫Jadi, bayangkan ada pengguna yang mengakses aplikasi Anda dan 97 00:04:39,830 --> 00:04:43,280 ‫ada file sinkron besar yang dibaca dalam kode Anda 98 00:04:43,280 --> 00:04:46,630 ‫yang membutuhkan waktu satu detik untuk dimuat. 99 00:04:46,630 --> 00:04:49,920 ‫Ini berarti, tentu saja, untuk satu detik 100 00:04:49,920 --> 00:04:52,370 ‫itu, semua pengguna lain 101 00:04:52,370 --> 00:04:57,370 ‫harus menunggu karena seluruh eksekusi diblokir selama satu detik itu. 102 00:04:57,490 --> 00:05:00,680 ‫Jadi, jika pengguna lain tersebut ingin melakukan beberapa tugas 103 00:05:00,680 --> 00:05:02,940 ‫sederhana, seperti masuk ke aplikasi 104 00:05:02,940 --> 00:05:06,900 ‫Anda atau hanya meminta beberapa data, mereka tidak akan dapat melakukannya. 105 00:05:06,900 --> 00:05:11,150 ‫Mereka harus menunggu sampai file selesai dibaca. 106 00:05:11,150 --> 00:05:15,130 ‫Hanya ketika itu terjadi, mereka akhirnya dapat melakukan tugas 107 00:05:15,130 --> 00:05:18,113 ‫yang lebih sederhana, satu demi satu. 108 00:05:19,260 --> 00:05:23,290 ‫Sekarang, harap dicatat, bahwa ini adalah versi yang sangat disederhanakan dari apa yang 109 00:05:23,290 --> 00:05:27,010 ‫sebenarnya terjadi di balik layar Node.js. js, itulah sebabnya 110 00:05:27,010 --> 00:05:29,880 ‫kami akan kembali ke semua ini 111 00:05:29,880 --> 00:05:33,760 ‫di bagian selanjutnya dan mendapatkan pemahaman yang lebih 112 00:05:33,760 --> 00:05:38,090 ‫dalam tentang bagaimana Node.js. js menangani kode asinkron di bawah tenda. 113 00:05:38,090 --> 00:05:39,370 ‫Tetapi pada titik 114 00:05:39,370 --> 00:05:42,170 ‫ini, ini cukup bagi Anda untuk memahami konsepnya. 115 00:05:42,170 --> 00:05:44,560 ‫Lebih baik untuk pergi selangkah demi 116 00:05:44,560 --> 00:05:46,520 ‫selangkah di sini dan 117 00:05:46,520 --> 00:05:49,220 ‫tidak membuatnya terlalu membingungkan sejak awal, oke? 118 00:05:49,220 --> 00:05:51,660 ‫Bagaimanapun, beginilah situasinya 119 00:05:51,660 --> 00:05:54,620 ‫dengan kode pemblokiran sinkron, yang 120 00:05:54,620 --> 00:05:58,460 ‫jelas merupakan pengalaman buruk bagi pengguna Anda. 121 00:05:58,460 --> 00:06:01,180 ‫Jadi, tugas Anda sebagai pengembang adalah 122 00:06:01,180 --> 00:06:03,260 ‫menghindari situasi seperti ini dengan 123 00:06:03,260 --> 00:06:05,113 ‫menggunakan kode asinkron. 124 00:06:07,150 --> 00:06:10,180 ‫Jadi, untuk situasi yang sama, tentu saja kita 125 00:06:10,180 --> 00:06:12,780 ‫harus menggunakan fungsi baca file asinkron, 126 00:06:12,780 --> 00:06:15,190 ‫yang alih-alih memblokir utas 127 00:06:15,190 --> 00:06:17,700 ‫tunggal, melakukan pekerjaan berat di latar 128 00:06:17,700 --> 00:06:20,170 ‫belakang, di mana pada dasarnya tetap 129 00:06:20,170 --> 00:06:22,700 ‫sampai selesai membaca data dari file. 130 00:06:22,700 --> 00:06:25,950 ‫Tentu saja, kami kemudian juga mendaftarkan 131 00:06:25,950 --> 00:06:29,490 ‫fungsi panggilan balik untuk dipanggil setelah data tersedia. 132 00:06:29,490 --> 00:06:32,130 ‫Dan dalam skenario ini, semua pengguna 133 00:06:32,130 --> 00:06:35,100 ‫lain kemudian dapat melakukan tugas mereka dalam 134 00:06:35,100 --> 00:06:38,710 ‫satu utas, satu demi satu, saat file masih dibaca 135 00:06:38,710 --> 00:06:40,390 ‫di latar belakang. 136 00:06:40,390 --> 00:06:43,870 ‫Sekarang, setelah data dibaca, fungsi panggilan balik kami, 137 00:06:43,870 --> 00:06:46,240 ‫tentu saja, akan dipanggil 138 00:06:46,240 --> 00:06:51,240 ‫untuk dieksekusi di utas tunggal utama untuk memproses data yang dibaca. 139 00:06:51,380 --> 00:06:52,460 ‫Dan itu saja. 140 00:06:52,460 --> 00:06:54,720 ‫Itulah gambaran tentang bagaimana Node. js 141 00:06:54,720 --> 00:06:58,000 ‫menangani perilaku asinkron untuk mengimplementasikan model 142 00:06:58,000 --> 00:07:00,850 ‫I/O non-blocking yang kita bicarakan 143 00:07:00,850 --> 00:07:03,670 ‫di kuliah pendahuluan, oke? 144 00:07:03,670 --> 00:07:07,240 ‫Dan I/O adalah singkatan dari input-output, yang 145 00:07:07,240 --> 00:07:10,810 ‫pada dasarnya adalah hal-hal seperti mengakses sistem 146 00:07:10,810 --> 00:07:13,500 ‫file dan menangani permintaan jaringan. 147 00:07:13,500 --> 00:07:16,470 ‫Ini sebenarnya alasan mengapa Node.js. js sepenuhnya dirancang 148 00:07:16,470 --> 00:07:18,830 ‫seputar panggilan balik, seperti yang akan 149 00:07:18,830 --> 00:07:21,190 ‫Anda lihat di sepanjang kursus. 150 00:07:21,190 --> 00:07:24,090 ‫Dalam bahasa pemrograman lain, seperti PHP, cara kerjanya 151 00:07:24,090 --> 00:07:27,260 ‫sangat berbeda karena pada dasarnya Anda mendapatkan satu utas 152 00:07:27,260 --> 00:07:29,640 ‫baru untuk setiap pengguna baru, yang 153 00:07:29,640 --> 00:07:32,020 ‫merupakan paradigma yang sama sekali berbeda 154 00:07:32,020 --> 00:07:34,600 ‫dan benar-benar bekerja dengan cara yang sangat berbeda. 155 00:07:34,600 --> 00:07:37,620 ‫Tapi pencipta Node. js menemukan model 156 00:07:37,620 --> 00:07:40,660 ‫ini sebagai solusi terbaik untuk membangun aplikasi web 157 00:07:40,660 --> 00:07:42,980 ‫yang berperforma tinggi dan skalabel. 158 00:07:42,980 --> 00:07:46,810 ‫Sekarang, sebagai catatan terakhir di sini, penting untuk diketahui bahwa, 159 00:07:46,810 --> 00:07:48,830 ‫ketika kita menggunakan panggilan 160 00:07:48,830 --> 00:07:53,380 ‫balik dalam kode kita, itu tidak secara otomatis membuatnya asinkron, oke? 161 00:07:53,380 --> 00:07:56,520 ‫Jadi, meneruskan fungsi ke fungsi lain 162 00:07:56,520 --> 00:07:58,780 ‫cukup umum di 163 00:07:58,780 --> 00:08:01,830 ‫JavaScript, tetapi tentu saja, sekali lagi, 164 00:08:01,830 --> 00:08:05,110 ‫itu tidak membuatnya asinkron secara otomatis, oke? 165 00:08:05,110 --> 00:08:09,150 ‫Ini hanya berfungsi dengan cara ini untuk beberapa fungsi di Node 166 00:08:09,150 --> 00:08:11,210 ‫API, seperti fungsi readFile dan 167 00:08:11,210 --> 00:08:14,823 ‫banyak lagi, seperti yang dijelajahi orang di masa mendatang. 168 00:08:16,610 --> 00:08:18,500 ‫Dan sekarang, hanya untuk 169 00:08:18,500 --> 00:08:21,200 ‫menyelesaikan, karena kita berbicara tentang kode asinkron di 170 00:08:21,200 --> 00:08:24,630 ‫sini, hanya satu catatan terakhir tentang fungsi panggilan balik. 171 00:08:24,630 --> 00:08:27,670 ‫Jadi, model panggilan balik yang baru saja kita 172 00:08:27,670 --> 00:08:29,370 ‫bahas, di mana satu 173 00:08:29,370 --> 00:08:32,300 ‫fungsi dipanggil setelah yang sebelumnya selesai bekerja, 174 00:08:32,300 --> 00:08:36,970 ‫dapat dengan cepat menyebabkan beberapa kode yang sulit dibaca dan tidak dapat dikelola. 175 00:08:36,970 --> 00:08:39,830 ‫Ambil saja contoh ini di mana pembacaan file 176 00:08:39,830 --> 00:08:41,870 ‫kedua bergantung pada yang 177 00:08:41,870 --> 00:08:44,800 ‫pertama, kemudian, pembacaan file ketiga bergantung pada yang 178 00:08:44,800 --> 00:08:47,560 ‫kedua, dan akhirnya, kami ingin menggunakan data 179 00:08:47,560 --> 00:08:49,700 ‫akhir untuk menulis file sebagai hasilnya. 180 00:08:49,700 --> 00:08:52,690 ‫Itu terlihat cukup membingungkan, bukan? 181 00:08:52,690 --> 00:08:54,950 ‫Maksud saya, ini akan bekerja 182 00:08:54,950 --> 00:08:57,330 ‫dengan baik, tapi itu sulit untuk 183 00:08:57,330 --> 00:09:00,110 ‫dipikirkan dan itu hanya dengan empat level. 184 00:09:00,110 --> 00:09:02,980 ‫Bayangkan Anda memiliki 10 atau 20 185 00:09:02,980 --> 00:09:05,850 ‫level, yang sebenarnya tidak biasa. 186 00:09:05,850 --> 00:09:09,440 ‫Bagaimanapun, ini adalah apa yang kita sebut neraka panggilan balik. 187 00:09:09,440 --> 00:09:11,370 ‫Ini adalah masalah umum, 188 00:09:11,370 --> 00:09:13,780 ‫yang sudah punya nama sendiri. 189 00:09:13,780 --> 00:09:16,920 ‫Dan apakah Anda memperhatikan bentuk segitiga ini di sini? 190 00:09:16,920 --> 00:09:20,840 ‫Itu tanda yang sangat jelas bahwa Anda berada di neraka panggilan balik. 191 00:09:20,840 --> 00:09:24,350 ‫Sekarang, bagaimana kita benar-benar lolos dari panggilan balik neraka? 192 00:09:24,350 --> 00:09:27,600 ‫Yah, kita dapat menggunakan alat yang lebih 193 00:09:27,600 --> 00:09:30,730 ‫canggih untuk menangani kode asinkron, seperti 194 00:09:30,730 --> 00:09:34,150 ‫janji ES6 atau bahkan lebih baik, ES8 asinkron/menunggu. 195 00:09:34,150 --> 00:09:36,320 ‫Sekarang, model yang baru saja kita 196 00:09:36,320 --> 00:09:37,890 ‫bicarakan akan tetap sama. 197 00:09:37,890 --> 00:09:39,960 ‫Kami hanya memiliki cara yang 198 00:09:39,960 --> 00:09:43,370 ‫lebih elegan untuk menangani kode itu sendiri dan menulisnya. 199 00:09:43,370 --> 00:09:45,830 ‫Dan ada bagian opsional 200 00:09:45,830 --> 00:09:50,090 ‫secara keseluruhan nanti dalam kursus tentang janji dan juga, async/menunggu, 201 00:09:50,090 --> 00:09:52,590 ‫jadi jika Anda tidak terbiasa dengannya. 202 00:09:52,590 --> 00:09:55,140 ‫Tetapi untuk saat ini, kami akan 203 00:09:55,140 --> 00:09:57,900 ‫tetap menggunakan callback karena itulah yang digunakan 204 00:09:57,900 --> 00:10:00,100 ‫dan dirancang oleh Node. 205 00:10:00,100 --> 00:10:02,030 ‫Dan sekarang, dengan itu, 206 00:10:02,030 --> 00:10:05,240 ‫mari kita lanjutkan dan gunakan model asinkron ini 207 00:10:05,240 --> 00:10:07,233 ‫dalam praktik untuk pertama kalinya.