ਇੱਕ ਫਰੰਟਐਂਡ ਟੀਮ ਨੇ ਇੱਕ type-safe API-mocking ਲੇਅਰ ਲਾਂਚ ਕੀਤੀ ਜੋ ਸਿਰਫ਼ development ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। Axios interceptors ਅਤੇ Vite ਦੀ tree-shaking ਦੀ ਵਰਤੋਂ ਕਰਕੇ, production bundle ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਇੰਜੀਨੀਅਰ ਬੈਕਐਂਡ endpoints ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਆਪਣੇ ਆਮ ਪੈਟਰਨਾਂ ਨਾਲ ਡੇਟਾ ਫੈਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਅਸਲੀ API ਨਾਲ ਜੁੜਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ environment flag ਬਦਲਦੇ ਹਨ।

ਟੀਮ ਨੂੰ ਮੌਕ (mock) ਕਰਨ ਲਈ ਇੱਕ ਬਿਹਤਰ ਤਰੀਕੇ ਦੀ ਲੋੜ ਕਿਉਂ ਸੀ

ਜਦੋਂ ਬੈਕਐਂਡ ਰੂਟ ਅਧੂਰਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਫਰੰਟਐਂਡ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਰੁਕਾਵਟ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜਲਦੀ ਹੱਲ—ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਦੇ ਅੰਦਰ ਰਿਸਪਾਂਸ ਨੂੰ hard-code ਕਰਨਾ ਜਾਂ ਪੂਰੇ UI ਵਿੱਚ if (process.env.NODE_ENV === 'development') ਬਲਾਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ—ਐਪ ਨੂੰ ਚਲਾਉਂਦਾ ਤਾਂ ਹੈ ਪਰ technical debt ਛੱਡ ਜਾਂਦਾ ਹੈ। ਉਹ mock objects ਕੰਪੋਨੈਂਟ ਦੇ ਲੌਜਿਕ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੇ ਹਨ, production ਵਿੱਚ ਫੇਕ ਡੇਟਾ ਭੇਜਣ ਦਾ ਖ਼ਤਰਾ ਵਧਾਉਂਦੇ ਹਨ, ਅਤੇ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ।

ਟੀਮ ਚਾਹੁੰਦੀ ਸੀ ਕਿ ਹਰ mock ਨੂੰ component tree ਤੋਂ ਬਾਹਰ ਕੱਢਿਆ ਜਾਵੇ, ਫਰੰਟ ਅਤੇ ਬੈਕ ਐਂਡ ਵਿਚਕਾਰ ਇੱਕ contract ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ production build ਵਿੱਚ ਕੁਝ ਵੀ ਵਾਧੂ ਨਾ ਜਾਵੇ।

ਟੀਮ ਦੁਆਰਾ ਅਪਣਾਇਆ ਗਿਆ ਤਿੰਨ-ਪੜਾਵੀ ਪ੍ਰਕਿਰਿਆ

  1. Contract meeting – ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਇੰਜੀਨੀਅਰ ਇਕੱਠੇ ਬੈਠਦੇ ਹਨ ਅਤੇ ਹਰੇਕ request, ਉਸਦਾ URL, method, ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਜਾਣ ਵਾਲੇ payload ਦੀ ਸੂਚੀ ਬਣਾਉਂਦੇ ਹਨ।
  2. Typed contract – ਉਹ ਇਸ ਸੂਚੀ ਨੂੰ ਇੱਕ TypeScript interface ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਜੋ request ਅਤੇ response ਦੇ ਰੂਪਾਂ ਲਈ single source of truth ਬਣ ਜਾਂਦਾ ਹੈ।
  3. Interceptor wiring – ਇੱਕ Axios interceptor ਹਰੇਕ outgoing request ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ URL ਇੱਕ ਰਜਿਸਟਰਡ mock ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ interceptor mock ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ request ਲਾਈਵ ਸਰਵਰ ਵੱਲ ਵਧਦੀ ਹੈ।

ਕਿਉਂਕਿ interceptor ਹੀ ਇਕਲੌਤੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ mock ਲੌਜਿਕ ਰਹਿੰਦਾ ਹੈ, ਕੰਪੋਨੈਂਟ ਕੋਡ ਬਦਲਿਆ ਨਹੀਂ ਰਹਿੰਦਾ। ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਕਿਸੇ conditional logic ਨੂੰ ਜੋੜੇ ਆਪਣੇ ਆਮ data-fetching hooks—ਜਿਵੇਂ ਕਿ useQuery—ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।

Production bloat ਤੋਂ ਕਿਵੇਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ

