एक फ्रंटएंड टीम ने एक टाइप-सेफ (type-safe) API-mocking लेयर पेश की है जो केवल डेवलपमेंट के दौरान ही काम करती है। Axios interceptors और Vite के tree-shaking का उपयोग करके, प्रोडक्शन बंडल को बिना छेड़े रखा जाता है। इंजीनियर बैकएंड एंडपॉइंट्स का इंतज़ार करते समय अपने सामान्य पैटर्न के साथ डेटा फेच (fetch) करते हैं, और फिर असली API तक पहुँचने के लिए बस एक सिंगल एनवायरनमेंट फ्लैग (environment flag) बदल देते हैं।
टीम को मॉक (mock) करने के लिए बेहतर तरीके की आवश्यकता क्यों थी
जब बैकएंड रूट अधूरा होता है, तो फ्रंटएंड डेवलपर्स के सामने रुकावट आ जाती है। इसका त्वरित समाधान—किसी कंपोनेंट के अंदर रिस्पॉन्स को हार्ड-कोड करना या पूरे UI में if (process.env.NODE_ENV === 'development') ब्लॉक्स का उपयोग करना—ऐप को तो आगे बढ़ाता है लेकिन तकनीकी ऋण (technical debt) छोड़ जाता है। वे मॉक ऑब्जेक्ट्स कंपोनेंट के लॉजिक का हिस्सा बन जाते हैं, प्रोडक्शन में नकली डेटा भेजने का जोखिम बढ़ाते हैं, और कोड को पढ़ना और टेस्ट करना कठिन बना देते हैं।
टीम चाहती थी कि हर मॉक को कंपोनेंट ट्री से बाहर निकाला जाए, फ्रंट और बैक एंड के बीच एक कॉन्ट्रैक्ट (contract) लागू किया जाए, और यह सुनिश्चित किया जाए कि प्रोडक्शन बिल्ड में कुछ भी अतिरिक्त न जाए।
टीम द्वारा पालन की जाने वाली तीन-चरणीय प्रक्रिया
- कॉन्ट्रैक्ट मीटिंग (Contract meeting) – फ्रंटएंड और बैकएंड इंजीनियर साथ बैठते हैं और प्रत्येक रिक्वेस्ट, उसके URL, मेथड और अपेक्षित पेलोड (payload) की सूची बनाते हैं।
- टाइप्ड कॉन्ट्रैक्ट (Typed contract) – वे इस सूची को एक TypeScript इंटरफ़ेस में बदल देते हैं जो रिक्वेस्ट और रिस्पॉन्स के आकार (shapes) के लिए सिंगल सोर्स ऑफ ट्रुथ (single source of truth) बन जाता है।
- इंटरसेप्टर वायरिंग (Interceptor wiring) – एक Axios interceptor हर आउटगोइंग रिक्वेस्ट की जांच करता है। यदि URL किसी रजिस्टर्ड मॉक से मेल खाता है, तो इंटरसेप्टर मॉक डेटा लौटाता है; अन्यथा रिक्वेस्ट लाइव सर्वर पर चली जाती है।
क्योंकि इंटरसेप्टर ही एकमात्र जगह है जहाँ मॉक लॉजिक रहता है, कंपोनेंट कोड अपरिवर्तित रहता है। डेवलपर्स बिना किसी कंडीशनल लॉजिक को जोड़े अपने सामान्य डेटा-फेचिंग हुक्स—जैसे कि useQuery—का उपयोग करना जारी रखते हैं।
प्रोडक्शन ब्लोट (production bloat) से कैसे बचा जाता है
टीम ने तीन सुरक्षा उपाय (safeguards) लागू किए हैं जो Rollup (Vite द्वारा उपयोग किया जाने वाला बंडलर) को प्रोडक्शन के लिए बिल्ड करते समय मॉक कोड को पूरी तरह से हटाने की अनुमति देते हैं:
- प्रोडक्शन बिल्ड में
import.meta.env.DEVका मानfalseहो जाता है, इसलिए tree-shaking के दौरान पूरा इंटरसेप्टर मॉड्यूल गायब हो जाता है। - यूनिट टेस्ट चलाते समय
MODEवेरिएबल कोtestके अलावा कुछ और पर सेट किया जाता है, जिससे केवल टेस्ट वाला कोड अलग रहता है। - एक कस्टम फ्लैग,
VITE_ENABLE_MSW, डिफ़ॉल्ट रूप सेfalseहोता है और मॉक को सक्रिय करने के लिए इसे स्पष्ट रूप से चालू करना पड़ता है।
जब तीनों शर्तें false होती हैं, तो मॉक रजिस्ट्री कभी भी फाइनल बंडल में नहीं पहुँच पाती है।
मॉक फाइलों को व्यवस्थित करना
रिपॉजिटरी एक फीचर-केंद्रित लेआउट का पालन करती है:
interfaces/– कॉन्ट्रैक्ट मीटिंग से उत्पन्न TypeScript डेफिनिशन को रखता है।scenarios.ts– प्रत्येक एंडपॉइंट के लिए सफल रिस्पॉन्स और एरर केस के ठोस उदाहरणों को रखता है।devHandlers.ts– एक सेंट्रल रजिस्ट्री के रूप में कार्य करता है जो URL को सिनेरियो डेटा (scenario data) से मैप करता है और इंटरसेप्टर को Axios में प्लग करता है।
एक छोटा स्कैफोल्डिंग स्क्रिप्ट (scaffolding script) इन फाइलों को स्वचालित रूप से बना सकता है: इसे एक URL और मैचिंग इंटरफ़ेस दें, और यह स्टब फाइल्स बना देगा और मॉक को रजिस्टर कर देगा। यह स्क्रिप्ट प्रोडक्शन कोड पाथ के बाहर रहती है, इसलिए यह बंडल साइज को प्रभावित नहीं करती है।
टीम को क्या हासिल हुआ
- कंपोनेंट्स के अंदर ज़ीरो मॉक – सारा नकली डेटा एक समर्पित लेयर में रहता है, जिससे UI कोड साफ रहता है।
- एंड-टू-एंड टाइप सेफ्टी – मॉक डेटा उन्हीं TypeScript इंटरफ़ेस का पालन करता है जिनका उपयोग असली रिस्पॉन्स के लिए किया जाता है, इसलिए मिसमैच (mismatch) को कंपाइल टाइम पर ही पकड़ लिया जाता है।
- कोई प्रोडक्शन वेट नहीं – Tree-shaking इंटरसेप्टर और मॉक डेटा को पूरी तरह से हटा देता है, जिससे बंडल साइज अपरिवर्तित रहता है।
- डेव और टेस्ट के लिए साझा सिनेरियो – वही मॉक डेफिनिशन लोकल डेवलपमेंट और ऑटोमेटेड टेस्ट दोनों को चलाती है, जिससे डुप्लीकेशन कम होता है।
ट्रेड-ऑफ (trade-offs) और सीमाएं
यह दृष्टिकोण असली बैकएंड का विकल्प नहीं है। यदि मॉक कॉन्ट्रैक्ट लाइव API से अलग हो जाता है, तो डेवलपर्स को मिसमैच का पता तभी चलता है जब वे एनवायरनमेंट फ्लैग बदलते हैं।
आगे क्या देखना है
- टूलिंग इंटीग्रेशन (Tooling integration) –
- व्यापक अपनाना (Broader adoption) –
- परफॉरमेंस मॉनिटरिंग (Performance monitoring) –
निष्कर्ष स्पष्ट है: मॉक लॉजिक को एक टाइप्ड, एनवायरनमेंट-गेटेड लेयर में ले जाने से फ्रंटएंड टीमें कंपोनेंट्स को स्वच्छ रख सकती हैं, टाइप-सेफ रह सकती हैं, और बिना किसी छिपे हुए मॉक पेलोड के प्रोडक्शन बिल्ड शिप कर सकती हैं। एक साझा कॉन्ट्रैक्ट बनाए रखना एक सुचारू डेवलपमेंट वर्कफ़्लो और एक स्वच्छ कोडबेस की कीमत है।