tRPC Lebih Baik dari JSON API?

Pernah ngerasa FOMO saat dengar teknologi baru? Tiba-tiba semua orang di Twitter ngomongin tRPC, katanya lebih keren, lebih aman, lebih magic. Kamu pun mulai bertanya-tanya, “Apa selama ini aku salah pakai JSON API?”

Tenang, Kamu tidak sendirian.

Seperti halnya dulu ada REST API, lalu GraphQL, gRPC, sekarang muncul lagi namanya tRPC. Dan pertanyaan besarnya: Apakah tRPC benar-benar lebih baik dari JSON API? Atau cuma hype belaka?

Di artikel ini, aku bakal bongkar habis tRPC dari sisi teknis, kelebihan, kekurangan, dan kasus penggunaan yang tepat. Siap-siap, karena jawabannya mungkin tidak sesuai ekspektasi Kamu.

Apa Itu tRPC? Bukan Sekadar Singkatan Baru

tRPC kepanjangannya TypeScript Remote Procedure Call. Kalau diurai:

• TypeScript → bahasa pemrograman
• Remote Procedure Call → mekanisme memanggil fungsi dari jarak jauh

Bedanya dengan RPC biasa? tRPC dibuat khusus untuk ekosistem TypeScript. Server pakai TS, klien pakai TS, dan mereka bisa binding secara otomatis.

🎯 Inti utamanya: Kamu bisa memanggil fungsi backend seolah-olah fungsi lokal di frontend. Tanpa manual menulis endpoint HTTP, tanpa repot membuat dokumentasi API.

Tapi tunggu dulu… sebelum kamu terlalu bersemangat, mari kita lihat gimana sih cara kerjanya?

Cara Kerja tRPC: The “Magic” yang Sebenarnya

🔍 Yang Kamu Lihat di Kode

// Server
const userRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(({ input }) => {
      return { id: input.id, name: "Yamada Elf", email: "[email protected]" };
    })
});

// Client - Seperti ajaib!
const user = await client.getUser.query({ id: "123" });

Kelihatan magic kan? Langsung manggil getUser seperti fungsi lokal.

⚙️ Yang Terjadi di Balik Layar (Low-Level)

Inilah fakta yang jarang diungkap: tRPC tetap menggunakan HTTP dan JSON.

Berdasarkan analisis source code-nya:

