tRPC vs GraphQL vs REST+Zod: pilih API layer 2026

Konteks: kenapa 2026 masih relevan debat ini

Tiga tahun lalu, pilihan API layer terasa lebih jelas: GraphQL untuk complex client, REST untuk segalanya. Sekarang, tRPC sudah mature, REST+Zod ecosystem sudah solid (ts-rest, zod-to-openapi), dan GraphQL punya Pothos + Houdini yang lebih ergonomis.

Masalahnya: banyak tim Indonesia masih memilih GraphQL karena “scalable” atau tRPC karena “modern” tanpa mempertimbangkan total cost of ownership — termasuk latency ke Jakarta, kebutuhan external client, dan learning curve tim.

Artikel ini bukan tentang mana yang “terbaik”. Ini tentang kondisi spesifik mana yang wins.

Perbandingan langsung

Aspek	tRPC	GraphQL	REST+Zod
Setup cost	Rendah (monorepo TS)	Tinggi (schema, resolver, codegen)	Rendah–sedang
Type safety	End-to-end otomatis	Perlu codegen (graphql-codegen)	Perlu ts-rest / openapi-typescript
External client	Tidak bisa (TS only)	Excellent (language-agnostic)	Excellent
DX di monorepo	Excellent	Sedang	Sedang–baik
Latency overhead	Minimal	Ada (query parsing + resolver chain)	Minimal
Hosting Indonesia	VPS/Cloudflare Workers	Perlu managed service atau self-host	VPS apapun
Ecosystem maturity	Stable, tapi niche	Sangat mature	Paling mature

tRPC

Kekuatan nyata

tRPC wins di satu skenario spesifik: monorepo TypeScript fullstack dengan client yang semuanya TypeScript dan owned oleh tim yang sama. Di kondisi itu, DX-nya tidak ada tandingan — tulis procedure di server, langsung callable di client dengan type inference penuh, tanpa generate step, tanpa boilerplate.

Untuk Next.js App Router atau Astro dengan API routes, tRPC bisa di-setup dalam satu hari dan langsung produktif. Refactor type di satu tempat, TypeScript error langsung muncul di semua consumer — ini nyata menghemat waktu di project mid-size.

Keterbatasan yang sering diabaikan

tRPC adalah TypeScript-to-TypeScript RPC. Kalau ada kebutuhan mobile native (React Native masih hitung, tapi Kotlin/Swift tidak), atau kalau backend Anda butuh dikonsumsi oleh third-party, tRPC tidak bisa serve itu. Anda harus tetap expose REST endpoint terpisah — yang artinya Anda maintain dua layer.

Selain itu, tRPC belum punya adoption yang luas di luar lingkaran Next.js community. Kalau tim baru join dan belum familiar, ada learning curve. Debugging juga kurang straightforward dibanding REST — request/response tidak se-plain JSON biasa karena transport layer-nya berbeda.

Kapan worth

tRPC worth kalau Anda bangun SaaS internal atau B2B tool di mana semua client adalah web TypeScript, dan tidak ada rencana expose API ke pihak ketiga dalam 12-18 bulan ke depan.

GraphQL

Kekuatan nyata

GraphQL genuinely menyelesaikan masalah riil: multiple client dengan kebutuhan data berbeda. Kalau Anda punya mobile app, web app, dan dashboard analytics yang semua butuh data yang sama tapi dengan shape berbeda, GraphQL memungkinkan tiap client ambil persis yang dibutuhkan tanpa over-fetch atau under-fetch.

Di 2026, GraphQL tooling sudah lebih baik. Pothos membuat schema definition lebih ergonomis di TypeScript. Houdini dan TanStack Query + urql membuat client-side cache management lebih bisa diprediksi. Untuk aplikasi dengan data graph yang complex (relasi banyak, querying nested entity), GraphQL masih yang paling ekspresif.

Keterbatasan yang perlu diperhitungkan

