Beyond The Browser: Memulai Dengan WebAssembly Tanpa Server

Sekarang WebAssembly didukung oleh semua browser utama dan lebih dari 85% pengguna di seluruh dunia, JavaScript bukan lagi satu-satunya bahasa browser di kota ini. Jika Anda belum pernah mendengar, WebAssembly adalah bahasa tingkat rendah baru yang berjalan di browser. Ini juga merupakan target kompilasi, yang berarti Anda dapat mengkompilasi program yang ada yang ditulis dalam bahasa seperti C, C++, dan Rust ke dalam WebAssembly, dan menjalankan program tersebut di browser. Sejauh ini, WebAssembly telah digunakan untuk mem-porting semua jenis aplikasi ke web, termasuk aplikasi desktop, alat baris perintah, permainan, dan alat ilmu data.

Catatan: Untuk studi kasus mendalam tentang bagaimana WebAssembly dapat digunakan di dalam browser untuk mempercepat aplikasi web, lihat artikel saya sebelumnya.

WebAssembly Di Luar Web?

Meskipun sebagian besar aplikasi WebAssembly saat ini adalah browser-centric, WebAssembly sendiri awalnya tidak dirancang hanya untuk web, tetapi benar-benar untuk lingkungan kotak pasir apa pun. Faktanya, baru-baru ini ada banyak minat untuk mengeksplorasi bagaimana WebAssembly dapat berguna di luar browser, sebagai pendekatan umum untuk menjalankan binari pada OS atau arsitektur komputer apa pun, selama ada runtime WebAssembly yang mendukung sistem itu. Pada artikel ini, kita akan melihat bagaimana WebAssembly dapat dijalankan di luar browser, dalam mode tanpa server/Function-as-a-Service (FaaS).

WebAssembly Untuk Aplikasi Tanpa Server

Singkatnya, fungsi tanpa server adalah model komputasi di mana Anda menyerahkan kode Anda ke penyedia cloud, dan membiarkan mereka mengeksekusi dan mengelola penskalaan kode itu untuk Anda. Misalnya, Anda dapat meminta agar fungsi tanpa server dijalankan kapan pun Anda memanggil titik akhir API, atau didorong oleh peristiwa, seperti saat file diunggah ke bucket cloud Anda. Sementara istilah "tanpa server" mungkin tampak seperti keliru karena server jelas terlibat di suatu tempat di sepanjang jalan, itu tanpa server dari sudut pandang kami karena kami tidak perlu khawatir tentang cara mengelola, menyebarkan, atau menskalakan server tersebut.

Meskipun fungsi ini biasanya ditulis dalam bahasa seperti Python dan JavaScript (Node.js), ada beberapa alasan Anda mungkin memilih untuk menggunakan WebAssembly sebagai gantinya:

