2 min read

tRPC Simplifies Type-Safe API Development

Learn how tRPC provides end-to-end type-safe APIs for TypeScript applications, including procedures, validation, batching, and the advantages and limitations of using tRPC.

Node.jsTypeScripttRPCAPI Design

What Is tRPC?

tRPC ဆိုတာ TypeScript ကို အခြေခံပြီး End-to-end Type-safe APIs တွေ တည်ဆောက်နိုင်တဲ့ Framework တစ်ခု ဖြစ်ပါတယ်။ Backend နဲ့ Frontend အတွက် API Types တွေကို သီးခြားစီ ခွဲရေးနေစရာမလိုဘဲ Server ကို Single Source of Truth အဖြစ်ထားရှိကာ Router Types တွေကို Client ဆီ အလိုအလျောက် မျှဝေပေးတာကြောင့် TypeScript တစ်ခုတည်းနဲ့ System နှစ်ခုလုံးကို အလွယ်တကူ ချိတ်ဆက်ပေးနိုင်ပါတယ်။

The Traditional API Problem

ရိုးရာ REST APIs တွေမှာ fetch() သုံးပြီး Data လှမ်းခေါ်တဲ့အခါ TypeScript က Backend က ပြန်လာမယ့် Response Structure ကို အလိုအလျောက် မသိရှိနိုင်တဲ့အတွက် Frontend ဘက်မှာ Types တွေကို သီးသန့် ထပ်ရေးရပါတယ်။ Application ကြီးလာတာနဲ့အမျှ Backend မှာ Data Structure အပြောင်းအလဲလုပ်လိုက်ချိန်မှာ Frontend Types တွေက လိုက်မပြောင်းဘဲ ကျန်နေခဲ့ပြီး Runtime Errors တွေ ဖြစ်ပေါ်စေတဲ့ API Contract Synchronization ပြဿနာကို ကြုံတွေ့ရတတ်ပါတယ်။

The tRPC Approach

tRPC မှာတော့ Server ဘက်က Typed Procedures တွေကို သတ်မှတ်လိုက်တာနဲ့ Client ဘက်ကနေ Function Call သဖွယ် တိုက်ရိုက် ခေါ်သုံးနိုင်ပါတယ်။ Client ဟာ ဘယ် Input Parameters တွေ လိုအပ်ပြီး Response အနေနဲ့ ဘာပြန်လာမလဲဆိုတာကို အလိုအလျောက် သိရှိတဲ့အတွက် API Data Models တွေကို နှစ်ခါပြန်ရေးစရာမလိုဘဲ Frontend နဲ့ Backend အမြဲ Synchronized ဖြစ်နေစေပါတယ်။

End-to-End Type Safety

Server ဘက်က string မျှော်လင့်ထားတဲ့နေရာမှာ Client က number ပို့လိုက်မိတာမျိုး Input Mismatch တွေကို TypeScript က Development Process အတွင်းမှာတင် ကြိုတင်ဖမ်းယူပေးပါတယ်။ ဒါဟာ Code Refactoring လုပ်တဲ့အခါ အမှားအယွင်းတွေကို Deploy မလုပ်ခင် ကြိုတင်သိရှိ ပြင်ဆင်နိုင်တာကြောင့် Development ကို ပိုမိုစိတ်ချလုံခြုံစေပါတယ်။

Runtime Validation with Zod

TypeScript Types တွေဟာ Compile-time Safety အတွက်သာဖြစ်ပြီး Runtime မှာ ပျောက်သွားတာကြောင့် External Input တွေကို Validate လုပ်ဖို့ Zod လို Library တွေကို ပေါင်းစပ်အသုံးပြုရပါတယ်။ ဒါဟာ Development အဆင့်မှာ TypeScript က Types တွေကို စစ်ဆေးပေးပြီး Runtime အဆင့်မှာ Zod က Incoming Input Data တွေကို Validate လုပ်ပေးတဲ့ နှစ်ထပ်ကူ ကာကွယ်ရေး (Two Layers of Protection) ကို ရရှိစေပါတယ်။

tRPC vs REST and GraphQL

REST က Resources (Endpoints) တွေကို ထုတ်ပေးပြီး GraphQL က လိုချင်တဲ့ Field တွေကို သီးသန့် Query လုပ်ခွင့်ပေးတဲ့အချိန်မှာ tRPC ကတော့ Typed Procedures တွေကို တိုက်ရိုက် ခေါ်သုံးခွင့်ပေးတာ ဖြစ်ပါတယ်။ Frontend နဲ့ Backend နှစ်ခုလုံး TypeScript သုံးထားပြီး Team တစ်ခုတည်းက ထိန်းချုပ်ထားတဲ့ Full-stack TypeScript Projects တွေအတွက် tRPC က အထူးသင့်တော်ပြီး Multi-language Clients တွေ သို့မဟုတ် Public APIs တွေအတွက်တော့ REST ဒါမှမဟုတ် GraphQL က ပိုမိုသင့်လျော်ပါတယ်။

Advantages and Limitations

tRPC ဟာ Automatic Type Inference, Autocomplete, Safer Refactoring နဲ့ ပိုမိုကောင်းမွန်တဲ့ Developer Experience တွေကို ပေးစွမ်းနိုင်ပေမဲ့ Authentication, Authorization, Caching, Database Query Performance နဲ့ Network Failure စတဲ့ Distributed System ရဲ့ အခြေခံပြဿနာတွေကိုတော့ အလိုအလျောက် ဖြေရှင်းမပေးနိုင်ပါ။

Final Thoughts

tRPC ရဲ့ အဓိကတန်ဖိုးက Frontend နဲ့ Backend ကြားက Type Mismatch ကွာဟချက်ကို လျှော့ချပေးပြီး Server ပိုင်း အပြောင်းအလဲတွေကို Client ဘက်က အချိန်နဲ့တပြေးညီ ကြိုတင်သိရှိနိုင်စေခြင်း ဖြစ်ပါတယ်။ REST ထက် သာသလားဆိုတာထက် သင့် Project လိုအပ်ချက်နဲ့ ကိုက်ညီမှုရှိမရှိပေါ်မှာ မူတည်ပြီး Full-stack TypeScript Applications တွေအတွက်တော့ Type System ကို အပြည့်အဝ အသုံးချနိုင်တဲ့ အလွန်ထိရောက်တဲ့ ဖြေရှင်းနည်းတစ်ခု ဖြစ်ပါတယ်။