ഒരു ഡെവലപ്പർ ഒരു ഇന്റേണൽ ടൂളിൽ REST API-ക്ക് പകരം tRPC ഉപയോഗിക്കാൻ രണ്ട് ആഴ്ചകൾ ചെലവഴിച്ചു.

ഈ മാറ്റം പ്രധാനപ്പെട്ടത് എന്തുകൊണ്ട്

പഴയ സ്റ്റാക്ക് (stack) ഉപയോഗിക്കുമ്പോൾ ഒരു DTO, ഒരു validator, കൂടാതെ ഫ്രണ്ട്‌എൻഡിനായി പ്രത്യേക TypeScript ടൈപ്പുകൾ എന്നിവ നിലനിർത്തേണ്ടി വരുമായിരുന്നു. ബാക്കെൻഡ് ഫീൽഡ് (field) മാറ്റിയാൽ പോലും API ഇപ്പോഴും 200 റിട്ടേൺ ചെയ്യുമായിരുന്നു, UI റെൻഡർ ചെയ്തുകൊണ്ടേയിരുന്നു, എന്നാൽ ബഗ്ഗ് "undefined" വാല്യൂകളായി മാത്രമേ പുറത്തുവരികയുള്ളൂ. ടീമിലെ ആരും ശ്രദ്ധിക്കുന്നതിന് മുമ്പ് തന്നെ ഒരു ഉപഭോക്താവ് ഈ പ്രശ്നം കണ്ടെത്തി. REST കോൺട്രാക്റ്റുകൾ പ്രശ്നങ്ങളെ മറച്ചുവെച്ചു, കൂടാതെ അധിക ഫയലുകൾ അനാവശ്യമായ മെയിന്റനൻസ് ഭാരം വർദ്ധിപ്പിച്ചു.

REST സെറ്റപ്പ് എങ്ങനെയായിരുന്നു

  • OpenAPI spec – എൻഡ്‌പോയിന്റുകളെ വിവരിക്കുന്ന ഒരു സ്റ്റാറ്റിക് ഫയൽ, എന്നാൽ ഇത് ഒരിക്കലും കൃത്യമായ വിവരങ്ങളുടെ ഉറവിടമായി (source of truth) പ്രവർത്തിച്ചില്ല.
  • Client SDK generation step – ഒരു JavaScript wrapper നിർമ്മിക്കുന്ന ഒരു CI ജോബ്.
  • Postman collection – ആരും ഉപയോഗിക്കാത്ത ഒരു ഷെയർഡ് ടെസ്റ്റിംഗ് ആർട്ടീഫാക്റ്റ്.
  • Manual TypeScript interfaces – സെർവറുമായി സിങ്ക് ആയിരിക്കേണ്ട കൈകൊണ്ട് എഴുതിയ ടൈപ്പുകൾ.

ഓരോ API മാറ്റവും ഈ ആർട്ടീഫാക്റ്റുകളിൽ കുറഞ്ഞത് മൂന്നെണ്ണത്തെയെങ്കിലും, കൂടാതെ validator-നെയും ഡൗൺസ്ട്രീം fetch കോളുകളെയും ബാധിക്കുമായിരുന്നു. ഈ പ്രക്രിയ തെറ്റുകൾ സംഭവിക്കാൻ സാധ്യതയുള്ളതും സാവധാനത്തിലുള്ളതുമായിരുന്നു.

tRPC എങ്ങനെ കോഡ്ബേസ് കുറച്ചു

tRPC പ്രത്യേക കോൺട്രാക്റ്റ് ഫയലുകളുടെ ആവശ്യം ഇല്ലാതാക്കുന്നു. സെർവർ ഒരു router type എക്‌സ്‌പോർട്ട് ചെയ്യുന്നു; ക്ലയന്റ് അതേ ടൈപ്പ് ഇംപോർട്ട് ചെയ്യുന്നു. ബാക്കെൻഡ് ഫീൽഡ് മാറ്റിയാൽ, കോഡ് റൺ ചെയ്യുകയോ റിക്വസ്റ്റ് പരാജയപ്പെടുകയോ ചെയ്യുന്നതിന് മുമ്പ് തന്നെ എഡിറ്റർ ആ വ്യത്യാസം ഉടൻ തന്നെ കാണിച്ചുതരുന്നു. ഡെവലപ്പർ ഇവ ഒഴിവാക്കി:

  • OpenAPI spec ഫയൽ.
  • Client SDK generation step.
  • ഉപയോഗിക്കാത്ത Postman collection.
  • മാനുവൽ TypeScript interfaces അടങ്ങിയ ഫോൾഡർ.

റെപ്പോസിറ്ററി കൂടുതൽ ലളിതമായി, ഡെപ്ലോയ്‌മെന്റിന് പകരം ഡെവലപ്‌മെന്റ് സമയത്ത് തന്നെ ഫീഡ്‌ബാക്ക് ലഭിച്ചു തുടങ്ങി.

tRPC-യുടെ പരിമിതികൾ

രണ്ട് ഭാഗങ്ങളിലും TypeScript ഉപയോഗിക്കുമ്പോൾ മാത്രമേ tRPC പ്രവർത്തിക്കൂ. താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ ഇത് പരിമിതികൾ നേരിടുന്നു:

  • ഒരു മൊബൈൽ ടീം Swift അല്ലെങ്കിൽ Kotlin ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ.
  • API പുറത്തുള്ള പങ്കാളികൾ (external partners) ഉപയോഗിക്കേണ്ടതുണ്ടെങ്കിൽ.
  • നിങ്ങൾക്ക് ഒരു പബ്ലിക്, ലാംഗ്വേജ്-അഗ്നോസ്റ്റിക് (language-agnostic) ഇന്റർഫേസ് ആവശ്യമുണ്ടെങ്കിൽ.

