Rust membutuhkan framework web untuk developer yang malas

• Saat membuat aplikasi web kecil dengan Rust, masih kurang pengalaman terintegrasi seperti Django, sehingga beban merangkai sendiri routing, login, DB, dan fitur admin menjadi besar
• Framework yang dibutuhkan harus membundel secara bawaan routing/handler, template, penyajian file statis, login, otorisasi, antarmuka DB, alat admin, WebSockets, dan hot reloading
• Ada framework minimal seperti actix-web dan axum serta framework SPA seperti Dioxus, Leptos, dan Yew, tetapi semuanya tidak merakit keseluruhan susunan aplikasi web untuk Anda
• Template starter memang mengurangi pengaturan awal, tetapi setelah proyek bercabang, penggabungan perubahan dan pembaruan library tetap menjadi beban pemeliharaan
• newt mengarah pada toolkit web yang mengikat komponen yang sudah ada dengan cara yang opinionated, dengan tujuan membuat aplikasi web kecil bisa dimulai dalam hitungan menit, bukan hari

---

Titik awal terintegrasi yang kurang dalam pengembangan web Rust

• Bahkan saat membuat proyek web kecil dengan Rust, dibutuhkan jauh lebih banyak pekerjaan pengkabelan awal dibanding Django atau framework serupa
• Pendekatan umum di komunitas Rust lebih dekat ke cara merangkai sendiri komponen yang dibutuhkan
  • Are We Web Yet? juga menjelaskan bahwa dalam pengembangan web Rust, komponen umumnya perlu dihubungkan sendiri, dan menyarankan untuk memperkirakan adanya pekerjaan konfigurasi tambahan saat memulai
• Pekerjaan tambahan ini bukan sekadar “sedikit lebih banyak”, tetapi benar-benar mencakup banyak hal yang harus ditangani sebelum proyek bisa dimulai
• Jika ada framework web yang terintegrasi, akan lebih mudah meyakinkan orang untuk memakai Rust dalam aplikasi web
  • Keunggulan Rust yang disebut antara lain sistem tipe, performa, dan jeda minum kopi selama waktu kompilasi

Komponen dasar yang dibutuhkan hampir semua aplikasi web

• Routing/handler

  • Permintaan yang masuk harus diarahkan ke handler yang sesuai
  • Parameter path harus bisa ditangani, dan akan lebih baik jika ada informasi tipe
  • Parameter query dan pemrosesan form juga sebaiknya tersedia

• Template

  • Harus bisa menghasilkan HTML, dan dalam beberapa kasus juga JSON atau XML
  • Dibutuhkan logika dasar seperti kondisional, match/switch, dan perulangan

• Penyajian file statis

  • Harus bisa menyajikan aset seperti CSS
  • Ini bisa ditangani oleh server terpisah, tetapi untuk pengembangan lokal dan deployment kecil, akan lebih praktis jika disertakan dalam server web yang sama

• Login

  • Aplikasi umumnya bersifat multi-pengguna atau dideploy di jaringan publik, jadi fitur login hampir selalu dibutuhkan
  • Karena merepotkan jika harus merangkainya sendiri setiap kali, fitur ini harus mudah dipakai sejak awal
  • Kustomisasi dan opsi untuk tidak menggunakannya tetap harus ada

• Otorisasi

  • Dalam sistem dengan banyak pengguna, data atau peran yang bisa diakses berbeda-beda
  • Bahkan pola check(user, object, action) saja sudah bisa membawa cukup jauh

• Antarmuka DB

  • Dibutuhkan cara untuk menyimpan data aplikasi
  • Pendekatan yang mirip ORM bisa berguna, tetapi pendekatan yang lebih ringan juga memungkinkan
  • Karena dipakai untuk login, otorisasi, dan alat admin, ini menjadi komponen dasar

• Alat admin

  • Saat mengatur aplikasi di lingkungan lokal maupun produksi, setidaknya perlu melakukan bootstrap untuk satu pengguna atau sebagian data
  • Sebagian tugas admin yang umum sebaiknya dibangun langsung agar pengalaman terasa mulus

• WebSockets

  • Memungkinkan pembuatan fitur yang mendorong data ke pengguna yang terhubung dengan nuansa lebih mendekati real-time

