Backend baru untuk pembangun komunitas open source TSBOARD: GOAPI

Sekitar 7 bulan yang lalu saya pertama kali memperkenalkan proyek TSBOARD.

Saat itu frontend dan backend sama-sama ditulis dengan TypeScript, dan untuk menjalankan backend digunakan runtime Bun.

Namun karena berbagai alasan, saya membuat ulang backend dari nol, lalu merilisnya secara terbuka di repositori GitHub yang terpisah dari proyek TSBOARD yang ada. Backend baru ini ditulis dalam bahasa Go, dan akan disertakan bersama versi resmi TSBOARD dalam bentuk biner.

---

Mengapa membuat ulang backend?

• Runtime Bun benar-benar menunjukkan performa yang luar biasa. Namun, meski diperkenalkan sebagai toolkit all-in-one, pengelolaan paketnya masih belum bisa menyaingi npm.
• Karena itu, untuk menggunakan TSBOARD dibutuhkan dua runtime sekaligus: Node.js dan Bun. Ini merepotkan, dan dari sudut pandang pengguna juga tidak nyaman.
• Sekarang masalah itu sudah diperbaiki, tetapi pada masa awal ada masalah Bun tidak berjalan di vCPU virtual, dan situasi ketika bahkan saya sendiri sebagai pengembang tidak bisa memasangnya di server lain terasa sangat fatal.
• (Seperti yang ditunjukkan orang lain) memang bisa diatasi dengan orkestrasi, tetapi saya tetap ingin melampaui keterbatasan bawaan runtime JS yang bagaimanapun berbasis single-thread, dan memanfaatkan banyak thread.
• Saya membutuhkan lebih banyak tipe. Hanya dengan TypeScript, rasa haus itu tidak terpuaskan.

Mengapa memilih bahasa Go?

• Untuk backend baru, saya ingin 1) bisa dikompilasi, 2) pengelolaan memori ditangani otomatis, dan 3) tidak perlu memasang sesuatu seperti runtime terpisah.
• Setelah mempertimbangkan Rust, Kotlin, Python, PHP, dan Go, saya akhirnya memilih Go, yang memenuhi ketiga syarat di atas meskipun merupakan bahasa yang benar-benar baru bagi saya. (Maaf, PHP)
• Yang paling saya suka adalah kesederhanaan Go, dan kemiripannya dengan TypeScript juga menjadi poin penting dalam keputusan ini. Di atas segalanya, saya rasa ini pilihan yang baik dibanding alternatif lain dalam hal pengelolaan konkurensi dan memori.

Bagaimana rasanya setelah memakai Go?

