Seorang pengembang menghabiskan dua minggu untuk mengganti REST API dengan tRPC dalam sebuah alat internal.

Mengapa peralihan ini penting

Stack lama memaksa kami untuk memelihara DTO, validator, dan set tipe TypeScript terpisah untuk frontend. Ubah nama field di backend, dan API tetap mengembalikan status 200, UI terus merender, dan bug baru muncul hanya sebagai nilai “undefined”. Seorang pelanggan menemukan masalah tersebut sebelum ada anggota tim yang menyadarinya. Kontrak REST menyembunyikan masalah tersebut, dan file tambahan menambah beban pemeliharaan yang tidak pernah sebanding dengan hasilnya.

Seperti apa pengaturan REST sebelumnya

  • OpenAPI spec – sebuah file statis yang mendeskripsikan endpoint tetapi tidak pernah berfungsi sebagai sumber kebenaran (source of truth).
  • Langkah pembuatan Client SDK – sebuah pekerjaan CI yang menghasilkan wrapper JavaScript.
  • Koleksi Postman – artefak pengujian bersama yang tidak digunakan oleh siapa pun.
  • Interface TypeScript manual – tipe yang ditulis tangan yang harus tetap sinkron dengan server.

Setiap perubahan API menyentuh setidaknya tiga dari artefak tersebut, ditambah validator dan setiap panggilan fetch hilir (downstream). Prosesnya rentan terhadap kesalahan dan lambat.

Bagaimana tRPC merampingkan codebase

tRPC menghilangkan file kontrak yang terpisah. Server mengekspor tipe router; client mengimpor tipe yang sama tersebut. Ubah nama field di backend, dan editor akan langsung menandai ketidakcocokan tersebut—tanpa perlu menjalankan kode atau menunggu permintaan gagal. Pengembang menghapus:

  • File OpenAPI spec.
  • Langkah pembuatan client SDK.
  • Koleksi Postman yang tidak terpakai.
  • Folder interface TypeScript manual.

Repositori menjadi lebih ramping, dan umpan balik muncul selama pengembangan, bukan setelah deployment.

Batasan tRPC

tRPC hanya berfungsi ketika kedua sisi menggunakan TypeScript. tRPC kurang efektif jika:

  • Tim mobile menggunakan Swift atau Kotlin.
  • API harus dikonsumsi oleh mitra eksternal.
  • Anda membutuhkan antarmuka publik yang bersifat language-agnostic.

Apa yang sebenarnya dibutuhkan dalam migrasi ini

Upaya selama dua minggu tersebut lebih dari sekadar salin-tempel. Pengembang harus:

  • Menulis ulang setiap panggilan fetch untuk menggunakan fungsi client tRPC.
  • Menyesuaikan logika penanganan kesalahan (error-handling).
  • Memperbarui komponen UI yang bergantung pada status pemuatan (loading) dan percobaan ulang (retry) yang terikat pada respons HTTP mentah.

Pertanyaan yang perlu diajukan sebelum Anda beralih

  • Apakah frontend dan backend sama-sama menggunakan TypeScript? Tanpa sistem tipe yang terbagi, tRPC kehilangan keunggulan utamanya.
  • Apakah tim yang sama bertanggung jawab atas kedua sisi? Kesenjangan kepemilikan dapat memicu kembali ketidaksesuaian kontrak (contract drift).
  • Apakah Anda memperbaiki bug nyata atau sekadar mengikuti tren? Peningkatan produktivitas itu nyata, tetapi hal ini harus mampu menyelesaikan masalah yang ada.

Pendekatan hibrida untuk 2025

Banyak tim menemukan titik keseimbangan dengan menjalankan kedua stack tersebut:

  • tRPC untuk lapisan aplikasi internal di mana codebase sepenuhnya menggunakan TypeScript dan tim yang sama memiliki server serta client.
  • REST untuk webhook, API publik, dan integrasi mitra di mana akses yang bersifat language-agnostic diperlukan.

Menggunakan alat yang tepat untuk setiap permukaan menjaga pengembangan internal tetap cepat sambil tetap mempertahankan keterbukaan yang dibutuhkan bagi konsumen eksternal.

Kesimpulan: Mengganti REST dengan tRPC dapat menghilangkan duplikasi artefak kontrak dan memunculkan bug pada saat pengeditan, tetapi keuntungan tersebut hanya akan terasa jika seluruh stack menggunakan TypeScript dan tim mampu menyerap biaya migrasi. Strategi campuran memungkinkan Anda memetik manfaatnya tanpa menutup akses bagi konsumen non-TypeScript.