• Hot reloading

  • Perubahan kode atau template harus tercermin secepat mungkin, sehingga ini sangat penting bagi pengalaman developer

Fitur tambahan yang dibutuhkan proyek jangka panjang

• Pekerjaan background

  • Akan muncul fungsi yang perlu dijalankan sesuai jadwal, jadi adanya cara yang konsisten akan memudahkan pengembangan

• Monitoring/observability

  • Ini dibutuhkan kecuali untuk sistem yang paling kecil dan paling tidak penting
  • Sangat membantu tepat saat benar-benar mulai terasa mendesak

• Caching

  • Ada banyak cara implementasi dan semuanya menambah kompleksitas, sementara peningkatan kecepatan juga bergantung pada situasi
  • Akan bagus jika ada pembahasan di tingkat framework, tetapi pengguna juga bisa menanganinya sendiri

• Email dan notifikasi

  • Jika ada fitur login, kemampuan email bisa menjadi kebutuhan praktis karena reset kata sandi
  • Fitur notifikasi lainnya bisa ditambahkan nanti saat memang diperlukan

• Alat deployment

  • Akan bagus jika ada cara yang konsisten untuk deployment ke lokasi tertentu
  • Bahkan Dockerfile yang dihasilkan otomatis untuk host yang dipilih pun sudah berguna

• Bundling CSS/JS

  • Akan bagus jika alat web bisa mengenali CSS dan JS lalu menyertakannya secara alami
  • Tidak pasti apakah ini benar-benar harus diintegrasikan

Celah yang ditinggalkan ekosistem web Rust saat ini

• Rust sudah punya banyak alat pengembangan web, tetapi tidak ada alat yang benar-benar menargetkan pengalaman terintegrasi yang diinginkan ini

• Framework web minimal

  • actix-web dan axum lebih mirip framework kecil seperti Flask atau Sinatra
  • Keduanya memberi pengalaman pengembangan web yang baik dengan memanfaatkan sistem tipe Rust, tetapi hampir tidak menyediakan banyak fitur tambahan selain handler
  • Meski sebagian besar proyek bisa dibuat dengan framework minimal seperti ini, tetap merepotkan karena fitur yang dibutuhkan harus dirangkai sendiri setiap kali

• Framework SPA

  • Dioxus, Leptos, dan Yew mengisi area penggunaan Rust untuk backend dan frontend sekaligus, dengan WebAssembly untuk rendering frontend
  • Pengalaman membuat digital vigil dengan Yew terasa menyenangkan, tetapi belum tentu ingin dipakai di lingkungan produksi nyata
  • Framework-framework ini juga hebat untuk tujuannya masing-masing, tetapi tetap memerlukan banyak pekerjaan pengkabelan

• Kumpulan library terpisah

  • Ada banyak library untuk template, login, otorisasi, dan WebSocket
  • Beberapa proyek dan contoh memang mengintegrasikan sebagian komponen, tetapi sulit menemukan yang menyatukan semua bagian yang dipakai
  • Karena ekosistem bergerak cepat, sebagian contoh mungkin sudah usang
  • “Tinggal hubungkan saja” pada akhirnya berarti tetap harus meneliti cara kerja tiap library dan memahaminya dengan cukup baik

Beban pemeliharaan yang tidak diselesaikan template starter

• Pendekatan yang ada biasanya memilih framework dasar seperti actix-web atau axum, lalu mencari bagian-bagian yang diperlukan, menambahkannya, dan menghubungkannya sendiri
• Template starter bisa mengurangi rasa sakit di awal, tetapi beban pemeliharaan tetap ada
  • Library harus terus dijaga tetap mutakhir
  • Perubahan yang memutus kompatibilitas (breaking change) juga harus ditangani
  • Begitu proyek menyimpang dari template, akan sulit menggabungkan kembali perubahan pada template
