ஒரு டெவலப்பர் ஒரு உள் கருவியில் (internal tool) REST API-க்கு பதிலாக tRPC-ஐப் பயன்படுத்த இரண்டு வாரங்களைச் செலவிட்டார்.
இந்த மாற்றம் ஏன் முக்கியமானது
பழைய தொழில்நுட்ப அடுக்கு (stack), ஒரு DTO, ஒரு validator மற்றும் முன்பக்கத்திற்காக (frontend) தனியான TypeScript வகைகளை (types) பராமரிக்க எங்களை வற்புறுத்தியது. பேக்எண்ட் புலத்தின் (backend field) பெயரை மாற்றினால், API இன்னும் 200-ஐத் தான் திருப்பி அனுப்பும், UI தொடர்ந்து இயங்கும், மேலும் பிழை "undefined" மதிப்புகளாக மட்டுமே தெரியும். குழுவில் உள்ள எவருக்கும் தெரியவில்லை, ஆனால் ஒரு வாடிக்கையாளர் அந்தப் பிரச்சனையைத் தெரிந்து கொண்டார். REST ஒப்பந்தங்கள் (contracts) அந்தப் பிரச்சனையை மறைத்து வைத்திருந்தன, மேலும் கூடுதல் கோப்புகள் எந்தப் பயனும் தராத பராமரிப்புச் சுமையைச் சேர்த்தன.
REST அமைப்பு எப்படி இருந்தது
- OpenAPI spec – எண்ட்பாயிண்டுகளை (endpoints) விவரிக்கும் ஒரு நிலையான கோப்பு, ஆனால் இது ஒருபோதும் உண்மையான ஆதாரமாக (source of truth) செயல்படவில்லை.
- Client SDK உருவாக்கும் படிநிலை – ஒரு JavaScript wrapper-ஐ உருவாக்கும் CI வேலை.
- Postman collection – யாரும் பயன்படுத்தாத ஒரு பகிரப்பட்ட சோதனைப் பொருள் (testing artifact).
- Manual TypeScript interfaces – சர்வரோடு ஒத்துப்போக வேண்டிய கையால் எழுதப்பட்ட வகைகள் (types).
ஒவ்வொரு API மாற்றமும் அந்தப் பொருட்களில் குறைந்தது மூன்றையும், அதோடு validator மற்றும் பிற fetch அழைப்புகளையும் பாதித்தது. இந்தச் செயல்முறை பிழைகளுக்கு வழிவகுப்பதாகவும் மெதுவாகவும் இருந்தது.
tRPC எவ்வாறு codebase-ஐக் குறைத்தது
tRPC தனியான ஒப்பந்தக் கோப்பை (contract file) நீக்குகிறது. சர்வர் ஒரு router type-ஐ ஏற்றுமதி செய்கிறது; கிளையண்ட் அதே type-ஐ இறக்குமதி செய்கிறது. பேக்எண்ட் புலத்தின் பெயரை மாற்றினால், எடிட்டர் உடனடியாக அந்த முரண்பாட்டைக் காட்டும்—குறியீட்டை இயக்கவோ அல்லது தோல்வியடைந்த கோரிக்கையை (failed request) எதிர்பார்க்கவோ தேவையில்லை. டெவலப்பர் இவற்றை நீக்கினார்:
- OpenAPI spec கோப்பு.
- Client SDK உருவாக்கும் படிநிலை.
- பயன்படுத்தப்படாத Postman collection.
- Manual TypeScript interfaces கோப்புறை.
ரெப்போ (repo) மிகவும் சுருங்கியது, மேலும் பயன்பாட்டில் (deployment) கொண்டு வருவதற்கு முன்பே, மேம்படுத்தும் போதே (development) கருத்துக்கள் (feedback) கிடைத்தன.
tRPC-ன் வரம்புகள்
இருமுனைகளிலும் TypeScript பயன்படுத்தப்படும்போது மட்டுமே tRPC வேலை செய்யும். பின்வரும் சூழல்களில் இது போதுமானதாக இருக்காது:
- ஒரு மொபைல் குழு Swift அல்லது Kotlin பயன்படுத்துகிறது என்றால்.
- API-ஐ வெளிப்படையான கூட்டாளர்கள் (external partners) பயன்படுத்த வேண்டும் என்றால்.
- உங்களுக்கு ஒரு பொதுவான, மொழி சாராத (language-agnostic) இடைமுகம் தேவைப்பட்டால்.
இடமாற்றத்திற்கு (migration) உண்மையில் என்ன தேவைப்பட்டது
அந்த இரண்டு வார முயற்சி என்பது வெறும் நகலெடுப்பது (copy-and-paste) மட்டுமல்ல. டெவலப்பர் செய்ய வேண்டியவை:
- tRPC-ன் client செயல்பாடுகளைப் பயன்படுத்த ஒவ்வொரு
fetchஅழைப்பையும் மீண்டும் எழுத வேண்டும். - பிழை கையாளுதல் (error-handling) தர்க்கத்தை மாற்றியமைக்க வேண்டும்.
- நேரடி HTTP பதில்களுடன் (raw HTTP responses) தொடர்புடைய loading மற்றும் retry நிலைகளைச் சார்ந்திருக்கும் UI கூறுகளை (components) புதுப்பிக்க வேண்டும்.
தொடங்குவதற்கு முன் கேட்க வேண்டிய கேள்விகள்
- முன்பக்கமும் (frontend) பின்புலமும் (backend) TypeScript பயன்படுத்துகின்றனவா? ஒரு பகிரப்பட்ட வகை அமைப்பு (shared type system) இல்லையென்றால், tRPC தனது முக்கிய நன்மையைத் இழந்துவிடும்.
- இரு பக்கங்களுக்கும் ஒரே குழு பொறுப்பேற்கிறதா? பொறுப்புக்கூறலில் உள்ள இடைவெளிகள் ஒப்பந்த முரண்பாடுகளை (contract drift) மீண்டும் ஏற்படுத்தலாம்.
- நீங்கள் ஒரு குறிப்பிட்ட பிழையைச் சரிசெய்கிறீர்களா அல்லது ஒரு போக்கைப் (trend) பின்தொடர்கிறீர்களா? உற்பத்தித்திறன் அதிகரிப்பு உண்மையானதுதான், ஆனால் அது ஏற்கனவே உள்ள ஒரு சிக்கலைத் தீர்க்க வேண்டும்.
2025-க்கான ஒரு கலப்பு அணுகுமுறை (hybrid approach)
பல குழுக்கள் இரண்டு தொழில்நுட்ப அடுக்குகளையும் (stacks) இயக்குவதன் மூலம் சிறந்த சமநிலையைக் கண்டறிகின்றன:
- உள் பயன்பாட்டு அடுக்குகளுக்கு (internal application layers) tRPC: இங்கு codebase முழுமையாக TypeScript ஆக இருக்கும் மற்றும் ஒரே குழு சர்வர் மற்றும் கிளையன்ட்டை நிர்வகிக்கும்.
- Webhooks, பொதுவான APIs மற்றும் கூட்டாளர் ஒருங்கிணைப்புகளுக்கு (partner integrations) REST: இங்கு மொழி சாராத அணுகல் (language-agnostic access) தேவைப்படும்.
ஒவ்வொரு தேவைக்கும் சரியான கருவியைப் பயன்படுத்துவது, வெளிப்படையான நுகர்வோருக்குத் தேவையான திறந்த தன்மையைப் பாதுகாக்கும் அதே வேளையில், உள் மேம்பாட்டை (internal development) வேகமாகவும் வைத்திருக்கும்.
சுருக்கம்: REST-க்கு பதிலாக tRPC-ஐப் பயன்படுத்துவது, நகல் ஒப்பந்தப் பொருட்களை (duplicated contract artifacts) நீக்கலாம் மற்றும் குறியீட்டைத் திருத்தும் போதே பிழைகளைக் கண்டறியலாம், ஆனால் முழுத் தொழில்நுட்ப அடுக்கும் TypeScript-ஐப் பகிர்ந்து கொள்ளும்போது மற்றும் குழு இடமாற்றச் செலவை ஏற்கத் தயாராக இருக்கும்போது மட்டுமே இதன் பலன்கள் கிடைக்கும். ஒரு கலப்பு உத்தி (mixed strategy), TypeScript அல்லாத நுகர்வோரைத் தடுத்தல் இன்றி உங்களுக்குப் பலன்களைப் பெற அனுமதிக்கிறது.