Ngoprek Twirp RPC Framework

Sedikit konteks

Terinspirasi dari talk di channel Insinyur Online tentang Pursuit of Production Ready Software, saya terdorong untuk memulai sesi oprek dan mendokumentasikan-nya dalam beberapa media, salah satunya tulisan ini. (ini cuap cuap saja, sebenarnya saya tertarik hadiah buku-nya wqwq).

Salah satu topik yang sedang saya pelajari adalah tentang Sistem Terdistribusi, dan masih jadi, misteri buat saya gimana caranya membuat komunikasi antar aplikasi yang reliable, scalable dan maintanable (sesuai dengan 3 attributes membuat aplikasi siap guna).

Tapi saya tidak akan membahas dari segi 3 attributes diatas, karena saya ada masalah lain yang ingin telusuri.

Permasalahan

Saat proyek baru dimulai, mengembangkan komunikasi aplikasi sistem terdistribusi dengan REST API mungkin belum muncul banyak masalah, tapi masalah mulai terasa ketika API endpoint terus bertambah seiring penambahan fitur, Pengembang yang terlibat juga bertambah seiring perkembangan organisasi.

Sehingga setiap menulis sebuah endpoint baru, muncul pertanyaan sbb.

• Data apa yang harus dikembalikan?
• Bagaimana bentuk data yang dikembalikan?
• Bagaimana mengkomunikasi-kan error?
• Headers apa saja yang perlu dikembalikan?
• Bagaimana mengatur versioning?
• dan banyak lagi…..wqwq

Belum ada-nya standarisasi menambah runyam kondisi ini, jadi saya mencari sebuah petunjuk, dan menemukan sebuah konsep yang bernama Remote Procedural Call selanjutnya disebut RPC¹. Saya juga breakdown masalah ini dalam bentuk mindmap.

Apa itu RPC?

Yang saya tangkap, RPC ini adalah sebuah fungsi yang sebenarnya di-eksekusi di mesin berbeda dimana fungsi ini dipanggil, namun karena RPC sudah menyembunyikan implementasi-nya, kita seolah-olah memanggil fungsi tersebut dari fungsi utama.

Karena sedang belajar Golang, saya mencari sebuah implementasi RPC dan menemukan Twirp. Module ini menurut saya menarik karena dibuat oleh Twitch dan sudah digunakan secara production, katanya sih begitu, mari kita gali lagi.

Twirp sebuah Framework RPC ditulis dengan Golang

Mengapa memilih Twirp, dari tulisan blog² ini saya menemukan beberapa hal menarik sbb.

• RPC terstruktur lebih mudah di design dan maintain daripada REST API yang berorientasi URL. (ini saya relate banget)
• Penulis blog post ini mengatakan, yang diperlukan adalah standarisasi bentuk URL, bentuk request, response dan error messages. (wah pas banget, sesuai yang saya cari)
• Bisa jalan di HTTP 1.1 dan support JSON serialization, legacy project pastinya menyukai hal ini, tidak perlu takut menghadapi keribetan menggunakan grpc, yang saya sendiri belum tahu itu apa.

Bagaimana caranya menggunakan Twirp?

Output dari sesi oprek kali ini adalah menghasilkan proof of concept sbb.

1. Membuat implementasi client dan server menggunakan definisi protobuf dan Twirp
2. Membuat implementasi client dari browser

Lebih detail tentang langkah-langkah oprekan ini, saya rekam dalam catatan yg lebih kasar disini.

Kesimpulan

Pro

• Mengurangi menulis definisi request dan response sebuah aplikasi dengan manual, cukup tulis protobuf definition dan generate code-nya
• Tersedia generator untuk berbagai bahasa seperti Javascript dan Typescript
• Support JSON memudahkan proses debugging
• Menurut saya bisa jadi alternatif teknologi seperti GraphQL
• Definisi protobuf mudah di export ke format OpenAPI, ini berguna buat bikin dokumentasi.

Kontra

• Belum ada pengalaman menggunakan-nya di aplikasi siap guna / production ready
• Masih belum yakin bagaimana strategi adopsinya pada project yang multi-repo

Catatan Kaki