Masalah yang Diselesaikan tRPC

Saat Anda membangun REST API dalam TypeScript, server menentukan bentuk respons. Klien harus membuat tipe TypeScript yang sesuai secara manual. Seiring perkembangan API, tipe-tipe ini dapat menyimpang, dan kompilator tidak dapat mendeteksi ketidakcocokan tersebut karena tipe-tipe itu ditentukan dalam paket yang terpisah.

Nama bidang yang diubah di server menjadi galat saat berjalan yang tidak terlihat di klien.

GraphQL mengatasi penyimpangan tipe dengan membuat tipe TypeScript dari skema menggunakan alat seperti graphql-codegen. Cara ini bekerja dengan baik, tetapi menambah kerumitan: bahasa kueri terpisah (GraphQL SDL), langkah pembuatan kode dalam alur pembangunan, dan alat pengelolaan skema.

Untuk tim yang sudah menggunakan GraphQL, pembuatan kode merupakan jawaban yang tepat. Untuk tim yang menginginkan keamanan tipe tanpa kerumitan tambahan GraphQL, tRPC menawarkan alternatif.

Pendekatan tRPC sangat sederhana: tentukan prosedur API di server sebagai fungsi TypeScript, ekspor tipe router, lalu impor tipe tersebut di klien. Tidak ada pembuatan kode. Tidak ada bahasa skema terpisah.

Kompilator TypeScript sendiri memberlakukan kontrak antara klien dan server saat pembangunan.

tRPC mengharuskan server dan klien berbagi tipe melalui impor TypeScript. Cara ini berjalan alami dalam monorepo (Turborepo, Nx, pnpm workspaces), tempat server dan klien merupakan paket terpisah yang dapat saling mengimpor.

Untuk backend dan frontend yang sepenuhnya terpisah, Anda perlu menerbitkan tipe router sebagai paket bersama. Hal ini menambahkan langkah penerbitan, tetapi tetap tidak memerlukan pembuatan kode.

Di server, Anda menentukan router dan mengekspor tipenya: export type AppRouter = typeof appRouter. Di klien, Anda mengimpor tipe tersebut dan membuat klien bertipe: createTRPCReact<AppRouter>(). Klien mengetahui dengan tepat prosedur apa saja yang tersedia serta tipe masukan dan keluarannya.

Mengubah nama prosedur di server akan segera menampilkan galat TypeScript di klien.

Karena tRPC menggunakan sistem tipe TypeScript secara langsung, editor Anda menyediakan pelengkapan otomatis penuh untuk nama prosedur, bentuk masukan, dan tipe nilai kembalian di sisi klien. Mengubah nama prosedur merupakan pemfaktoran ulang nama TypeScript, bukan pencarian dan penggantian manual di seluruh codebase.

Peningkatan pengalaman pengembang ini merupakan fitur tRPC yang paling banyak dipuji dalam praktik.

Secara bawaan, tRPC menggunakan HTTP sebagai transportasinya. Setiap pemanggilan prosedur merupakan permintaan HTTP. tRPC juga mendukung WebSockets untuk subscription. Transportasi ini merupakan detail implementasi; API klien tetap sama terlepas dari transportasi yang digunakan.

Anda juga dapat mengekspos prosedur tRPC sebagai titik akhir REST konvensional menggunakan adaptor REST agar kompatibel dengan klien non-tRPC.

tRPC berfungsi sebagai middleware dalam Express, Fastify, dan Hono. Untuk Next.js, tRPC terintegrasi melalui penangan rute API. Starter create-t3-app (T3 Stack) menggabungkan tRPC, Prisma, NextAuth, dan Tailwind ke dalam template Next.js untuk seluruh tumpukan.

T3 Stack merupakan titik awal tRPC yang paling populer dan menunjukkan pola yang siap digunakan dalam produksi.

Pendekatan REST lain yang aman secara tipe adalah menentukan skema Zod, membuat spesifikasi OpenAPI secara otomatis, lalu membuat tipe TypeScript dari spesifikasi tersebut. Cara ini menyediakan kontrak API yang dapat digunakan oleh klien non-TypeScript.

tRPC lebih sederhana, tetapi hanya untuk TypeScript. OpenAPI+Zod menambah kerumitan, tetapi menghasilkan kontrak API publik. Pilih tRPC untuk komunikasi internal TypeScript-ke-TypeScript; pilih OpenAPI untuk API publik.

tRPC bukan pengganti REST jika Anda memerlukan API publik yang digunakan pihak ketiga, klien seluler yang tidak ditulis dalam TypeScript, atau mitra yang memerlukan kontrak berversi yang stabil. tRPC secara khusus ditujukan untuk monorepo TypeScript dengan keamanan tipe di seluruh tumpukan.

Memahami cakupan ini mencegah Anda mengadopsi tRPC dalam konteks ketika REST atau GraphQL lebih sesuai.

Menjalankan npm create t3-app@latest akan membuat kerangka awal proyek Next.js dengan tRPC, Prisma, NextAuth.js, Tailwind CSS, dan TypeScript yang telah dikonfigurasi sebelumnya. Kode yang dihasilkan menunjukkan struktur router, pembuatan konteks, dan penyiapan klien.

Mempelajari kerangka awal ini adalah cara tercepat untuk memahami bagaimana semua bagian tRPC saling terhubung dalam aplikasi nyata.

Bagaimana tRPC membagikan tipe antara server dan klien tanpa pembuatan kode?

tRPC mengatasi perbedaan tipe antara klien dan server TypeScript dengan membagikan tipe TypeScript router secara langsung melalui impor, sehingga pembuatan kode tidak diperlukan. tRPC dapat digunakan dalam monorepo dan terintegrasi dengan Next.js, Express, Fastify, serta Hono. T3 Stack (create-t3-app) adalah kerangka awal standar untuk produksi.

tRPC hanya mendukung TypeScript dan paling sesuai untuk aplikasi full-stack internal, bukan API publik.