ஒரு frontend குழு, மேம்பாட்டு நிலையில் (development) மட்டுமே செயல்படும் ஒரு type-safe API-mocking அடுக்கை (layer) அறிமுகப்படுத்தியது. Axios interceptors மற்றும் Vite-ன் tree-shaking ஆகியவற்றைப் பயன்படுத்துவதன் மூலம், production bundle பாதிக்கப்படாமல் இருப்பதை அவர்கள் உறுதி செய்துள்ளனர். பொறியாளர்கள் backend endpoints-களுக்காகக் காத்திருக்கும்போது, வழக்கமான முறையிலேயே தரவை (data) பெறலாம்; பின்னர் ஒரு environment flag-ஐ மாற்றுவதன் மூலம் உண்மையான API-யை அணுக முடியும்.

Mock செய்வதற்கு ஏன் ஒரு சிறந்த வழி தேவைப்பட்டது

Backend route முழுமையடையாதபோது frontend டெவலப்பர்கள் ஒரு தடையை எதிர்கொள்கிறார்கள். ஒரு component-க்குள் response-ஐ hard-code செய்வது அல்லது UI முழுவதும் if (process.env.NODE_ENV === 'development') போன்ற பிளாக்குகளைச் சிதறவிடுவது போன்ற தற்காலிகத் தீர்வுகள், செயலியைத் தொடர்ந்து இயக்க உதவினாலும், அவை தொழில்நுட்பக் கடனை (technical debt) உருவாக்குகின்றன. அந்த mock objects component-ன் தர்க்கத்தின் (logic) ஒரு பகுதியாக மாறிவிடுகின்றன, இது production-க்கு போலித் தரவை அனுப்பும் அபாயத்தை அதிகரிப்பதோடு, குறியீட்டைப் படிப்பது மற்றும் சோதனை செய்வதையும் கடினமாக்குகிறது.

ஒவ்வொரு mock-ஐயும் component tree-யிலிருந்து வெளியே கொண்டு வரவும், front மற்றும் back ends இடையே ஒரு ஒப்பந்தத்தை (contract) நடைமுறைப்படுத்தவும், production build-ல் தேவையற்ற எதுவும் சேராமல் இருப்பதை உறுதி செய்யவும் குழு விரும்பியது.

குழு பின்பற்றும் மூன்று படிநிலை செயல்முறை

  1. ஒப்பந்தக் கூட்டம் (Contract meeting) – Frontend மற்றும் backend பொறியாளர்கள் அமர்ந்து ஒவ்வொரு request, அதன் URL, method மற்றும் எதிர்பார்க்கப்படும் payload ஆகியவற்றைப் பட்டியலிடுகிறார்கள்.
  2. வகைப்படுத்தப்பட்ட ஒப்பந்தம் (Typed contract) – அந்தப் பட்டியலை ஒரு TypeScript interface-ஆக மாற்றுகிறார்கள், இது request மற்றும் response வடிவங்களுக்கான ஒரே உண்மையான ஆதாரமாக (single source of truth) அமைகிறது.
  3. Interceptor இணைப்பு (Interceptor wiring) – ஒரு Axios interceptor ஒவ்வொரு outgoing request-யையும் ஆய்வு செய்கிறது. URL ஒரு பதிவு செய்யப்பட்ட mock-உடன் பொருந்தினால், interceptor mock தரவைத் திருப்பித் தரும்; இல்லையெனில், request நேரடிச் சேவையகத்திற்கு (live server) செல்லும்.

Interceptor என்பது mock logic இருக்கும் ஒரே இடமாக இருப்பதால், component குறியீடு மாற்றமடையாமல் இருக்கும். டெவலப்பர்கள் எந்தவொரு நிபந்தனைத் தர்க்கத்தையும் (conditional logic) சேர்க்காமல், useQuery போன்ற தங்களின் இயல்பான data-fetching hooks-களைத் தொடர்ந்து பயன்படுத்தலாம்.

Production அளவை அதிகரிப்பதைத் (bloat) தவிர்ப்பது எப்படி

Vite பயன்படுத்தும் Rollup (bundler) production-க்காக உருவாக்கும்போது mock குறியீட்டை முழுமையாக நீக்குவதற்கு, குழு மூன்று பாதுகாப்பு முறைகளைச் செயல்படுத்தியது:

  • import.meta.env.DEV என்பது production build-ல் false எனத் தீர்மானிக்கப்படுகிறது, எனவே tree-shaking செய்யும்போது முழு interceptor module-உம் மறைந்துவிடும்.
  • Unit test-களை இயக்கும்போது MODE மாறி (variable) test தவிர வேறு ஏதேனும் ஒன்றாக அமைக்கப்படுகிறது, இது test-க்கு மட்டுமே தேவையான குறியீட்டைத் தனிமைப்படுத்துகிறது.
  • VITE_ENABLE_MSW என்ற தனிப்பயன் flag, இயல்பாக false என இருக்கும், mock-ஐச் செயல்படுத்த இதைத் தெளிவாக ஆன் செய்ய வேண்டும்.

