Commit 1 Reflection notes

Dalam fungsi handle_connection, kita memproses request yang masuk dari browser. Berikut adalah penjelasan metode yang digunakan:

1. BufReader::new(&mut stream): Kita membungkus TcpStream menggunakan BufReader. Ini bertujuan untuk menambahkan buffering, sehingga pembacaan data menjadi lebih efisien karena kita bisa memanggil fungsi seperti .lines() untuk membaca data baris per baris secara langsung, daripada membaca byte demi byte secara manual.
2. .lines(): Mengubah BufReader menjadi iterator yang mengembalikan setiap baris teks dari stream.
3. .map(|result| result.unwrap()): Karena setiap baris yang dibaca mengembalikan tipe Result (bisa sukses atau error), kita menggunakan .map() dan .unwrap() untuk mengekstrak nilai String dari Result::Ok secara langsung (mengasumsikan tidak ada error saat pembacaan demi kesederhanaan).
4. .take_while(|line| !line.is_empty()): HTTP request header selalu diakhiri dengan dua buah newline (baris kosong). Fungsi ini akan terus membaca baris dari stream sampai menemukan baris kosong tersebut, lalu berhenti. Ini mencegah program hang karena menunggu data yang tidak akan dikirim lagi oleh browser.
5. .collect(): Mengumpulkan semua baris teks yang sudah diproses di atas ke dalam sebuah koleksi vektor (Vec<_>), yang kemudian kita simpan ke variabel http_request untuk di-print.

Commit 2 Reflection notes

Pada code yang baru ditambahkan di handle_connection, server sekarang mengirimkan response yang valid sesuai HTTP Protocol. Berikut hal baru yang dipelajari:

1. fs::read_to_string("hello.html"): Digunakan untuk membaca seluruh isi file HTML dan mengubahnya menjadi tipe data String di Rust agar bisa dikirimkan sebagai body dari HTTP response.
2. HTTP/1.1 200 OK: Ini adalah status line standar dari HTTP yang memberitahu browser bahwa request berhasil diproses.
3. Content-Length: Header HTTP yang wajib disertakan agar browser tahu seberapa besar ukuran data (dalam byte) yang akan diterima. Kita menghitungnya menggunakan contents.len().
4. Format Response (\r\n\r\n): Protokol HTTP mensyaratkan penggunaan CRLF (\r\n) untuk memisahkan setiap baris header. Selain itu, harus ada dua buah CRLF (\r\n\r\n) yang berfungsi sebagai pemisah mutlak antara bagian Headers dan bagian Body (isi konten HTML).
5. stream.write_all: Mengirimkan seluruh string balasan yang sudah diformat tadi (diubah menjadi bytes) kembali melalui TCP stream ke browser.

Commit 3 Reflection notes

Pada tahap ini, kita memvalidasi request HTTP yang masuk agar server tidak merespons semua request dengan hello.html.