മൈഗ്രേഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ആവശ്യപ്പെട്ടത്

രണ്ട് ആഴ്ച നീണ്ട ഈ പരിശ്രമം വെറുമൊരു കോപ്പി-പേസ്റ്റ് ആയിരുന്നില്ല. ഡെവലപ്പർ ഇവ ചെയ്യേണ്ടി വന്നു:

  • tRPC-യുടെ ക്ലയന്റ് ഫംഗ്ഷനുകൾ ഉപയോഗിക്കുന്നതിനായി ഓരോ fetch കോളും വീണ്ടും എഴുതുക.
  • എറർ-ഹാൻഡ്‌ലിംഗ് ലോജിക് ക്രമീകരിക്കുക.
  • റോ (raw) HTTP റെസ്‌പോൺസുകളെ ആശ്രയിച്ചിരുന്ന ലോഡിംഗ്, റീട്രൈ സ്റ്റേറ്റുകൾ ഉപയോഗിക്കുന്ന UI കമ്പോണന്റുകൾ അപ്‌ഡേറ്റ് ചെയ്യുക.

തുടങ്ങുന്നതിന് മുമ്പ് ചോദിക്കേണ്ട ചോദ്യങ്ങൾ

  • ഫ്രണ്ട്‌എൻഡും ബാക്കെൻഡും TypeScript ഉപയോഗിക്കുന്നുണ്ടോ? ഒരു ഷെയർഡ് ടൈപ്പ് സിസ്റ്റം ഇല്ലാതെ tRPC-യുടെ പ്രധാന നേട്ടം നഷ്ടപ്പെടും.
  • രണ്ട് വശങ്ങളും കൈകാര്യം ചെയ്യുന്നത് ഒരേ ടീമാണോ? ഉത്തരവാദിത്തങ്ങളിലെ വ്യത്യാസം കോൺട്രാക്റ്റുകളിൽ വീണ്ടും മാറ്റങ്ങൾ വരാൻ കാരണമായേക്കാം.
  • നിങ്ങൾ ഒരു യഥാർത്ഥ ബഗ്ഗ് പരിഹരിക്കുകയാണോ അതോ വെറുമൊരു ട്രെൻഡ് പിന്തുടരുകയാണോ? ഉൽപ്പാദനക്ഷമത വർദ്ധിപ്പിക്കുന്നത് സത്യമാണ്, പക്ഷേ അത് നിലവിലുള്ള ഒരു പ്രശ്നം പരിഹരിക്കാൻ സഹായിക്കുന്നതാകണം.

2025-ലേക്കുള്ള ഒരു ഹൈബ്രിഡ് സമീപനം

രണ്ട് സ്റ്റാക്കുകളും ഒരേസമയം ഉപയോഗിക്കുന്നതിലൂടെ പല ടീമുകളും മികച്ച ഫലം കണ്ടെത്തുന്നു:

  • ഇന്റേണൽ ആപ്ലിക്കേഷൻ ലെയറുകൾക്കായി tRPC: കോഡ്ബേസ് പൂർണ്ണമായും TypeScript ആയപ്പോഴും, സെർവറും ക്ലയന്റും ഒരേ ടീം കൈകാര്യം ചെയ്യുമ്പോഴും ഇത് ഉപയോഗിക്കാം.
  • വെബ്ഹുക്കുകൾ (webhooks), പബ്ലിക് API-കൾ, പാർട്ണർ ഇന്റഗ്രേഷനുകൾ എന്നിവയ്ക്കായി REST: ലാംഗ്വേജ്-അഗ്നോസ്റ്റിക് ആക്സസ് ആവശ്യമായ ഇടങ്ങളിൽ ഇത് ഉപയോഗിക്കാം.

ഓരോ ആവശ്യത്തിനും അനുയോജ്യമായ ടൂൾ ഉപയോഗിക്കുന്നത് ഇന്റേണൽ ഡെവലപ്‌മെന്റ് വേഗത്തിലാക്കുന്നതിനൊപ്പം പുറത്തുള്ള ഉപഭോക്താക്കൾക്ക് ആവശ്യമായ ഓപ്പൺനെസ് നിലനിർത്താനും സഹായിക്കുന്നു.

ചുരുക്കത്തിൽ: REST-ന് പകരം tRPC ഉപയോഗിക്കുന്നത് ഡ്യൂപ്ലിക്കേറ്റ് കോൺട്രാക്റ്റ് ആർട്ടീഫാക്റ്റുകൾ ഒഴിവാക്കാനും എഡിറ്റ് ചെയ്യുന്ന സമയത്ത് തന്നെ ബഗ്ഗുകൾ കണ്ടെത്താനും സഹായിക്കും. എന്നാൽ മുഴുവൻ സ്റ്റാക്കും TypeScript പങ്കിടുന്നതാകുമ്പോഴും മൈഗ്രേഷൻ ചിലവ് താങ്ങാൻ ടീമിന് കഴിയുമ്പോഴും മാത്രമേ ഇതിന്റെ ഗുണങ്ങൾ പൂർണ്ണമായി ലഭിക്കൂ. ഒരു മിക്സഡ് സ്ട്രാറ്റജി ഉപയോഗിക്കുന്നതിലൂടെ non-TypeScript ഉപഭോക്താക്കളെ ഒഴിവാക്കാതെ തന്നെ നിങ്ങൾക്ക് ഇതിന്റെ ഗുണങ്ങൾ പ്രയോജനപ്പെടുത്താം.