એક ડેવલપરે ઇન્ટરનલ ટૂલમાં REST API ને બદલે tRPC વાપરવા માટે બે અઠવાડિયાનો સમય વિતાવ્યો.
આ બદલાવ કેમ મહત્વનો હતો
જૂની ટેક સ્ટેક (stack) ને કારણે અમારે DTO, એક વેલિડેટર અને ફ્રન્ટએન્ડ માટે TypeScript પ્રકારો (types) નો અલગ સેટ જાળવવો પડતો હતો. જો બેકએન્ડ ફિલ્ડનું નામ બદલાય, તો પણ API હજુ પણ 200 રિટર્ન કરતું, UI રેન્ડર થતું રહેતું, અને બગ (bug) માત્ર “undefined” વેલ્યુ તરીકે જ દેખાતો. ટીમમાં કોઈના પણ જાણ કરતા પહેલા ગ્રાહકે આ સમસ્યા પકડી પાડી હતી. REST કોન્ટ્રાક્ટ્સ આ સમસ્યાને છુપાવી દેતા હતા, અને વધારાની ફાઇલોએ એવું મેન્ટેનન્સ વધાર્યું જેનો કોઈ ફાયદો થયો નહીં.
REST સેટઅપ કેવું દેખાતું હતું
- OpenAPI spec – એક સ્ટેટિક ફાઇલ જે એન્ડપોઇન્ટ્સનું વર્ણન કરતી હતી પરંતુ ક્યારેય 'સોર્સ ઓફ ટ્રુથ' (source of truth) તરીકે કામ કરતી નહોતી.
- Client SDK generation step – એક CI જોબ જે JavaScript વૉરેપર (wrapper) બનાવતું હતું.
- Postman collection – એક શેર કરેલ ટેસ્ટિંગ આર્ટિફેક્ટ (artifact) જેનો કોઈ ઉપયોગ કરતું નહોતું.
- Manual TypeScript interfaces – હાથથી લખાયેલા પ્રકારો (types) જેને સર્વર સાથે સિંક (sync) રાખવા પડતા હતા.
દરેક API ફેરફારમાં આમાંથી ઓછામાં ઓછા ત્રણ આર્ટિફેક્ટ્સ, વત્તા વેલિડેટર અને કોઈપણ ડાઉનસ્ટ્રીમ fetch કોલ્સને સ્પર્શતા હતા. આ પ્રક્રિયા ભૂલભરેલી અને ધીમી હતી.
tRPC એ કોડબેઝને કેવી રીતે ઘટાડ્યો
tRPC અલગ કોન્ટ્રાક્ટ ફાઇલની જરૂરિયાત દૂર કરે છે. સર્વર એક router type એક્સપોર્ટ કરે છે; ક્લાયન્ટ તે જ પ્રકારને ઇમ્પોર્ટ કરે છે. જો બેકએન્ડ ફિલ્ડનું નામ બદલાય, તો એડિટર તરત જ મિસમેચ (mismatch) દર્શાવે છે—કોડ રન કરવાની કે ફેઇલ રિક્વેસ્ટની જરૂર પડતી નથી. ડેવલપરે આ બધું દૂર કરી દીધું:
- OpenAPI spec ફાઇલ.
- Client SDK જનરેશન સ્ટેપ.
- બિનઉપયોગી Postman કલેક્શન.
- મેન્યુઅલ TypeScript ઇન્ટરફેસનું ફોલ્ડર.
રિપોઝિટરી (repo) વધુ સ્લીમ (lean) બની ગઈ, અને ફીડબેક ડિપ્લોયમેન્ટ પછીને બદલે ડેવલપમેન્ટ દરમિયાન જ મળી ગયો.
tRPC ની મર્યાદાઓ
tRPC ત્યારે જ કામ કરે છે જ્યારે બંને છેડા (ends) TypeScript નો ઉપયોગ કરતા હોય. તે નીચેના કિસ્સાઓમાં નિષ્ફળ જાય છે:
- મોબાઈલ ટીમ Swift અથવા Kotlin નો ઉપયોગ કરતી હોય.
- API નો ઉપયોગ બાહ્ય પાર્ટનર્સ દ્વારા કરવાનો હોય.
- તમારે પબ્લિક, લેંગ્વેજ-એગ્નોસ્ટિક (language-agnostic) ઇન્ટરફેસની જરૂર હોય.
માઇગ્રેશન માટે ખરેખર શું જરૂરી હતું
બે અઠવાડિયાનો આ પ્રયાસ માત્ર કોપી-અને-પેસ્ટ કરવા પૂરતો નહોતો. ડેવલપરે આ કરવું પડ્યું:
- tRPC ના ક્લાયન્ટ ફંક્શન્સનો ઉપયોગ કરવા માટે દરેક
fetchકોલ ફરીથી લખવો પડ્યો. - એરર-હેન્ડલિંગ લોજિકમાં ફેરફાર કરવો પડ્યો.
- લોડિંગ અને રિટ્રાય સ્ટેટ્સ (retry states) જે રો (raw) HTTP રિસ્પોન્સ પર આધારિત હતા, તેવા UI કમ્પોનન્ટ્સ અપડેટ કરવા પડ્યા.
આગળ વધતા પહેલા પૂછવા જેવા પ્રશ્નો
- શું ફ્રન્ટએન્ડ અને બેકએન્ડ બંને TypeScript નો ઉપયોગ કરે છે? શેર કરેલી ટાઇપ સિસ્ટમ વગર, tRPC તેનો મુખ્ય ફાયદો ગુમાવે છે.
- શું બંને બાજુ માટે એક જ ટીમ જવાબદાર છે? ઓનરશિપ ગેપ્સ (ownership gaps) ફરીથી કોન્ટ્રાક્ટ ડ્રિફ્ટ (contract drift) લાવી શકે છે.
- શું તમે કોઈ ચોક્કસ બગ સુધારી રહ્યા છો કે માત્ર ટ્રેન્ડ પાછળ દોડી રહ્યા છો? ઉત્પાદકતામાં વધારો વાસ્તવિક છે, પરંતુ તે હાલની સમસ્યાનું નિરાકરણ લાવવો જોઈએ.
2025 માટે હાઇબ્રિડ અભિગમ
ઘણી ટીમો બંને સ્ટેક ચલાવીને યોગ્ય સંતુલન (sweet spot) શોધી લે છે:
- ઇન્ટરનલ એપ્લિકેશન લેયર્સ માટે tRPC, જ્યાં કોડબેઝ સંપૂર્ણપણે TypeScript હોય અને એક જ ટીમ સર્વર અને ક્લાયન્ટની માલિક હોય.
- વેબહૂક્સ (webhooks), પબ્લિક APIs અને પાર્ટનર ઇન્ટિગ્રેશન્સ માટે REST, જ્યાં લેંગ્વેજ-એગ્નોસ્ટિક એક્સેસની જરૂર હોય.
દરેક જરૂરિયાત માટે યોગ્ય સાધનનો ઉપયોગ કરવાથી ઇન્ટરનલ ડેવલપમેન્ટ ઝડપી રહે છે અને સાથે સાથે બાહ્ય ગ્રાહકો માટે જરૂરી ઓપનનેસ પણ જળવાઈ રહે છે.
મુખ્ય વાત (Takeaway): REST ને બદલે tRPC વાપરવાથી ડુપ્લીકેટ કોન્ટ્રાક્ટ આર્ટિફેક્ટ્સ દૂર થઈ શકે છે અને એડિટ કરતી વખતે જ બગ્સ સામે આવી શકે છે, પરંતુ આ ફાયદા ત્યારે જ મળે છે જ્યારે આખો સ્ટેક TypeScript શેર કરતો હોય અને ટીમ માઇગ્રેશન ખર્ચ સહન કરી શકે. મિશ્ર વ્યૂહરચના તમને non-TypeScript ગ્રાહકોને બાકાત રાખ્યા વિના તેના ફાયદા મેળવવામાં મદદ કરે છે.