1. Cara memisahkan respons: Kita membaca baris pertama dari HTTP request (request_line). Jika baris tersebut sama persis dengan "GET / HTTP/1.1", kita mengembalikan hello.html dengan status 200 OK. Jika request line berupa hal lain (misalnya /bad), kita masuk ke blok else dan mengembalikan 404.html dengan status 404 NOT FOUND.
2. Kenapa refactoring diperlukan: Pada awalnya, blok if dan else memiliki banyak duplikasi kode (seperti pemanggilan fs::read_to_string, penghitungan length, dan format response). Membiarkan kode duplikat bertentangan dengan prinsip Clean Code (DRY - Don't Repeat Yourself). Dengan melakukan refactoring, kita hanya menggunakan blok if-else untuk menentukan status_line dan filename, lalu mengeksekusi logika pembacaan file dan pengiriman respons secara universal di luar blok kondisi tersebut. Ini membuat kode lebih bersih, mudah dibaca, dan mudah di-maintenance jika nanti kita ingin menambahkan modifikasi pada format respons HTTP.

Commit 4 Reflection notes

Pada tahap ini, kita menambahkan rute /sleep yang akan melakukan simulasi proses lambat dengan menghentikan thread selama 10 detik (thread::sleep).

Dari hasil percobaan membuka dua browser window, ketika kita mengakses /sleep di window pertama dan segera mengakses / di window kedua, window kedua tertahan (loading terus) dan baru memuat halaman setelah window pertama selesai.

Kenapa ini terjadi? Ini terjadi karena web server yang kita bangun saat ini bersifat Single-Threaded. Artinya, server hanya memproses satu request pada satu waktu secara berurutan. Ketika rute /sleep diakses, satu-satunya thread yang dimiliki program akan delay selama 10 detik. Selama masa itu, thread tersebut blocked dan tidak bisa menerima atau memproses koneksi baru yang masuk (seperti request ke / dari window kedua). Window kedua harus menunggu dalam antrean sistem operasi (TCP queue) sampai thread utama selesai memproses rute /sleep. Ini menunjukkan bahwa server single-thread sangat tidak optimal dan tidak tangguh untuk menangani banyak koneksi (karena bottleneck).

Commit 5 Reflection notes

Pada tahap ini, kita menyelesaikan masalah single-thread bottleneck dengan mengimplementasikan ThreadPool.

Bagaimana ThreadPool Bekerja:

1. Saat program berjalan, ThreadPool::new(4) akan langsung membuat 4 thread pekerja (Worker) yang berjalan di latar belakang.
2. Kita menggunakan struktur komunikasi Channel (mpsc::channel) di Rust. ThreadPool bertindak sebagai pengirim pesan (Sender), dan setiap Worker berbagi akses sebagai penerima pesan (Receiver) melalui Arc<Mutex<Receiver>> agar aman dari race condition antar thread.
3. Setiap kali ada koneksi masuk dari browser, fungsi main akan memanggil pool.execute(...) dan mengirimkan tugas (closure/pekerjaan yang harus dieksekusi) ke dalam channel.
4. Worker yang sedang menganggur akan menerima tugas tersebut dari channel dan langsung mengeksekusinya.
5. Dengan arsitektur ini, jika ada pengguna yang mengakses rute lambat seperti /sleep, hanya satu Worker yang akan tertidur. Tiga Worker lainnya tetap standby dan bisa langsung melayani koneksi baru yang masuk secara bersamaan (karena itu tes membuka 2 window secara bersamaan sekarang berhasil tanpa harus antre).

Commit Bonus Reflection notes

Pada bagian bonus ini, saya mengganti fungsi new pada ThreadPool menjadi fungsi build. Berikut adalah perbandingan dan alasan perubahannya:

1. Fungsi new (Sebelumnya): Di Rust, fungsi new memiliki conventional yang tidak tertulis, bahwa ia harus selalu berhasil membuat dan mengembalikan instance dari sebuah struct. Pada kode sebelumnya, jika kita memasukkan parameter size bernilai 0, program akan memanggil makro assert! dan seketika mengalami crash. Hal ini bukanlah design pattern yang baik untuk sebuah library atau public API, karena dapat mematikan program utama pengguna secara paksa.
2. Fungsi build (Perbaikan): Ketika proses pembuatan instance memiliki kemungkinan gagal (misalnya karena validasi input yang salah seperti size == 0), lebih idiomatic di Rust untuk menggunakan fungsi bernama build yang mengembalikan tipe data Result. Dengan cara ini, jika input bernilai 0, kita mengembalikan Err(PoolCreationError) alih-alih melakukan panic.
3. Dampak: Penggunaan build memberikan fleksibilitas kepada pemanggil (dalam hal ini main.rs) untuk menangani error tersebut dengan elegan (misalnya dengan mencetak pesan error ke stderr dan keluar menggunakan std::process::exit(1)), membuat server menjadi jauh lebih robust dan aman dari crash mendadak.