ഒരു ഫ്രണ്ട്‌എൻഡ് ടീം ഡെവലപ്‌മെന്റ് സമയത്ത് മാത്രം ഉപയോഗിക്കുന്ന ഒരു ടൈപ്പ്-സേഫ് (type-safe) API-mocking ലെയർ അവതരിപ്പിച്ചു. Axios interceptors-ഉം Vite-ന്റെ tree-shaking-ഉം ഉപയോഗിക്കുന്നതിലൂടെ പ്രൊഡക്ഷൻ ബണ്ടിൽ (production bundle) മാറ്റമില്ലാതെ നിലനിർത്താൻ സാധിക്കുന്നു. ബാക്കെൻഡ് എൻഡ്‌പോയിന്റുകൾക്കായി കാത്തിരിക്കുമ്പോൾ എൻജിനീയർമാർക്ക് അവരുടെ പതിവ് രീതികളിൽ ഡാറ്റ ഫെച്ച് ചെയ്യാം, പിന്നീട് ഒരു സിംഗിൾ എൻവയോൺമെന്റ് ഫ്ലാഗ് (environment flag) മാറ്റുന്നതിലൂടെ യഥാർത്ഥ API ഉപയോഗിക്കാൻ സാധിക്കും.

മോക്കിംഗിനായി (mocking) ടീമിന് മെച്ചപ്പെട്ട ഒരു മാർഗ്ഗം എന്തുകൊണ്ട് ആവശ്യമായി വന്നു

ഒരു ബാക്കെൻഡ് റൂട്ട് പൂർത്തിയായിട്ടില്ലെങ്കിൽ ഫ്രണ്ട്‌എൻഡ് ഡെവലപ്പർമാർക്ക് തടസ്സങ്ങൾ നേരിടേണ്ടി വരും. ഒരു കമ്പോണന്റിനുള്ളിൽ തന്നെ റെസ്‌പോൺസ് ഹാർഡ്-കോഡ് ചെയ്യുന്നതോ അല്ലെങ്കിൽ UIയിലുടനീളം if (process.env.NODE_ENV === 'development') ബ്ലോക്കുകൾ ഉപയോഗിക്കുന്നതോ ഒരു താൽക്കാലിക പരിഹാരമാണ്. ഇത് ആപ്പ് പ്രവർത്തിപ്പിക്കാൻ സഹായിക്കുമെങ്കിലും ടെക്നിക്കൽ ഡെബ്റ്റ് (technical debt) ഉണ്ടാക്കുന്നു. ഇത്തരം മോക്ക് ഒബ്‌ജക്റ്റുകൾ കമ്പോണന്റിന്റെ ലോജിക്കിന്റെ ഭാഗമായി മാറുകയും, പ്രൊഡക്ഷനിലേക്ക് വ്യാജ ഡാറ്റ എത്തുന്നതിനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുകയും, കോഡ് വായിക്കാനും ടെസ്റ്റ് ചെയ്യാനും പ്രയാസകരമാക്കുകയും ചെയ്യുന്നു.

എല്ലാ മോക്കുകളെയും കമ്പോണന്റ് ട്രീയിൽ നിന്ന് മാറ്റാനും, ഫ്രണ്ട്‌എൻഡും ബാക്കെൻഡും തമ്മിൽ ഒരു കരാർ (contract) ഉറപ്പാക്കാനും, പ്രൊഡക്ഷൻ ബിൽഡിൽ അനാവശ്യമായ ഒന്നും ഉൾപ്പെടില്ലെന്ന് ഉറപ്പുവരുത്താനും ടീം ആഗ്രഹിച്ചു.

ടീം പിന്തുടരുന്ന മൂന്ന് ഘട്ടങ്ങളുള്ള പ്രക്രിയ

  1. Contract meeting – ഫ്രണ്ട്‌എൻഡ്, ബാക്കെൻഡ് എൻജിനീയർമാർ ഒത്തുചേർന്ന് ഓരോ റിക്വസ്റ്റും, അതിന്റെ URL, മെത്തേഡ്, പ്രതീക്ഷിക്കുന്ന പേലോഡ് (payload) എന്നിവ പട്ടികപ്പെടുത്തുന്നു.
  2. Typed contract – അവർ ഈ പട്ടികയെ ഒരു TypeScript ഇന്റർഫേസ് (interface) ആക്കി മാറ്റുന്നു. ഇത് റിക്വസ്റ്റ്, റെസ്‌പോൺസ് രൂപങ്ങൾ എന്നിവയുടെ ഏക സ്രോതസ്സായി (single source of truth) മാറുന്നു.
  3. Interceptor wiring – ഒരു Axios interceptor ഓരോ ഔട്ട്‌ഗോയിംഗ് റിക്വസ്റ്റും പരിശോധിക്കുന്നു. URL ഒരു രജിസ്റ്റർ ചെയ്ത മോക്കുമായി പൊരുത്തപ്പെടുന്നുണ്ടെങ്കിൽ, ഇന്റർസെപ്റ്റർ മോക്ക് ഡാറ്റ തിരികെ നൽകുന്നു; അല്ലെങ്കിൽ റിക്വസ്റ്റ് ലൈവ് സെർവറിലേക്ക് പോകുന്നു.

