Go, templ, HTMX, Postgres — dan kenapa kami nggak pakai React

Buat yang penasaran isi dapurnya, ini tumpukan teknologi Wizzy:

• Go — bahasa server
• Chi — router HTTP
• templ — templat yang dikompilasi jadi Go, jadi kesalahan ketik ketahuan waktu build
• HTMX — buat interaksi yang perlu, tanpa kerangka kerja JavaScript
• TailwindCSS — gaya tampilan
• PostgreSQL — database, dan sekaligus antrean pekerjaan latar belakang

Nggak ada React. Nggak ada Redis. Nggak ada layanan mikro. Hasil akhirnya satu program dan satu database, dan itu yang jalan di server.

Kenapa nggak React

Bukan karena React jelek. React jelas jawaban yang bener buat sebagian aplikasi.

Alasannya lebih membosankan: Wizzy sebagian besar isinya halaman yang nampilin data dan formulir yang ngirim data. Buat pekerjaan itu, render di server udah cukup, dan lebih cepat sampai ke layar orang.

Konteksnya penting. Mayoritas besar pengguna kami buka dari HP Android kelas menengah. Di perangkat itu, selisih antara halaman yang langsung jadi dan halaman yang harus ngunduh serta menjalankan bundel JavaScript dulu itu kerasa banget — bukan selisih milidetik di grafik, tapi selisih antara kepakai dan bikin sebel.

HTMX nutup sisanya. Kalau cuma sebagian halaman yang perlu berubah, dia minta potongan HTML ke server dan nempelin. Nggak ada status yang harus disinkronkan antara server dan browser, karena statusnya cuma ada satu tempat.

Pengecualiannya, dan kenapa itu boleh

Ada satu bagian yang nggak ngikutin aturan di atas: kanvas untuk membangun alur otomatis. Itu editor visual dengan simpul yang bisa diseret, disambung, dan diatur letaknya — dan itu memang bukan pekerjaan yang cocok buat render di server.

Jadi bagian itu satu-satunya pulau JavaScript di Wizzy, dan dikurung ketat di satu elemen di satu halaman.

Kami sebut ini karena artikel bergaya "kami nggak butuh JavaScript" yang menyembunyikan pengecualiannya itu bikin orang salah menilai. Aturannya bukan "JavaScript itu haram" — aturannya "pakai kalau pekerjaannya emang minta". Editor kanvas emang minta. Formulir kontak nggak.

Postgres sebagai antrean pekerjaan

Keputusan kedua yang sering ditanyain: unduhan, konversi video, dan pekerjaan berat lain masuk antrean, dan antreannya ada di Postgres — bukan Redis atau layanan antrean khusus.

Postgres bisa ngasih satu baris pekerjaan ke satu pekerja secara aman tanpa dua pekerja ngambil pekerjaan yang sama. Fitur ini udah ada bertahun-tahun dan stabil.

Yang kami hemat bukan uang sewa server. Yang kami hemat satu sistem yang harus dipantau, dicadangkan, dan dipahami waktu jam dua pagi ada yang rusak. Buat tim kecil, jumlah bagian yang bergerak itu biaya paling mahal yang jarang dimasukkan hitungan.

Yang kami korbankan

Biar seimbang, ini yang jadi lebih susah:

• Interaksi yang sangat rumit lebih repot dibikin. Kalau suatu saat kami butuh banyak antarmuka sekelas kanvas tadi, keputusan ini bakal terasa sempit.
• Kolam pelamar kerja lebih kecil. Jauh lebih banyak orang yang tahu React daripada yang tahu templ.
• Nggak ada aplikasi seluler asli, dan itu keputusan tersendiri.

Kami pilih ini sadar bahwa suatu hari mungkin harus berubah. Kalau produknya menuntut, kami bakal pakai alat lain — yang kami hindari itu bayar ongkos kerumitan sekarang buat kebutuhan yang belum ada.

Ukurannya buat kami

Deploy itu satu perintah. Menjalankan seluruh aplikasi di laptop buat mengembangkan itu satu perintah. Orang baru bisa baca satu berkas dan tahu semua rute yang ada.

Selama tiga hal itu masih benar, kami belum punya alasan buat ganti.

Bacaan lanjutan: halaman depan kami nggak nanam skrip pelacak.