Seorang pembangun menghabiskan masa dua minggu untuk menukar REST API kepada tRPC dalam satu alatan dalaman.

Mengapa pertukaran ini penting

Stak lama memaksa kami menyelenggara DTO, validator, dan set jenis TypeScript yang berasingan untuk bahagian hadapan (frontend). Tukar nama medan backend, dan API masih mengembalikan 200, UI terus dipaparkan, dan pepijat hanya muncul sebagai nilai “undefined”. Pelanggan mengesan isu tersebut sebelum sesiapa pun dalam pasukan menyedarinya. Kontrak REST menyembunyikan masalah tersebut, dan fail tambahan menambah beban penyelenggaraan yang tidak mendatangkan hasil.

Gambaran tetapan REST

  • Spesifikasi OpenAPI – fail statik yang menerangkan titik akhir (endpoints) tetapi tidak pernah berfungsi sebagai sumber kebenaran (source of truth).
  • Langkah penjanaan SDK klien – tugasan CI yang menghasilkan pembungkus (wrapper) JavaScript.
  • Koleksi Postman – artifak ujian dikongsi yang tidak digunakan oleh sesiapa.
  • Antara muka TypeScript manual – jenis yang ditulis tangan yang perlu sentiasa selari dengan pelayan.

Setiap perubahan API melibatkan sekurang-kurangnya tiga daripada artifak tersebut, ditambah dengan validator dan sebarang panggilan fetch hiliran. Proses tersebut mudah terdedah kepada ralat dan perlahan.

Bagaimana tRPC meringkaskan kod asas (codebase)

tRPC menghapuskan fail kontrak yang berasingan. Pelayan mengeksport jenis router; klien mengimport jenis yang sama. Tukar nama medan backend, dan editor akan menandakan ketidakpadanan dengan serta-merta—tanpa perlu menjalankan kod atau menunggu permintaan gagal. Pembangun telah membuang:

  • Fail spesifikasi OpenAPI.
  • Langkah penjanaan SDK klien.
  • Koleksi Postman yang tidak digunakan.
  • Folder antara muka TypeScript manual.

Repositori menjadi lebih ramping, dan maklum balas diterima semasa pembangunan dan bukannya selepas penggunaan (deployment).

Had tRPC

tRPC hanya berfungsi apabila kedua-dua hujung menggunakan TypeScript. Ia mempunyai kekurangan jika:

  • Pasukan mudah alih menggunakan Swift atau Kotlin.
  • API mesti digunakan oleh rakan kongsi luaran.
  • Anda memerlukan antara muka awam yang tidak bergantung pada bahasa pengaturcaraan (language-agnostic).

Apa yang sebenarnya diperlukan untuk migrasi

Usaha selama dua minggu itu lebih daripada sekadar salin-dan-tampal. Pembangun perlu:

  • Menulis semula setiap panggilan fetch untuk menggunakan fungsi klien tRPC.
  • Melaraskan logik pengendalian ralat.
  • Mengemas kini komponen UI yang bergantung pada keadaan pemuatan (loading) dan cubaan semula (retry) yang terikat dengan respons HTTP mentah.

Soalan untuk ditanya sebelum anda bermula

  • Adakah bahagian hadapan dan belakang menggunakan TypeScript? Tanpa sistem jenis yang dikongsi, tRPC kehilangan kelebihan utamanya.
  • Adakah pasukan yang sama bertanggungjawab untuk kedua-dua belah pihak? Jurang pemilikan boleh menyebabkan ketidakselarasan kontrak (contract drift) berlaku semula.
  • Adakah anda sedang membaiki pepijat yang nyata atau sekadar mengikut trend? Peningkatan produktiviti adalah nyata, tetapi ia sepatutnya menyelesaikan masalah (pain point) yang sedia ada.

Pendekatan hibrid untuk 2025

Banyak pasukan menemui titik keseimbangan dengan menjalankan kedua-dua stak:

  • tRPC untuk lapisan aplikasi dalaman di mana kod asas adalah sepenuhnya TypeScript dan pasukan yang sama memiliki pelayan dan klien.
  • REST untuk webhook, API awam, dan integrasi rakan kongsi di mana akses yang tidak bergantung pada bahasa diperlukan.

Menggunakan alatan yang betul untuk setiap permukaan memastikan pembangunan dalaman kekal pantas sambil mengekalkan keterbukaan yang diperlukan untuk pengguna luaran.

Rumusan: Menggantikan REST dengan tRPC boleh menghapuskan artifak kontrak yang bertindih dan mendedahkan pepijat semasa waktu penyuntingan, tetapi manfaatnya hanya akan terhasil apabila keseluruhan stak berkongsi TypeScript dan pasukan mampu menyerap kos migrasi. Strategi campuran membolehkan anda menuai manfaat tanpa menyekat pengguna bukan TypeScript.