ഇന്റർസെപ്റ്റർ മാത്രമാണ് മോക്ക് ലോജിക്കിന്റെ ഏക ഇടമായതുകൊണ്ട്, കമ്പോണന്റ് കോഡിൽ മാറ്റം വരുത്തേണ്ടതില്ല. ഡെവലപ്പർമാർക്ക് യാതൊരു കണ്ടീഷനൽ ലോജിക്കും ചേർക്കാതെ തന്നെ useQuery പോലുള്ള സാധാരണ ഡാറ്റാ-ഫെച്ചിംഗ് ഹുക്കുകൾ (data-fetching hooks) ഉപയോഗിക്കാം.

പ്രൊഡക്ഷൻ ബ്ലോട്ട് (production bloat) എങ്ങനെ ഒഴിവാക്കാം

പ്രൊഡക്ഷനായി ബിൽഡ് ചെയ്യുമ്പോൾ മോക്ക് കോഡ് പൂർണ്ണമായും നീക്കം ചെയ്യാൻ Rollup-ന് (Vite ഉപയോഗിക്കുന്ന ബണ്ട്ലർ) സാധിക്കുന്ന മൂന്ന് സുരക്ഷാ സംവിധാനങ്ങൾ ടീം നടപ്പിലാക്കി:

  • പ്രൊഡക്ഷൻ ബിൽഡിൽ import.meta.env.DEV എന്നത് false ആയി മാറുന്നു, അതിനാൽ tree-shaking സമയത്ത് മുഴുവൻ ഇന്റർസെപ്റ്റർ മോഡ്യൂളും നീക്കം ചെയ്യപ്പെടുന്നു.
  • യൂണിറ്റ് ടെസ്റ്റുകൾ നടത്തുമ്പോൾ MODE വേരിയബിൾ test അല്ലാത്ത മറ്റൊന്നായി ക്രമീകരിക്കുന്നു, ഇത് ടെസ്റ്റ് ആവശ്യങ്ങൾക്കുള്ള കോഡിനെ വേർതിരിച്ചു നിർത്തുന്നു.
  • VITE_ENABLE_MSW എന്ന കസ്റ്റം ഫ്ലാഗ് ഡിഫോൾട്ട് ആയി false ആണ്, മോക്ക് ആക്ടിവേഷന് ഇത് പ്രത്യേകം ഓൺ ചെയ്യേണ്ടതുണ്ട്.

ഈ മൂന്ന് നിബന്ധനകളും തെറ്റാണെങ്കിൽ (false), മോക്ക് രജിസ്ട്രി ഫൈനൽ ബണ്ടിലിൽ എത്തില്ല.

മോക്ക് ഫയലുകൾ ക്രമീകരിക്കുന്നത് എങ്ങനെ

ഈ റെപ്പോസിറ്ററി ഒരു ഫീച്ചർ-സെൻട്രിക് (feature-centric) ലേഔട്ട് പിന്തുടരുന്നു:

  • interfaces/ – കോൺട്രാക്ട് മീറ്റിംഗിൽ നിന്ന് നിർമ്മിച്ച TypeScript ഡെഫനിഷനുകൾ ഇവിടെ സൂക്ഷിക്കുന്നു.
  • scenarios.ts – ഓരോ എൻഡ്‌പോയിന്റിനും വിജയകരമായ റെസ്‌പോൺസുകളുടെയും എറർ കേസുകളുടെയും കൃത്യമായ ഉദാഹരണങ്ങൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നു.
  • devHandlers.ts – URL-കളെ സീനറിയോ ഡാറ്റയുമായി ബന്ധിപ്പിക്കുകയും ഇന്റർസെപ്റ്ററിനെ Axios-ലേക്ക് ഘടിപ്പിക്കുകയും ചെയ്യുന്ന സെൻട്രൽ രജിസ്ട്രിയായി ഇത് പ്രവർത്തിക്കുന്നു.