1. JavaScript Proxy digunakan untuk menangkap panggilan fungsi di client
2. Panggilan tersebut diterjemahkan menjadi HTTP request
3. URL endpoint diambil dari nama prosedur (contoh: http://localhost:3000/getUser)
4. Input tetap dikirim sebagai JSON di body request
5. Response yang diterima juga JSON biasa

// Inilah yang SEBENARNYA terjadi di network
POST /getUser HTTP/1.1
Content-Type: application/json

{"id": "123"}

// Response
{
  "result": {
    "data": {
      "id": "123",
      "name": "Yamada Elf",
      "email": "[email protected]"
    }
  }
}

Jadi kesimpulannya? tRPC adalah abstraction layer di atas HTTP + JSON API, bukan protokol baru yang revolusioner.

---

Counter-Intuitive Insight: Lebih Lambat dari JSON API Biasa?

Inilah insight yang mungkin nggak kamu duga:

tRPC bisa jadi LEBIH LAMBAT daripada JSON API tradisional, bukan lebih cepat.

Kenapa? Karena:

1. Abstraction tambahan → Ada proses proxy, validasi Zod, dan routing internal
2. Overhead parsing → Request dan response tetap JSON, tapi dengan wrapper tambahan
3. Bundle size meningkat → Client perlu menyertakan seluruh definisi tipe

Bandingkan dengan gRPC yang pakai Protocol Buffer (binary) dan HTTP/2 — itu baru namanya high performance. tRPC? Ujung-ujungnya JSON juga.

Kapan Kamu HARUS Pakai tRPC?

Jujur, tRPC bukan teknologi jelek. Ada skenario spesifik di mana dia bersinar.

✅ Ideal Digunakan Ketika:

Skenario	Penjelasan
Full-stack TypeScript	Backend dan frontend 100% TypeScript
Internal tools / Admin dashboard	Tidak perlu API publik
Startup kecil dengan tim TS	Akselerasi development
Monorepo architecture	Sharing type jadi mudah

❌ JANGAN Pakai tRPC Jika:

Skenario	Alasan
Ada klien non-TypeScript (React Native, Flutter, Go, Python)	Tidak bisa consume tRPC
Membangun API publik	Memaksa klien pakai TS
Butuh performance maksimal	Mending langsung gRPC
Tim sudah nyaman dengan REST	ROI berganti teknologi kecil

Perbandingan Head-to-Head: tRPC vs JSON API

Aspek	JSON API (REST)	tRPC
Type safety	Manual (OpenAPI/Types)	✅ Otomatis
Learning curve	Rendah	Sedang (perlu paham TS advanced)
Performance	✅ Baseline	Sedikit lebih lambat (overhead proxy)
Client agnostic	✅ Bisa semua bahasa	❌ Hanya TypeScript
Debugging	✅ Mudah pakai Postman/curl	❌ Perlu tools khusus
Ecosystem	✅ Mature, banyak tools	Masih baru (~38k stars di GitHub)
Production ready?	✅ Teruji bertahun-tahun	⚠️ Masih perlu evaluasi

Pendapat Expert: Apakah Aku Akan Pakai tRPC?

Jujur, setelah mempelajari cara kerja low-level-nya:

Aku TIDAK akan pakai tRPC, bahkan untuk project TypeScript full-stack sekalipun.

Kenapa?

1. Ujung-ujungnya JSON API Juga

Kalau hasil akhirnya tetap HTTP + JSON, kenapa repot-repot pakai abstraction layer yang bikin debugging lebih susah?

2. Masalah Kompatibilitas

Suatu hari bisa jadi frontend-mu butuh diganti pakai framework non-TS (misalnya Flutter untuk mobile). Saat itu, kamu harus menulis ulang seluruh API.

3. Vendor Lock-in Terselubung

tRPC mengikatmu ke ekosistemnya sendiri. Mau pindah ke REST nanti? Pusing sendiri migration-nya.

4. Dokumentasi Kurang Low-Level

Sayangnya, dokumentasi tRPC tidak menjelaskan gimana sih cara kerjanya dari dalam. Untuk benar-benar paham, kamu harus baca source code-nya sendiri.

5. Hype vs Realita

38.000 stars di GitHub itu impresif, tapi pertanyaannya: beneran dipakai di production atau cuma eksperimen? Dari pengalaman, banyak teknologi populer ternyata hanya toy project yang tidak scalable.

Alternatif yang Lebih Baik?

Kalau kamu butuh:

Kebutuhan	Rekomendasi
Type safety end-to-end	OpenAPI + codegen (misal: OpenAPI Generator, Orval)
High performance	gRPC + Protocol Buffer
Flexibility query	GraphQL (Apollo, URQL)
Sederhana & universal	REST JSON API (tetap andalan)

💡 Saran dari veteran: Jangan terpancing shiny new thing. Teknologi yang sudah mature dan teruji di production jauh lebih berharga daripada fitur “magic” yang ujung-ujungnya bikin pusing.

---

Kesimpulan: Apakah tRPC Lebih Baik?

Jawaban singkatnya: Tidak untuk sebagian besar kasus.

Jawaban lengkapnya:

• ✅ tRPC unggul di developer experience untuk full-stack TypeScript
• ❌ Tapi kalah di performance, fleksibilitas, dan universalitas dibanding JSON API

Kalau kamu baru belajar atau membangun produk serius, tetap gunakan JSON API biasa. Pelajari dulu fundamentals HTTP, REST, dan bagaimana API bekerja dari low-level. Setelah itu, baru eksplor teknologi seperti tRPC sebagai nice-to-have, bukan must-have.

---

FAQ Seputar tRPC dan JSON API