ਟੀਮ ਨੇ ਤਿੰਨ ਸੁਰੱਖਿਆ ਉਪਾਅ ਲਾਗੂ ਕੀਤੇ ਹਨ ਜੋ Rollup (Vite ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ bundler) ਨੂੰ production ਲਈ ਬਿਲਡ ਕਰਦੇ ਸਮੇਂ mock ਕੋਡ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ:

  • import.meta.env.DEV production build ਵਿੱਚ false ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ tree-shaking ਦੌਰਾਨ ਪੂਰਾ interceptor module ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
  • ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਣ ਵੇਲੇ MODE variable ਨੂੰ test ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਹੋਰ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਿਰਫ਼ ਟੈਸਟ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਕੋਡ ਵੱਖਰਾ ਰਹਿੰਦਾ ਹੈ।
  • ਇੱਕ ਕਸਟਮ ਫਲੈਗ, VITE_ENABLE_MSW, ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ false ਹੁੰਦਾ ਹੈ ਅਤੇ mock ਨੂੰ ਐਕਟੀਵੇਟ ਕਰਨ ਲਈ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਚਾਲੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਜਦੋਂ ਤਿੰਨੋਂ ਸ਼ਰਤਾਂ false ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ mock registry ਕਦੇ ਵੀ ਫਾਈਨਲ bundle ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੀ।

Mock ਫਾਈਲਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ

ਰੇਪੋ (repo) ਇੱਕ feature-centric ਲੇਆਉਟ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ:

  • interfaces/ – Contract meeting ਤੋਂ ਤਿਆਰ ਕੀਤੇ TypeScript definitions ਨੂੰ ਰੱਖਦਾ ਹੈ।
  • scenarios.ts – ਹਰੇਕ endpoint ਲਈ ਸਫਲ ਰਿਸਪਾਂਸ ਅਤੇ error cases ਦੇ ਅਸਲ ਉਦਾਹਰਣਾਂ ਨੂੰ ਰੱਖਦਾ ਹੈ।
  • devHandlers.ts – ਇੱਕ ਕੇਂਦਰੀ ਰਜਿਸਟਰੀ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ URLs ਨੂੰ scenario ਡੇਟਾ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ ਅਤੇ interceptor ਨੂੰ Axios ਵਿੱਚ ਜੋੜਦਾ ਹੈ।

ਇੱਕ ਛੋਟਾ scaffolding script ਇਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ: ਇਸਨੂੰ ਇੱਕ URL ਅਤੇ ਮੇਲ ਖਾਂਦਾ interface ਦਿਓ, ਅਤੇ ਇਹ stub ਫਾਈਲਾਂ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ mock ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ। ਇਹ script production code path ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ bundle size ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੀ।

ਟੀਮ ਨੂੰ ਕੀ ਫਾਇਦਾ ਹੋਇਆ

  • ਕੰਪੋਨੈਂਟਸ ਦੇ ਅੰਦਰ ਜ਼ੀਰੋ ਮੌਕਸ (Zero mocks) – ਸਾਰਾ ਫੇਕ ਡੇਟਾ ਇੱਕ ਸਮਰਪਿਤ ਲੇਅਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ UI ਕੋਡ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ।
  • End-to-end type safety – Mock ਡੇਟਾ ਉਹੀ TypeScript interfaces ਵਰਤਦਾ ਹੈ ਜੋ ਅਸਲੀ ਰਿਸਪਾਂਸ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਗਲਤੀਆਂ compile time 'ਤੇ ਹੀ ਫੜ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ।
  • No production weight – Tree-shaking interceptor ਅਤੇ mock ਡੇਟਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ bundle size ਬਦਲਿਆ ਨਹੀਂ ਰਹਿੰਦਾ।
  • Dev ਅਤੇ test ਲਈ ਸਾਂਝੇ scenario – ਉਹੀ mock definitions ਸਥਾਨਕ development ਅਤੇ ਆਟੋਮੇਟਡ ਟੈਸਟ ਦੋਵਾਂ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਦੁਹਰਾਓ ਘੱਟ ਜਾਂਦਾ ਹੈ।

ਸਮਝੌਤੇ ਅਤੇ ਸੀਮਾਵਾਂ (Trade-offs and limits)

ਇਹ ਤਰੀਕਾ ਅਸਲੀ ਬੈਕਐਂਡ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦਾ। ਜੇਕਰ mock contract ਲਾਈਵ API ਤੋਂ ਵੱਖਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਗਲਤੀ ਉਦੋਂ ਹੀ ਪਤਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਉਹ environment flag ਬਦਲਦੇ ਹਨ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • Tooling integration –
  • Broader adoption –
  • Performance monitoring –

ਸਿੱਟਾ ਸਪੱਸ਼ਟ ਹੈ: mock ਲੌਜਿਕ ਨੂੰ ਇੱਕ typed, environment-gated ਲੇਅਰ ਵਿੱਚ ਲੈ ਕੇ ਜਾਣ ਨਾਲ ਫਰੰਟਐਂਡ ਟੀਮਾਂ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਸਾਫ਼ ਰੱਖ ਸਕਦੀ ਹੈ, type-safe ਰਹਿ ਸਕਦੀ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ hidden mock payloads ਦੇ production builds ਭੇਜ ਸਕਦੀ ਹੈ। ਇੱਕ ਸਾਂਝਾ contract ਬਣਾਈ ਰੱਖਣਾ ਇੱਕ ਸੁਚਾਰੂ development workflow ਅਤੇ ਸਾਫ਼ codebase ਦੀ ਕੀਮਤ ਹੈ।