இந்த மூன்று நிபந்தனைகளும் false ஆக இருக்கும்போது, mock registry இறுதி bundle-க்குள் நுழையாது.

Mock கோப்புகளை ஒழுங்கமைத்தல்

இந்த repo ஒரு feature-centric அமைப்பைப் பின்பற்றுகிறது:

  • interfaces/ – ஒப்பந்தக் கூட்டத்திலிருந்து உருவாக்கப்பட்ட TypeScript வரையறைகளை (definitions) வைத்திருக்கும்.
  • scenarios.ts – ஒவ்வொரு endpoint-க்கும் வெற்றிகரமான பதில்கள் மற்றும் பிழை நிலைகளுக்கான (error cases) உறுதியான உதாரணங்களைக் கொண்டிருக்கும்.
  • devHandlers.ts – URL-களை scenario தரவுகளுடன் இணைக்கும் மற்றும் Axios-ல் interceptor-ஐ இணைக்கும் மையப் பதிவேடாக (central registry) செயல்படும்.

ஒரு சிறிய scaffolding script மூலம் இந்த கோப்புகளைத் தானாகவே உருவாக்க முடியும்: ஒரு URL மற்றும் அதற்குப் பொருத்தமான interface-ஐக் கொடுத்தால், அது stub கோப்புகளை உருவாக்கி mock-ஐப் பதிவு செய்யும். இந்த script production குறியீட்டுப் பாதைக்கு வெளியே இருப்பதால், இது bundle அளவைப் பாதிக்காது.

குழுவால் பெறப்பட்ட நன்மைகள்

  • Component-களுக்குள் mock-கள் இல்லை – அனைத்து போலித் தரவுகளும் ஒரு பிரத்யேக அடுக்கில் இருப்பதால், UI குறியீடு தூய்மையாக இருக்கும்.
  • End-to-end வகை பாதுகாப்பு (type safety) – Mock தரவு உண்மையான பதில்களுக்குப் பயன்படுத்தப்படும் அதே TypeScript interfaces-களைப் பின்பற்றுவதால், பொருத்தமின்மைகள் (mismatches) compile time-லேயே கண்டறியப்படுகின்றன.
  • Production எடையில்லை – Tree-shaking மூலம் interceptor மற்றும் mock தரவு முழுமையாக நீக்கப்படுவதால், bundle அளவு மாறாமல் இருக்கும்.
  • Dev மற்றும் test-களுக்கான பகிரப்பட்ட scenarios – ஒரே mock வரையறைகள் உள்ளூர் மேம்பாடு (local development) மற்றும் தானியங்கி சோதனைகள் (automated tests) ஆகிய இரண்டிற்கும் பயன்படுவதால், நகல் வேலைகள் (duplication) குறைகின்றன.

சவால்கள் மற்றும் வரம்புகள்

இந்த அணுகுமுறை ஒரு உண்மையான backend-க்கு மாற்றாகாது. ஒருவேளை mock ஒப்பந்தம் நேரடி API-யிலிருந்து மாறுபட்டுவிட்டால், environment flag-ஐ மாற்றிய பின்னரே டெவலப்பர்கள் அந்தப் பொருத்தமின்மையைக் கண்டறிய முடியும்.

அடுத்து கவனிக்க வேண்டியவை

  • கருவி ஒருங்கிணைப்பு (Tooling integration) –
  • பரவலான பயன்பாடு (Broader adoption) –
  • செயல்திறன் கண்காணிப்பு (Performance monitoring) –

இதிலிருந்து நாம் கற்றுக்கொள்ளும் பாடம் தெளிவானது: mock logic-ஐ ஒரு வகைப்படுத்தப்பட்ட (typed), environment-களால் கட்டுப்படுத்தப்படும் அடுக்கிற்கு மாற்றுவதன் மூலம், frontend குழுக்கள் component-களைத் தூய்மையாகவும், type-safe ஆகவும் வைத்திருக்க முடியும், மேலும் மறைமுகமான mock payloads இல்லாமல் production builds-களை வெளியிட முடியும். ஒரு சுமூகமான மேம்பாட்டுப் பணிப்பாய்வு மற்றும் சுத்தமான குறியீட்டுத் தொகுப்பிற்கு (codebase), ஒரு பகிரப்பட்ட ஒப்பந்தத்தைப் பராமரிப்பதே விலையாகும்.