ಒಂದು ಫ್ರಂಟ್‌ಎಂಡ್ ತಂಡವು ಕೇವಲ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಇರುವ type-safe API-mocking ಪದರವನ್ನು (layer) ಪರಿಚಯಿಸಿತು. Axios interceptors ಮತ್ತು Vite ನ tree-shaking ಅನ್ನು ಬಳಸುವ ಮೂಲಕ, production bundle ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಎಂಜಿನಿಯರ್‌ಗಳು ಬ್ಯಾಕ್‌ಎಂಡ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗಾಗಿ ಕಾಯುವಾಗ ತಮ್ಮ ಸಾಮಾನ್ಯ ಮಾದರಿಗಳಲ್ಲೇ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು, ನಂತರ ಕೇವಲ ಒಂದು environment flag ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನೈಜ API ಅನ್ನು ಬಳಸಬಹುದು.

ಮಾಕಿಂಗ್ (mocking) ಮಾಡಲು ತಂಡಕ್ಕೆ ಉತ್ತಮ ಮಾರ್ಗ ಏಕೆ ಬೇಕಾಯಿತು

ಬ್ಯಾಕ್‌ಎಂಡ್ ರೂಟ್ (route) ಅಪೂರ್ಣವಾಗಿದ್ದಾಗ ಫ್ರಂಟ್‌ಎಂಡ್ ಡೆವಲಪರ್‌ಗಳು ಅಡೆತಡೆ ಎದುರಿಸುತ್ತಾರೆ. ಕಾಂಪೊನೆಂಟ್‌ನ ಒಳಗೆ ರೆಸ್ಪಾನ್ಸ್ ಅನ್ನು hard-code ಮಾಡುವುದು ಅಥವಾ UIಾದ್ಯಂತ if (process.env.NODE_ENV === 'development') ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬಳಸುವಂತಹ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರಗಳು ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಲು ಸಹಾಯ ಮಾಡಬಹುದು, ಆದರೆ ಅವು technical debt ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. ಅಂತಹ mock objects ಕಾಂಪೊನೆಂಟ್‌ನ ಲಾಜಿಕ್‌ನ ಭಾಗವಾಗುತ್ತವೆ, ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ತಪ್ಪು ಡೇಟಾ ಹೋಗುವ ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಓದಲು ಹಾಗೂ ಪರೀಕ್ಷಿಸಲು ಕಷ್ಟವಾಗುವಂತೆ ಮಾಡುತ್ತವೆ.

ತಂಡವು ಪ್ರತಿಯೊಂದು ಮಾಕ್ ಅನ್ನು ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯಿಂದ ಹೊರಗೆ ತರಲು, ಫ್ರಂಟ್ ಮತ್ತು ಬ್ಯಾಕ್ ಎಂಡ್ ನಡುವೆ ಒಂದು contract ಅನ್ನು ಜಾರಿಗೊಳಿಸಲು ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಬಿಲ್ಡ್‌ನಲ್ಲಿ ಯಾವುದೇ ಅನಗತ್ಯ ಅಂಶಗಳು ಸೇರದಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಯಸಿತು.

ತಂಡವು ಅನುಸರಿಸುವ ಮೂರು ಹಂತದ ಪ್ರಕ್ರಿಯೆ

  1. Contract meeting – ಫ್ರಂಟ್‌ಎಂಡ್ ಮತ್ತು ಬ್ಯಾಕ್‌ಎಂಡ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಕುಳಿತು ಪ್ರತಿಯೊಂದು ರಿಕ್ವೆಸ್ಟ್, ಅದರ URL, method ಮತ್ತು ನಿರೀಕ್ಷಿತ payload ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತಾರೆ.
  2. Typed contract – ಅವರು ಆ ಪಟ್ಟಿಯನ್ನು TypeScript interface ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತಾರೆ, ಇದು ರಿಕ್ವೆಸ್ಟ್ ಮತ್ತು ರೆಸ್ಪಾನ್ಸ್ ರೂಪಗಳಿಗಾಗಿ ಏಕೈಕ ಸತ್ಯದ ಮೂಲವಾಗಿ (single source of truth) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
  3. Interceptor wiring – Axios interceptor ಪ್ರತಿಯೊಂದು ಹೊರಹೋಗುವ ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. URL ನೋಂದಾಯಿತ ಮಾಕ್‌ಗೆ ಹೊಂದಿಕೆಯಾದರೆ, interceptor ಮಾಕ್ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ ರಿಕ್ವೆಸ್ಟ್ ಲೈವ್ ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ.