GraphQL bukan “REST yang lebih baik” — GraphQL adalah trade-off yang berbeda. Setup cost lebih tinggi: perlu define schema terpisah, tulis resolver, setup codegen untuk type safety, dan maintain N+1 query problem dengan DataLoader. Untuk CRUD sederhana, ini adalah overhead yang tidak sebanding.

Di Indonesia, ada satu faktor yang sering diabaikan: latency managed service. Kalau Anda pakai Hasura Cloud atau Apollo GraphOS di region US/EU, setiap GraphQL query Anda tambah 80-200ms dibanding REST ke server lokal. Untuk user di luar Jawa dengan koneksi variabel, ini terasa. Self-host GraphQL di VPS Jakarta atau Singapore ap-southeast-1 lebih baik, tapi itu tambah ops burden.

Kapan worth

GraphQL worth kalau Anda punya minimum dua client berbeda dengan kebutuhan query berbeda (misalnya web dashboard dan mobile app), atau kalau Anda expose API ke developer eksternal yang butuh flexibility query. Tidak worth untuk internal tool CRUD atau single-client SaaS.

REST+Zod

Kekuatan nyata

REST+Zod adalah pendekatan yang paling pragmatis dan portable. REST sudah dipahami semua orang — developer baru, stakeholder teknis, dokumentasi otomatis dengan OpenAPI, integration dengan tool apapun. Zod di-layer di atas memberikan type safety di request/response tanpa coupling arsitektur.

Dengan kombinasi zod-to-openapi dan openapi-typescript, Anda bisa generate TypeScript type dari schema OpenAPI dan pakai di frontend — end-to-end type safety tanpa lock-in ke framework spesifik. ts-rest membawa DX yang lebih mirip tRPC tapi tetap compatible dengan REST semantics dan bisa di-consume oleh client non-TypeScript.

Untuk deployment di Indonesia, REST ke VPS Hetzner Helsinki atau DigitalOcean Singapore dengan Nginx di depannya adalah setup yang sudah proven — tidak ada layer tambahan yang perlu dipelajari atau di-debug.

Keterbatasan

REST+Zod tidak punya DX seamless seperti tRPC. Ada generate step, atau ada contract file yang perlu dijaga sinkron secara manual. Kalau tim tidak disiplin menjaga schema tetap konsisten antara backend dan frontend, type safety bisa bocor. Ini bukan keterbatasan teknis — ini keterbatasan proses yang perlu dijaga.

Kapan worth

REST+Zod worth untuk hampir semua kasus, tapi paling optimal kalau Anda: punya multiple technology stack di backend atau frontend, butuh dokumentasi API yang bisa dibaca non-developer, atau bekerja di lingkungan di mana tidak semua client adalah TypeScript.

Verdict

Pakai tRPC kalau:

• Monorepo TypeScript dengan semua client TypeScript
• Tidak butuh expose API ke external consumer
• Tim sudah familiar dengan Next.js / Astro fullstack pattern
• Project internal / B2B dengan scope yang terdefinisi

Pakai GraphQL kalau:

• Punya 2+ client berbeda dengan kebutuhan data berbeda (mobile + web, atau external API consumer)
• Data model complex dengan banyak relasi
• Tim sudah punya pengalaman GraphQL dan siap maintain schema
• Deploy di region ap-southeast-1 atau server Jakarta (bukan managed service offshore)

Pakai REST+Zod kalau:

• Tim mixed-stack atau tidak semua TypeScript
• Butuh OpenAPI documentation untuk stakeholder atau third-party
• Project yang kemungkinan besar akan expose API ke consumer eksternal di masa depan
• Default pilihan untuk most Indonesian SMB SaaS — paling portable, paling mudah di-maintain, paling mudah di-hire untuk

Satu hal yang perlu saya tekankan: jangan pilih GraphQL karena ingin terlihat enterprise. Saya sudah lihat lebih dari sekali tim startup Indonesia setup Apollo Server dengan schema lengkap untuk aplikasi yang basically adalah CRUD 5 table — overhead yang tidak worth. Mulai dari REST+Zod, migrasi ke GraphQL kalau kebutuhan multiple client benar-benar muncul.