ഒരു ചെറിയ സ്കാഫോൾഡിംഗ് സ്ക്രിപ്റ്റ് (scaffolding script) ഉപയോഗിച്ച് ഈ ഫയലുകൾ സ്വയമേവ നിർമ്മിക്കാം: ഒരു URL-ഉം അതിന് അനുയോജ്യമായ ഇന്റർഫേസും നൽകിയാൽ, അത് സ്റ്റബ് ഫയലുകൾ (stub files) നിർമ്മിക്കുകയും മോക്ക് രജിസ്റ്റർ ചെയ്യുകയും ചെയ്യുന്നു. ഈ സ്ക്രിപ്റ്റ് പ്രൊഡക്ഷൻ കോഡ് പാതയ്ക്ക് പുറത്തായതുകൊണ്ട് ബണ്ടിൽ സൈസിനെ ഇത് ബാധിക്കില്ല.

ടീമിന് ലഭിച്ച നേട്ടങ്ങൾ

  • കമ്പോണന്റുകൾക്കുള്ളിൽ മോക്കുകൾ ഇല്ല – എല്ലാ വ്യാജ ഡാറ്റയും ഒരു പ്രത്യേക ലെയറിൽ സൂക്ഷിക്കുന്നതിലൂടെ UI കോഡ് വൃത്തിയായി നിലനിർത്താം.
  • എൻഡ്-ടു-എൻഡ് ടൈപ്പ് സേഫ്റ്റി (End-to-end type safety) – മോക്ക് ഡാറ്റ യഥാർത്ഥ റെസ്‌പോൺസുകൾക്കായി ഉപയോഗിക്കുന്ന അതേ TypeScript ഇന്റർഫേസുകൾ പാലിക്കുന്നതിനാൽ, പൊരുത്തക്കേടുകൾ കംപൈൽ സമയത്ത് തന്നെ കണ്ടെത്താനാകും.
  • പ്രൊഡക്ഷൻ ഭാരം ഇല്ല – Tree-shaking ഉപയോഗിച്ച് ഇന്റർസെപ്റ്ററും മോക്ക് ഡാറ്റയും പൂർണ്ണമായും നീക്കം ചെയ്യുന്നതിനാൽ ബണ്ടിൽ സൈസിൽ മാറ്റം വരുന്നില്ല.
  • ഡെവലപ്‌മെന്റിനും ടെസ്റ്റിംഗിനും ഒരേ സീനറിയോകൾ – ഒരേ മോക്ക് ഡെഫനിഷനുകൾ ലോക്കൽ ഡെവലപ്‌മെന്റിനും ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾക്കും ഉപയോഗിക്കുന്നത് ഡ്യൂപ്ലിക്കേഷൻ കുറയ്ക്കുന്നു.

പരിമിതികളും വെല്ലുവിളികളും

ഈ രീതി ഒരു യഥാർത്ഥ ബാക്കെൻഡിന് പകരമാവില്ല. മോക്ക് കോൺട്രാക്ട് യഥാർത്ഥ API-യിൽ നിന്ന് വ്യതിചലിച്ചാൽ, എൻവയോൺമെന്റ് ഫ്ലാഗ് മാറ്റുന്നതിന് ശേഷം മാത്രമേ ഡെവലപ്പർമാർക്ക് ആ വ്യത്യാസം മനസ്സിലാക്കാൻ സാധിക്കൂ.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • ടൂളിംഗ് ഇന്റഗ്രേഷൻ (Tooling integration) –
  • വിപുലമായ ഉപയോഗം (Broader adoption) –
  • പെർഫോമൻസ് മോണിറ്ററിംഗ് (Performance monitoring) –

ഇതിൽ നിന്നുള്ള പാഠം വ്യക്തമാണ്: മോക്ക് ലോജിക് ഒരു ടൈപ്പ്ഡ്, എൻവയോൺമെന്റ്-ഗേറ്റഡ് (environment-gated) ലെയറിലേക്ക് മാറ്റുന്നത് ഫ്രണ്ട്‌എൻഡ് ടീമുകളെ കമ്പോണന്റുകൾ ശുദ്ധമായി നിലനിർത്താനും, ടൈപ്പ് സേഫ്റ്റി ഉറപ്പാക്കാനും, ഒളിഞ്ഞിരിക്കുന്ന മോക്ക് പേലോഡുകൾ ഇല്ലാതെ പ്രൊഡക്ഷൻ ബിൽഡുകൾ പുറത്തിറക്കാനും സഹായിക്കുന്നു. സുഗമമായ ഡെവലപ്‌മെന്റ് വർക്ക്ഫ്ലോയ്ക്കും വൃത്തിയുള്ള കോഡ്ബേസിനും വേണ്ടി ഒരു പങ്കിട്ട കരാർ (shared contract) നിലനിർത്തുക എന്നത് അനിവാര്യമാണ്.