Interceptor ನಲ್ಲಿ ಮಾತ್ರ ಮಾಕ್ ಲಾಜಿಕ್ ಇರುವುದರಿಂದ, ಕಾಂಪೊನೆಂಟ್ ಕೋಡ್ ಬದಲಾಗದೆ ಉಳಿಯುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳು ಯಾವುದೇ ಕಂಡೀಷನಲ್ ಲಾಜಿಕ್ ಸೇರಿಸದೆ ತಮ್ಮ ಸಾಮಾನ್ಯ ಡೇಟಾ-ಫೆಚಿಂಗ್ ಹುಕ್‌ಗಳನ್ನು—ಉದಾಹರಣೆಗೆ useQuery—ಬಳಸಬಹುದು.

Production bloat ಅನ್ನು ಹೇಗೆ ತಪ್ಪಿಸುವುದು

Vite ಬಳಸುವ Rollup (bundler) ಪ್ರೊಡಕ್ಷನ್ ಬಿಲ್ಡ್ ಮಾಡುವಾಗ ಮಾಕ್ ಕೋಡ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಲು ತಂಡವು ಮೂರು ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಅಳವಡಿಸಿದೆ:

  • ಪ್ರೊಡಕ್ಷನ್ ಬಿಲ್ಡ್‌ನಲ್ಲಿ import.meta.env.DEV ಎಂಬುದು false ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ tree-shaking ಸಮಯದಲ್ಲಿ ಇಡೀ interceptor module ಮಾಯವಾಗುತ್ತದೆ.
  • ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡುವಾಗ MODE variable ಅನ್ನು test ಅಲ್ಲದ ಬೇರೆ ಯಾವುದಾದರೂ ವಾರಿಯೇಶನ್ ಆಗಿ ಸೆಟ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಟೆಸ್ಟ್-ಮಾತ್ರದ ಕೋಡ್ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತದೆ.
  • ಒಂದು ಕಸ್ಟಮ್ ಫ್ಲಾಗ್, VITE_ENABLE_MSW, ಡಿಫಾಲ್ಟ್ ಆಗಿ false ಇರುತ್ತದೆ ಮತ್ತು ಮಾಕ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಇದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಆನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಈ ಮೂರೂ ಪರಿಸ್ಥಿತಿಗಳು false ಆಗಿದ್ದಾಗ, ಮಾಕ್ ರಿಜಿಸ್ಟ್ರಿ ಅಂತಿಮ ಬಂಡಲ್‌ನಲ್ಲಿ ಎಂದಿಗೂ ಸೇರುವುದಿಲ್ಲ.

Mock ಫೈಲ್‌ಗಳನ್ನು ಸಂಘಟಿಸುವುದು