1. Waktu Inisialisasi Lebih Cepat
   Penyedia tanpa server yang mendukung WebAssembly (termasuk Cloudflare dan Fastly melaporkan bahwa mereka dapat meluncurkan fungsi setidaknya urutan besarnya lebih cepat daripada kebanyakan penyedia cloud dengan bahasa lain. Mereka mencapai ini dengan menjalankan puluhan ribu modul WebAssembly dalam proses yang sama, yaitu mungkin karena sifat kotak pasir dari WebAssembly membuat cara yang lebih efisien untuk mendapatkan isolasi yang biasanya digunakan wadah.
2. Tidak Perlu Penulisan Ulang
   Salah satu daya tarik utama WebAssembly di browser adalah kemampuannya untuk mem-port kode yang ada ke web tanpa harus menulis ulang semuanya ke JavaScript. Manfaat ini masih berlaku dalam kasus penggunaan tanpa server karena penyedia cloud membatasi bahasa mana Anda dapat menulis fungsi tanpa server Anda. Biasanya, mereka akan mendukung Python, Node.js, dan mungkin beberapa lainnya, tetapi tentu saja tidak C, C++, atau Rust . Dengan mendukung WebAssembly, penyedia tanpa server secara tidak langsung dapat mendukung lebih banyak bahasa.
3. Lebih Ringan
   Saat menjalankan WebAssembly di browser, kami mengandalkan komputer pengguna akhir untuk melakukan perhitungan kami. Jika perhitungan tersebut terlalu intensif, pengguna kami tidak akan senang ketika kipas komputer mereka mulai berputar. Menjalankan WebAssembly di luar browser memberi kami manfaat kecepatan dan portabilitas WebAssembly, sekaligus menjaga aplikasi kami tetap ringan. Selain itu, karena kami menjalankan kode WebAssembly kami di lingkungan yang lebih dapat diprediksi, kami berpotensi melakukan komputasi yang lebih intensif.

Contoh Konkrit

Dalam artikel saya sebelumnya di Smashing Magazine, kami membahas bagaimana kami mempercepat aplikasi web dengan mengganti perhitungan JavaScript yang lambat dengan kode C yang dikompilasi ke WebAssembly. Aplikasi web yang dimaksud adalah fastq.bio, alat untuk melihat pratinjau kualitas data pengurutan DNA.

Sebagai contoh konkret, mari kita tulis ulang fastq.bio sebagai aplikasi yang menggunakan WebAssembly tanpa server alih-alih menjalankan WebAssembly di dalam browser. Untuk artikel ini, kami akan menggunakan Cloudflare Workers, penyedia tanpa server yang mendukung WebAssembly dan dibangun di atas mesin browser V8. Penyedia cloud lain, Fastly, sedang mengerjakan penawaran serupa, tetapi berdasarkan runtime Lucet mereka.

Pertama, mari kita tulis beberapa kode Rust untuk menganalisis kualitas data dari data sekuensing DNA. Untuk kenyamanan, kami dapat memanfaatkan perpustakaan bioinformatika Rust-Bio untuk menangani penguraian data input, dan perpustakaan wasm-bindgen untuk membantu kami mengkompilasi kode Rust kami ke WebAssembly.

Berikut cuplikan kode yang terbaca dalam data sekuensing DNA dan mengeluarkan JSON dengan ringkasan metrik kualitas:

 // Import packages extern crate wasm_bindgen; use bio::seq_analysis::gc; use bio::io::fastq; ... // This "wasm_bindgen" tag lets us denote the functions // we want to expose in our WebAssembly module #[wasm_bindgen] pub fn fastq_metrics(seq: String) -> String { ... // Loop through lines in the file let reader = fastq::Reader::new(seq.as_bytes()); for result in reader.records() { let record = result.unwrap(); let sequence = record.seq(); // Calculate simple statistics on each record n_reads += 1.0; let read_length = sequence.len(); let read_gc = gc::gc_content(sequence); // We want to draw histograms of these values // so we store their values for later plotting hist_gc.push(read_gc * 100.0); hist_len.push(read_length); ... } // Return statistics as a JSON blob json!({ "n": n_reads, "hist": { "gc": hist_gc, "len": hist_len }, ... }).to_string() }

Kami kemudian menggunakan alat baris perintah wrangler Cloudflare untuk melakukan tugas berat kompilasi ke WebAssembly dan penerapan ke cloud. Setelah selesai, kami diberikan titik akhir API yang mengambil data pengurutan sebagai input dan mengembalikan JSON dengan metrik kualitas data. Kami sekarang dapat mengintegrasikan API itu ke dalam aplikasi kami.

Berikut GIF aplikasi yang sedang beraksi:

Kode lengkapnya tersedia di GitHub (sumber terbuka).

Menempatkan Semuanya Dalam Konteks

Untuk menempatkan pendekatan WebAssembly tanpa server dalam konteks, mari pertimbangkan empat cara utama di mana kita dapat membangun aplikasi web pemrosesan data (yaitu aplikasi web tempat kita melakukan analisis pada data yang disediakan oleh pengguna):

Seperti yang ditunjukkan di atas, pengolahan data dapat dilakukan di beberapa tempat:

1. Sisi server
   Ini adalah pendekatan yang diambil oleh sebagian besar aplikasi web, di mana panggilan API dilakukan di front-end, meluncurkan pemrosesan data di back-end.
2. JavaScript Sisi Klien
   Dalam pendekatan ini, kode pemrosesan data ditulis dalam JavaScript dan berjalan di browser. Kelemahannya adalah kinerja Anda akan terpukul, dan jika kode asli Anda tidak ada dalam JavaScript, Anda harus menulis ulang dari awal!
3. Perakitan Web Sisi Klien
   Ini melibatkan kompilasi kode analisis data ke WebAssembly dan menjalankannya di browser. Jika kode analisis ditulis dalam bahasa seperti C, C++ atau Rust (seperti yang sering terjadi di bidang genomik saya), ini meniadakan kebutuhan untuk menulis ulang algoritme kompleks dalam JavaScript. Ini juga memberikan potensi untuk mempercepat aplikasi kita (misalnya seperti yang dibahas dalam artikel sebelumnya).
4. Perakitan Web Tanpa Server
   Ini melibatkan menjalankan WebAssembly yang dikompilasi di cloud, menggunakan jenis model FaaS (mis. artikel ini).

Jadi mengapa Anda memilih pendekatan tanpa server daripada yang lain? Untuk satu hal, dibandingkan dengan pendekatan pertama, ini memiliki manfaat yang datang dengan menggunakan WebAssembly, terutama kemampuan untuk mem-port kode yang ada tanpa harus menulis ulang ke JavaScript. Dibandingkan dengan pendekatan ketiga, WebAssembly tanpa server juga berarti aplikasi kami lebih ringan karena kami tidak menggunakan sumber daya pengguna untuk menghitung angka. Secara khusus, jika komputasi cukup terlibat atau jika data sudah ada di cloud, pendekatan ini lebih masuk akal.

Namun, di sisi lain, aplikasi sekarang perlu membuat koneksi jaringan, sehingga aplikasi kemungkinan akan lebih lambat. Selain itu, tergantung pada skala komputasi dan apakah dapat dipecah menjadi bagian analisis yang lebih kecil, pendekatan ini mungkin tidak sesuai karena keterbatasan yang diberlakukan oleh penyedia cloud tanpa server pada penggunaan runtime, CPU, dan RAM.

Kesimpulan

Seperti yang kita lihat, sekarang dimungkinkan untuk menjalankan kode WebAssembly dalam mode tanpa server dan menuai manfaat dari WebAssembly (portabilitas dan kecepatan) dan arsitektur fungsi sebagai layanan (penskalaan otomatis dan harga per penggunaan ). Jenis aplikasi tertentu — seperti analisis data dan pemrosesan gambar, untuk beberapa nama — dapat sangat diuntungkan dari pendekatan semacam itu. Meskipun runtime menderita karena perjalanan pulang pergi tambahan ke jaringan, pendekatan ini memungkinkan kami untuk memproses lebih banyak data pada satu waktu dan tidak menguras sumber daya pengguna.