• Jika mengelola banyak proyek, alih-alih memperbarui satu framework, Anda harus memperbarui n framework kustom satu per satu
• Akan lebih baik jika framework web yang menangani semuanya menyediakan panduan upgrade antarversi
  • Perubahan yang memutus kompatibilitas mungkin tetap terjadi, tetapi setidaknya bisa didokumentasikan
  • Ini juga bisa mengurangi masalah yang muncul akibat perubahan interaksi antara dua komponen yang sejak awal tidak tahu bahwa mereka akan diintegrasikan satu sama lain

Toolkit web yang dituju newt

• Framework web Rust yang ideal harus memiliki fitur-fitur yang disebut sebelumnya, bersama dokumentasi yang baik, changelog, pengelolaan versi yang hati-hati, penanganan perubahan yang memutus kompatibilitas, dan komunitas
• Saat ini alat seperti itu belum ada, dan juga belum jelas apakah orang lain sedang membuatnya
• Alat yang sedang dikerjakan ini lebih dekat ke toolkit web daripada framework, yaitu merangkai blok bangunan yang sudah ada dengan cara yang opinionated
• Nama toolkit ini adalah nicole's web toolkit, disingkat newt
  • Tersedia di public repository
  • Saat ini belum dalam kondisi yang bisa digunakan, dan perubahan terbaru juga belum di-push
  • Juga belum siap menerima kontribusi
• Tujuan newt adalah agar saat membuat aplikasi web kecil yang baru, alih-alih menghabiskan berhari-hari untuk pekerjaan pengkabelan, orang bisa mulai mengerjakan proyek sebenarnya dalam beberapa menit
• Ada rencana untuk membuat sebagian komponen dari nol jika memang diperlukan
  • Itu bisa lebih mudah atau lebih cocok secara kohesif
• Ekosistem Rust membutuhkan kondisi yang sehat dengan beberapa toolkit seperti ini, dan diharapkan alat-alat lain juga akan muncul

[GN⁺]

Komentar Hacker News