ಈ ರೆಪೊ (repo) ಫೀಚರ್-ಕೇಂದ್ರಿತ ವಿನ್ಯಾಸವನ್ನು ಅನುಸರಿಸುತ್ತದೆ:

  • interfaces/ – Contract meeting ನಿಂದ ಸೃಷ್ಟಿಸಲಾದ TypeScript definitions ಅನ್ನು ಇದು ಹೊಂದಿರುತ್ತದೆ.
  • scenarios.ts – ಪ್ರತಿ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಯಶಸ್ವಿ ರೆಸ್ಪಾನ್ಸ್‌ಗಳು ಮತ್ತು ಎರರ್ ಕೇಸ್‌ಗಳ ನೈಜ ಉದಾಹರಣೆಗಳನ್ನು ಇದು ಒಳಗೊಂಡಿದೆ.
  • devHandlers.ts – ಇದು URL ಗಳನ್ನು ಸನ್ನಿವೇಶದ ಡೇಟಾಕ್ಕೆ (scenario data) ಮ್ಯಾಪ್ ಮಾಡುವ ಮತ್ತು Axios ಗೆ interceptor ಅನ್ನು ಜೋಡಿಸುವ ಕೇಂದ್ರ ರಿಜಿಸ್ಟ್ರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಒಂದು ಸಣ್ಣ scaffolding script ಈ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೃಷ್ಟಿಸಬಹುದು: ಇದಕ್ಕೆ ಒಂದು URL ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ interface ಅನ್ನು ನೀಡಿದರೆ, ಅದು stub ಫೈಲ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸಿ ಮಾಕ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತದೆ. ಈ script ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಪಥದ ಹೊರಗೆ ಇರುವುದರಿಂದ, ಇದು ಬಂಡಲ್ ಗಾತ್ರದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ತಂಡವು ಏನು ಸಾಧಿಸಿತು

  • ಕಾಂಪೊನೆಂಟ್‌ಗಳ ಒಳಗೆ ಯಾವುದೇ ಮಾಕ್‌ಗಳಿಲ್ಲ (Zero mocks inside components) – ಎಲ್ಲಾ ಫೇಕ್ ಡೇಟಾ ಒಂದು ಪ್ರತ್ಯೇಕ ಪದರದಲ್ಲಿ ಇರುತ್ತದೆ, ಇದರಿಂದ UI ಕೋಡ್ ಅಚ್ಚುಕಟ್ಟಾಗಿರುತ್ತದೆ.
  • End-to-end type safety – ಮಾಕ್ ಡೇಟಾ ನೈಜ ರೆಸ್ಪಾನ್ಸ್‌ಗಳಿಗೆ ಬಳಸುವ ಅದೇ TypeScript interfaces ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ mismatch ಗಳನ್ನು compile time ನಲ್ಲಿಯೇ ಪತ್ತೆಹಚ್ಚಬಹುದು.
  • No production weight – Tree-shaking ಇಂಟರ್‌ಸೆಪ್ಟರ್ ಮತ್ತು ಮಾಕ್ ಡೇಟಾವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದರಿಂದ ಬಂಡಲ್ ಗಾತ್ರ ಬದಲಾಗುವುದಿಲ್ಲ.
  • Dev ಮತ್ತು test ಗಾಗಿ ಹಂಚಿಕೆಯ ಸನ್ನಿವೇಶಗಳು (Shared scenarios) – ಒಂದೇ ಮಾಕ್ ವ್ಯಾಖ್ಯಾನಗಳು (definitions) ಲೋಕಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಮತ್ತು ಆಟೋಮೇಟೆಡ್ ಟೆಸ್ಟ್‌ಗಳೆರಡನ್ನೂ ನಡೆಸುತ್ತವೆ, ಇದರಿಂದ ಪುನರಾವರ್ತನೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.

ವಹಿ-ವಹಿ (trade-offs) ಮತ್ತು ಮಿತಿಗಳು

ಈ ವಿಧಾನವು ನೈಜ ಬ್ಯಾಕ್‌ಎಂಡ್‌ಗೆ ಪರ್ಯಾಯವಲ್ಲ. ಮಾಕ್ contract ನೈಜ API ಯಿಂದ ಭಿನ್ನವಾಗಿದ್ದರೆ, ಡೆವಲಪರ್‌ಗಳು ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಫ್ಲಾಗ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರವಷ್ಟೇ ಆ ವ್ಯತ್ಯಾಸವನ್ನು ತಿಳಿಯುತ್ತಾರೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

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

ಸಾರಾಂಶ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಮಾಕ್ ಲಾಜಿಕ್ ಅನ್ನು type-safe ಮತ್ತು environment-gated ಪದರಕ್ಕೆ ವರ್ಗಾಯಿಸುವುದರಿಂದ ಫ್ರಂಟ್‌ಎಂಡ್ ತಂಡಗಳು ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿಡಲು, type-safe ಆಗಿರಲು ಮತ್ತು ಯಾವುದೇ ಅಡಗಿರುವ ಮಾಕ್ ಪೇಲೋಡ್‌ಗಳಿಲ್ಲದೆ ಪ್ರೊಡಕ್ಷನ್ ಬಿಲ್ಡ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಸುಗಮ ಡೆವಲಪ್‌ಮೆಂಟ್ ವರ್ಕ್‌ಫ್ಲೋ ಮತ್ತು ಅಚ್ಚುಕಟ್ಟಾದ ಕೋಡ್ ಬೇಸ್‌ಗಾಗಿ ಹಂಚಿಕೆಯ contract ಅನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿದೆ.