ఒక డెవలపర్ ఒక ఇంటర్నల్ టూల్‌లో REST APIని tRPCతో మార్చడానికి రెండు వారాల సమయం కేటాయించారు.

ఈ మార్పు ఎందుకు ముఖ్యం

పాత స్టాక్ వల్ల మేము ఒక DTO, ఒక వాలిడేటర్ మరియు ఫ్రంటెండ్ కోసం విడిగా TypeScript టైప్స్‌ను నిర్వహించాల్సి వచ్చేది. బ్యాకెండ్ ఫీల్డ్‌ను రీనేమ్ చేస్తే, API ఇంకా 200 రిటర్న్ చేసేది, UI రెండరింగ్ కొనసాగేది, మరియు బగ్ కేవలం “undefined” వాల్యూస్‌గా మాత్రమే కనిపించేది. టీమ్‌లోని ఎవరూ గుర్తించకముందే ఒక కస్టమర్ ఆ సమస్యను కనిపెట్టారు. REST కాంట్రాక్ట్‌లు సమస్యను దాచిపెట్టాయి, మరియు అదనపు ఫైల్‌లు నిర్వహణ భారాన్ని పెంచాయి కానీ ఎటువంటి ప్రయోజనాన్ని ఇవ్వలేదు.

REST సెటప్ ఎలా ఉండేది

  • OpenAPI spec – ఎండ్‌పాయింట్‌లను వివరించే ఒక స్టాటిక్ ఫైల్, కానీ ఇది ఎప్పుడూ source of truth గా పనిచేయలేదు.
  • Client SDK generation step – ఒక JavaScript వ్రాపర్‌ను ఉత్పత్తి చేసే CI జాబ్.
  • Postman collection – ఎవరూ ఉపయోగించని ఒక షేర్డ్ టెస్టింగ్ ఆర్టిఫాక్ట్.
  • Manual TypeScript interfaces – సర్వర్‌తో సింక్ అయి ఉండాల్సిన, మాన్యువల్‌గా రాసిన టైప్స్.

ప్రతి API మార్పు కనీసం మూడు ఆర్టిఫాక్ట్‌లను, వీటికి తోడు వాలిడేటర్ మరియు డౌన్‌స్ట్రీమ్ fetch కాల్స్‌ను ప్రభావితం చేసేది. ఈ ప్రక్రియ తప్పులకు అవకాశం ఉన్నది మరియు నెమ్మదిగా ఉండేది.

tRPC కోడ్‌బేస్‌ను ఎలా తగ్గించింది

tRPC విడిగా ఉండే కాంట్రాక్ట్ ఫైల్‌ను తొలగిస్తుంది. సర్వర్ ఒక router typeను ఎగుమతి (export) చేస్తుంది; క్లయింట్ అదే టైప్‌ను ఇంపోర్ట్ చేసుకుంటుంది. బ్యాకెండ్ ఫీల్డ్‌ను రీనేమ్ చేస్తే, కోడ్‌ను రన్ చేయాల్సిన లేదా రిక్వెస్ట్ ఫెయిల్ అయ్యే వరకు వేచి చూడాల్సిన అవసరం లేకుండానే, ఎడిటర్ వెంటనే ఆ తేడాను గుర్తిస్తుంది. డెవలపర్ వీటిని తొలగించారు:

  • OpenAPI spec ఫైల్.
  • Client SDK generation step.
  • ఉపయోగించని Postman collection.
  • మాన్యువల్ TypeScript interfaces ఉన్న ఫోల్డర్.

రిపోజిటరీ మరింత తేలికగా మారింది మరియు డెప్లాయ్‌మెంట్ తర్వాత కాకుండా డెవలప్‌మెంట్ సమయంలోనే ఫీడ్‌బ్యాక్ లభించింది.

tRPC పరిమితులు

రెండు వైపులా TypeScript ఉన్నప్పుడు మాత్రమే tRPC పనిచేస్తుంది. ఈ క్రింది సందర్భాలలో ఇది సరిపోదు:

  • మొబైల్ టీమ్ Swift లేదా Kotlin ఉపయోగిస్తుంటే.
  • APIని ఎక్స్‌టర్నల్ పార్ట్‌నర్స్ ఉపయోగించాల్సి వస్తే.
  • మీకు పబ్లిక్, లాంగ్వేజ్-అగ్నోస్టిక్ (language-agnostic) ఇంటర్‌ఫేస్ కావాలంటే.