• Saya menyadari bahwa Go juga membuktikan tidak ada bahasa di dunia yang hanya punya kelebihan. if err != nil { } memang mutlak diperlukan, tetapi sungguh merepotkan. Kadang saya cukup merindukan try catch finally.
• Mungkin ini masalah di go-mysql-driver, tetapi dalam lingkungan pengembangan nyata yang memiliki bottleneck berupa DB I/O, performanya tidak berjalan secepat itu. (Lihat juga tulisan yang pernah saya unggah di GeekNews: https://id.news.hada.io/topic?id=18048)
• Penerapan interface implisit masih terasa agak canggung. Apakah mereka memang tidak ingin memakai keyword seperti implements atau extends?
• Pointer justru terasa menyenangkan. Terutama karena saya tidak perlu memikirkan kapan memori harus dibebaskan!
• Berbagai tipe, struct yang sederhana tetapi kuat, dan slice benar-benar favorit. Yang paling saya suka adalah jumlah keyword yang sedikit sehingga bisa cepat dipelajari dan langsung dipakai.
• Bisa memakai lightweight thread seperti sihir hanya dengan keyword go...! Saya bahagia!

Kesan setelah mengganti backend dari berbasis runtime JS ke Go...?

• Sekali saja cukup untuk melakukan hal seperti ini.
• Saya melakukan berbagai pengujian sambil melakukan benchmarking pada bagian DB I/O, dan dari sudut pandang performa, sebenarnya sulit merasakan perbedaan besar antara runtime JS dan biner Go. Misalnya, pustaka gambar yang banyak dipakai di JS seperti sharp juga tetap menggunakan pustaka libvips, dan tidak ada aplikasi web yang sama sekali tidak memiliki DB I/O.
• Meski begitu, walaupun saya sudah bersusah payah, saya tetap merasa keputusan ini tepat, dan ke depannya saya berencana terus memakai Go untuk backend.
  • Penggunaan memori benar-benar turun ke tingkat yang sangat berarti. Tentu kalau dikembangkan dengan Rust mungkin bisa dioptimalkan lebih jauh, tetapi untuk harga yang dibayar demi bisa memakai GC, tingkat ini sudah lebih dari cukup memuaskan.
  • Kesederhanaan bahasanya sendiri benar-benar luar biasa. Keyword yang harus dihafal sedikit, pola penggunaannya pun kebanyakan sudah jelas, jadi mudah dipelajari. (Tentu, menggunakannya dengan baik adalah cerita lain.) Saya juga sangat menyukai bahwa tipe primitif yang disediakan cukup beragam.
  • Yang paling memuaskan adalah, setelah dikompilasi, selama ada binernya maka program bisa langsung dijalankan. Saya tidak lagi ingin harus memasang sesuatu tambahan demi menjalankan backend, lalu mengeksekusi ulang kode lewat itu.

Bagaimana cara menggunakannya?

• Sayangnya lingkungan Windows tidak didukung. Cukup jalankan biner di lingkungan Linux/Mac.
• Pustaka libvips harus sudah terpasang terlebih dahulu di server yang digunakan. Ini karena biner tersebut memanfaatkan fungsi-fungsi dari pustaka itu untuk pemrosesan gambar.
• Rincian lebih lanjut dijelaskan di file README.md.

---

Masih banyak kekurangan, dan saya tetap menantikan masukan dari para pengembang lain. Sampai-sampai saya menyesali diri saya sendiri yang terlalu ragu-ragu saat acara GeekNight. Laporan bug, usulan perbaikan, maupun pendapat yang berbeda, semuanya saya sambut dengan senang hati.

Tahun ini bulan Desember terasa sangat berat, tetapi saya tetap berharap di tahun baru nanti ada masa depan yang sedikit lebih baik. Terima kasih sudah membaca tulisan panjang ini. Sebagai penutup, saya membagikan tautan catatan rilis TSBOARD v1.0.0 di bawah ini.

https://tsboard.dev/board/free/47

[angkr]

Saya melihatnya di Damoang.
Ini adalah CMS yang sangat menjanjikan. Terima kasih

[tsboard]

Saya juga kaget karena ada orang di Damoang yang masih mengingat saya. Hehe, saya akan berusaha lebih keras agar bisa memenuhi harapan itu! 😊

[dongho42]

Bermanfaat!

[tsboard]

Terlambat, tapi terima kasih atas komentarnya! 😃

[jongyeol]

Penerapan interface implisit masih terasa agak canggung. Apakah mereka memang tidak ingin memakai kata kunci seperti implements atau extends?

Ada kelebihan dan kekurangannya, tetapi sebagai kelebihan, kadang saya merasa enak karena tanpa memodifikasi kode library standar/eksternal, saat memakai implementasi yang dibuat orang lain, sebagian darinya bisa saya perlakukan sebagai interface yang saya buat sendiri. Mirip seperti FunctionalInterface di Java, atau seperti menerapkan duck typing ke bahasa yang dikompilasi. Sebaliknya, jika harus selalu mendeklarasikan implements/extends, untuk menempelkannya ke interface yang saya buat, saya malah harus membuat Adapter di tengah.

Sebagai kekurangan, ketika menambah/menghapus/mengubah method pada interface, posisi munculnya error jadi berbeda dibanding bahasa static typing lain, sehingga agak kurang nyaman.

[tsboard]

Ah begitu ya! Ternyata ada kelebihan yang sama sekali tidak terpikirkan oleh saya. Untungnya, untuk pesan error sepertinya gopls? Ekstensi bahasa Go di VS Code cukup bagus dalam menangkap hal-hal yang terlewat atau implementasi yang salah, jadi saya bisa cepat menemukannya. Kalau sudah lebih terbiasa, sepertinya suatu saat saya juga akan bisa memakainya dengan lebih baik. Hehe, terima kasih sudah menjelaskannya lewat komentar! Semoga Tahun Baru Anda penuh berkah~!

[ifmkl]

Kerja keras Anda luar biasa! Saya juga akan mencoba mengunggahnya ke server uji! Semoga sukses terus di Tahun Baru 2025!

[tsboard]

Terima kasih! Silakan dicoba, dan jika ada yang tidak berjalan dengan baik atau ada hal yang ingin ditanyakan, jangan ragu untuk memberi tahu kami kapan saja! Selamat Tahun Baru~!

[channprj]

Saya mendukung~ 👍🏻

[tsboard]

Terima kasih atas dukungannya!!! Selamat Tahun Baru~!

[zihado]

Semangat!

[tsboard]

Terima kasih!!! Selamat Tahun Baru!!