• Kaget karena Rocket(https://rocket.rs/) tidak ada dalam daftar framework yang disebut penulis
  Saya sendiri belum pernah memakainya, dan lebih suka axum/actix-web yang lebih tidak preskriptif, tetapi setahu saya tujuan Rocket jauh lebih dekat ke framework batteries-included yang diinginkan penulis, dan ini juga sudah merupakan proyek yang cukup lama

  • Rocket adalah salah satu framework Rust awal yang mendorong pengalaman pengembang yang baik lewat procedural macro, tetapi di banyak bagian komunitas tampaknya popularitasnya sudah banyak menurun
    Selama waktu yang sangat lama, build-nya membutuhkan nightly Rust, dan bagi orang yang ingin memakai framework ini di lingkungan produksi, itu adalah kekurangan besar
    Selain itu, selama sekitar 2 tahun ia terjebak di status kandidat rilis 0.5.0, dan rilis stabil terbarunya tertinggal cukup jauh dibanding framework web Rust lain. Butuh nightly dan dukungan async juga masih belum ada
    Sekarang setelah melewati rintangan 0.5, mungkin keadaannya sudah membaik, tetapi riwayat pengembangan Rocket tetap membuat orang ragu memakainya dibanding alternatif seperti Axum

• Sebenarnya ada satu: Poem[1]
  Penulis menyebut Flask, tetapi kalau melihat bagian “yang dibutuhkan”, sulit juga mengatakan Flask memenuhi kebutuhan itu. Saya benar-benar tidak suka Django, tetapi untuk kebutuhan seperti itu, menurut saya yang paling dekat dengan deskripsi penulis justru Django
  Dari sisi itu, Poem juga bukan kandidat yang sempurna. Secara keseluruhan, Poem cukup mirip dengan FastAPI, dan itu lebih merupakan pujian. Saya sudah memakai lima atau enam framework web Rust, dan kebanyakan membuat saya harus banyak mengutak-atik boilerplate pada setup awal. Kalau ingin cepat menghasilkan sesuatu, itu jadi masalah, dan dalam hal itu Poem cocok
  actix memang punya performa yang sangat baik, tetapi kalau Anda tidak menargetkan respons di bawah 30ms, sejak awal tidak banyak alasan untuk melihat actix. Jika butuh sesuatu seperti Pydantic, ada crate yang lumayan menangani itu: https://crates.io/crates/poem-openapi
  [1] https://github.com/poem-web/poem

  • Bukan hanya Django, tetapi juga Rails, ASP .NET Core, dan banyak framework web batteries-included full-featured lainnya yang termasuk di sini
    Intinya adalah bahwa ini sebuah “framework”

• F# juga layak dicoba
  Hampir semua permainan sistem tipe yang diinginkan ada, dan alat serta fitur kenyamanan yang dibutuhkan juga tersedia. Kelemahan besarnya mungkin justru karena async dan manajemen memorinya tidak menyedot waktu sebanyak Rust, jadi ada risiko Anda malah benar-benar menyelesaikan kebutuhan bisnis yang nyata
  Meski begitu, proses berurusan dengan Microsoft mungkin bisa mengisi kekosongan itu di suatu titik

  • Bukankah F# membutuhkan mesin virtual .NET? Kebanyakan orang Rust yang saya kenal menyukai fakta bahwa semuanya selalu dikompilasi menjadi kode native, sifatnya bisa diprediksi, dan tidak ada keacakan waktu pemulihan garbage collection
  • Saya terus mempertimbangkan untuk mencoba F#
    Dibandingkan dengan OCaml atau Haskell, bagaimana?

• Pendapat yang mungkin tidak populer: Rust adalah bahasa sistem, dan melakukan pekerjaan web dengan Rust adalah pemborosan usaha
  Untuk kebutuhan itu ada bahasa dan ekosistem yang jauh lebih baik

  • Sanggahan: Mengembangkan layanan web dengan Rust sama mudahnya seperti dengan Go atau Java, dan Anda juga mendapatkan sistem tipe yang hebat (sum type!), package manager yang hebat, serta performa yang sangat baik
    Seperti di Java, di Rust Anda juga bisa melakukan dependency injection untuk berbagi connection pool, dan pekerjaan latar belakang berbasis thread juga bisa ditulis dengan sangat mudah
    Dalam presentasi terbaru, Google disebut mengukur bahwa pengembang Rust tidak kurang efisien atau kurang produktif dibanding pengembang Go [1]
    Rust adalah bahasa yang hebat, dan sama sekali tidak perlu dibatasi hanya untuk pemrograman sistem. Ia bisa melakukan jauh lebih banyak
    [1] https://www.ardanlabs.com/news/2024/rust-at-google/
  • Saya selalu memakai C/C++ untuk server web
    Ringan, mudah dan cepat untuk memanggil kode C/C++ dan kode level rendah, serta memberi banyak kontrol dalam networking. Tanpa perlu mempelajari bahasa khusus aplikasi seperti PHP atau file konfigurasi nginx/apache, hampir apa pun bisa dilakukan dengan cara yang umum dan intuitif
    Akan bagus kalau ada alternatif Rust untuk sesuatu seperti libmicrohttpd, dan kalau ada saya mungkin akan memakainya
  • Saya hampir sepenuhnya setuju, tetapi saya ingin menekankan bahwa irisan antara pemrograman sistem dan pemrograman web tidak kosong
    Hal yang sama juga berlaku untuk irisan antara pemrograman embedded dan pemrograman web
    Meski begitu, jika pilihan seperti Django, .Net, atau Go memungkinkan, Rust umumnya tetap cenderung menjadi pilihan yang buruk
  • Ini adalah investasi untuk efisiensi energi
  • Ini masuk akal pada sistem dengan keterbatasan memori atau CPU yang lebih berat daripada kasus umum
    Framework web yang dikompilasi secara statis bisa dengan mudah hanya memakai 1/10 sampai 1/100 memori/CPU dibanding Rails, Django, atau Flask

• Python punya Django, C# punya ASP .NET Core, Ruby punya Rails
  Jika Anda benar-benar ingin membesarkan Rust secara serius di pengembangan web, Anda harus membuat solusi full-featured
  Rocket mungkin yang paling dekat, tetapi tetap tidak sebatteries-included framework-framework yang disebut di atas

• Yang dicari penulis adalah versi Rust dari ASP.NET Core, dan tidak ada masalah dengan itu
  Ada orang yang suka pilihan dan perakitan sendiri, tetapi dalam banyak lingkungan, pendekatan yang sudah menyaring pilihan untuk Anda jauh lebih produktif
  Respons seperti “bagaimana kalau saya ingin X lain? Mungkin itu Y% lebih baik!” memang umum, tetapi itu melewatkan fakta bahwa integrasi itu sendiri memberi nilai yang sangat besar. Library individual mungkin yang terbaik jika dilihat terpisah, tetapi kalau tidak saling terhubung dengan mulus, hasilnya bisa jadi tumpukan sampah
  Salah satu alasan saya suka memrogram dengan ASP.NET 8 adalah karena saya sama sekali tidak perlu memikirkan apakah sistem templating akan cocok dengan autentikasi, injection, routing, dan sebagainya

• Tidak ada penyebutan loco-rs, poem, rocket? Sudah ada cukup banyak proyek yang memang menargetkan pengalaman batteries-included
  Yang membedakan proyek-proyek ini dari framework seperti leptos adalah adanya CLI yang memandu. Itu juga yang saya suka dari Symfony, dan menurut saya di situlah bagian “malas”-nya

• Ada https://shuttle.rs
  Bukan sekadar framework, tetapi juga alat yang menghasilkan boilerplate web di sekitarnya, jadi menurut saya ini sudah cukup cara malas

• Tulisan ini membahas beberapa poin berbeda sekaligus, jadi idealnya masing-masing dibahas terpisah
  Jika ada pattern matching, router tidak selalu diperlukan. Cukup pecah URL lalu cocokkan variabel statis/dinamis sesuai kebutuhan
  Autentikasi, dalam bahasa apa pun, biasanya dibuat sendiri atau menggunakan SaaS seperti Firebase/Auth0, jadi ini tidak selalu merupakan masalah bahasa atau framework
  Alat CSS/JS juga tidak terlalu cocok dengan banyak framework frontend Rust seperti Dominator. Dominator ditulis dalam Rust, bukan JS, dan punya pendekatan styling sendiri seperti menempelkan style ke signal agar berubah secara real-time
  Saya paham maksud penulis. Saya sendiri sudah beberapa kali berkeliling mencoba menyelesaikan berbagai poin di tulisan ini, dan memang menyakitkan. Misalnya, https://github.com/dakom/dominator-workers-fluent-auth menangani banyak tugas yang disebut di sini di atas framework Cloudflare Workers, sekaligus menambahkan lokalisasi berbasis Fluent sebagai fitur tambahan yang diharapkan
  Akan bagus jika ada framework lengkap dengan baterai terpasang yang melakukan semuanya, tetapi banyak proyek nyata kemungkinan ingin mengubah keputusan yang terlalu mengikat seperti itu dan memilih mengimplementasikannya sendiri. Rust sudah cukup matang bahkan untuk web frontend, dan jika tahu harus melihat ke mana, semuanya bisa ditangani dengan wasm-bindgen dan sebagainya

  • “Jika ada pattern matching, router tidak diperlukan” itu tidak memadai
    Framework web menyediakan jauh lebih banyak hal seperti pengalihan URL, penanganan trailing slash, pengelolaan URL peka huruf besar-kecil, pencocokan regex yang kompleks, dan sebagainya
    “Autentikasi, dalam bahasa apa pun, biasanya dibuat sendiri atau memakai SaaS” itu salah. Django, Laravel, Rails, dan bahasa dengan baterai terpasang punya manajemen autentikasi yang sangat baik. Secara pribadi, saya melihat bahwa di 90% organisasi, menyerahkan autentikasi ke pihak luar adalah kesalahan besar
    Fakta bahwa pengembang web berpengalaman bisa langsung menyiapkan 10 CRUD dasar dalam satu hari tanpa harus menangani kompleksitas yang tidak perlu adalah keuntungan yang benar-benar besar bagi usaha kecil

• Jika tulisan ini berfokus pada C++ alih-alih Rust, apakah sebagian besar hal yang sama juga akan berlaku?
  Ini adalah bahasa sistem dengan hambatan masuk yang tinggi, ada waktu kompilasi, dan bahasa ini juga belum genap 10 tahun digunakan secara luas, jadi tidak realistis berharap ia bersaing dengan hal seperti Rails dalam hal kemudahan akses