మైగ్రేషన్ కోసం నిజంగా ఏమి అవసరమైంది

ఆ రెండు వారాల కృషి కేవలం కాపీ-అండ్-పేస్ట్ మాత్రమే కాదు. డెవలపర్ ఈ క్రింది పనులు చేయాల్సి వచ్చింది:

  • tRPC క్లయింట్ ఫంక్షన్‌లను ఉపయోగించడానికి ప్రతి fetch కాల్‌ను తిరిగి రాయడం.
  • ఎర్రర్-హ్యాండ్లింగ్ లాజిక్‌ను సర్దుబాటు చేయడం.
  • రా HTTP రెస్పాన్స్‌లపై ఆధారపడిన లోడింగ్ మరియు రీట్రై స్టేట్స్‌తో ముడిపడి ఉన్న UI కాంపోనెంట్స్‌ను అప్‌డేట్ చేయడం.

మీరు మారే ముందు అడగవలసిన ప్రశ్నలు

  • ఫ్రంటెండ్ మరియు బ్యాకెండ్ రెండూ TypeScript ఉపయోగిస్తున్నాయా? షేర్డ్ టైప్ సిస్టమ్ లేకపోతే, tRPC తన ప్రధాన ప్రయోజనాన్ని కోల్పోతుంది.
  • రెండు వైపులా ఒకే టీమ్ బాధ్యత వహిస్తోందా? ఓనర్‌షిప్ గ్యాప్స్ వల్ల కాంట్రాక్ట్ డ్రిఫ్ట్ (contract drift) మళ్ళీ వచ్చే అవకాశం ఉంది.
  • మీరు ఒక నిర్దిష్ట బగ్‌ను సరిచేస్తున్నారా లేదా కేవలం ట్రెండ్‌ను అనుసరిస్తున్నారా? ఉత్పాదకత పెరగడం నిజమే, కానీ అది ప్రస్తుతం ఉన్న సమస్యను పరిష్కరించేలా ఉండాలి.

2025 కోసం ఒక హైబ్రిడ్ విధానం

చాలా టీమ్‌లు రెండు స్టాక్‌లను ఉపయోగించడం ద్వారా సరైన సమతుల్యతను కనుగొంటాయి:

  • ఇంటర్నల్ అప్లికేషన్ లేయర్‌ల కోసం tRPC – ఇక్కడ కోడ్‌బేస్ పూర్తిగా TypeScriptలో ఉంటుంది మరియు సర్వర్, క్లయింట్ రెండింటినీ ఒకే టీమ్ నిర్వహిస్తుంది.
  • వెబ్‌హుక్స్, పబ్లిక్ APIలు మరియు పార్ట్‌నర్ ఇంటిగ్రేషన్‌ల కోసం REST – ఇక్కడ లాంగ్వేజ్-అగ్నోస్టిక్ యాక్సెస్ అవసరం అవుతుంది.

ప్రతి అవసరానికి సరైన సాధనాన్ని ఉపయోగించడం వల్ల ఇంటర్నల్ డెవలప్‌మెంట్ వేగంగా ఉంటుంది, అదే సమయంలో ఎక్స్‌టర్నల్ కన్స్యూమర్‌లకు అవసరమైన ఓపెన్‌నెస్‌ను కూడా కాపాడుకోవచ్చు.

ముఖ్య గమనిక: RESTని tRPCతో భర్తీ చేయడం వల్ల డూప్లికేట్ కాంట్రాక్ట్ ఆర్టిఫాక్ట్‌లను తొలగించవచ్చు మరియు ఎడిట్ చేసే సమయంలోనే బగ్‌లను గుర్తించవచ్చు, కానీ మొత్తం స్టాక్ TypeScriptని పంచుకున్నప్పుడు మరియు టీమ్ మైగ్రేషన్ ఖర్చును భరించగలిగినప్పుడు మాత్రమే దీనివల్ల లాభాలు ఉంటాయి. మిశ్రమ వ్యూహం (mixed strategy) ద్వారా మీరు non-TypeScript కన్స్యూమర్‌లను దూరం చేయకుండానే ప్రయోజనాలను పొందవచ్చు.