ಒಬ್ಬ ಡೆವಲಪರ್ ಒಂದು ಇಂಟರ್ನಲ್ ಟೂಲ್‌ನಲ್ಲಿ REST API ಬದಲಿಗೆ tRPC ಅನ್ನು ಬಳಸಲು ಎರಡು ವಾರಗಳನ್ನು ಕಳೆದರು.

ಈ ಬದಲಾವಣೆ ಏಕೆ ಮುಖ್ಯವಾಗಿತ್ತು

ಹಳೆಯ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ನಾವು DTO, ಒಂದು ವ್ಯಾಲಿಡೇಟರ್ ಮತ್ತು ಫ್ರಂಟ್‌ಎಂಡ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ TypeScript ಟೈಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗಿತ್ತು. ಬ್ಯಾಕೆಂಡ್ ಫೀಲ್ಡ್ ಅನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿದಾಗ, API ಇನ್ನೂ 200 ರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತಿತ್ತು, UI ರেন্ডರ್ ಆಗುತ್ತಲೇ ಇರುತ್ತಿತ್ತು ಮತ್ತು ಬಗ್ ಕೇವಲ "undefined" ಮೌಲ್ಯಗಳಾಗಿ ಮಾತ್ರ ಕಾಣಿಸುತ್ತಿತ್ತು. ತಂಡದ ಯಾರೂ ಗಮನಿಸುವ ಮೊದಲೇ ಗ್ರಾಹಕರು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು. REST ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳು ಸಮಸ್ಯೆಯನ್ನು ಮರೆಮಾಚಿದ್ದವು ಮತ್ತು ಹೆಚ್ಚುವರಿ ಫೈಲ್‌ಗಳು ಯಾವುದೇ ಪ್ರಯೋಜನ ನೀಡದ ನಿರ್ವಹಣಾ ಹೊರೆಯನ್ನು ಹೆಚ್ಚಿಸಿದ್ದವು.

REST ಸೆಟಪ್ ಹೇಗಿತ್ತು

  • OpenAPI spec – ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ವಿವರಿಸುವ ಒಂದು ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್ ಆಗಿತ್ತು, ಆದರೆ ಇದು ಎಂದಿಗೂ 'source of truth' ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ.
  • Client SDK generation step – JavaScript wrappರ್ ಅನ್ನು ತಯಾರಿಸುವ ಒಂದು CI ಜಾಬ್.
  • Postman collection – ಯಾರೂ ಬಳಸದ ಒಂದು ಹಂಚಿಕೆಯ ಟೆಸ್ಟಿಂಗ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್.
  • Manual TypeScript interfaces – ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ ಆಗಿರಬೇಕಾದ ಕೈಬರಹದ (hand-written) ಟೈಪ್‌ಗಳು.

ಪ್ರತಿಯೊಂದು API ಬದಲಾವಣೆಯು ಕನಿಷ್ಠ ಮೂರು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು, ಜೊತೆಗೆ ವ್ಯಾಲಿಡೇಟರ್ ಮತ್ತು ಯಾವುದೇ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ fetch ಕಾಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಈ ಪ್ರಕ್ರಿಯೆಯು ತಪ್ಪುಗಳಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತಿತ್ತು ಮತ್ತು ನಿಧಾನವಾಗಿತ್ತು.

tRPC ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡಿತು

tRPC ಪ್ರತ್ಯೇಕ ಕಾಂಟ್ರಾಕ್ಟ್ ಫೈಲ್‌ನ ಅಗತ್ಯವನ್ನು ಇಲ್ಲಮಡುತ್ತದೆ. ಸರ್ವರ್ ಒಂದು router type ಅನ್ನು ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಮಾಡುತ್ತದೆ; ಕ್ಲೈಂಟ್ ಅದೇ type ಅನ್ನು ಇಂಪೋರ್ಟ್ ಮಾಡುತ್ತದೆ. ಬ್ಯಾಕೆಂಡ್ ಫೀಲ್ಡ್ ಅನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿದ ತಕ್ಷಣ, ಎಡಿಟರ್ ತಕ್ಷಣವೇ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ—ಇದಕ್ಕಾಗಿ ಕೋಡ್ ರನ್ ಮಾಡುವ ಅಥವಾ ಫೇಲ್ ಆದ ರಿಕ್ವೆಸ್ಟ್‌ನ ಅಗತ್ಯವಿಲ್ಲ. ಡೆವಲಪರ್ ಇವುಗಳನ್ನು ತೆಗೆದುಹಾಕಿದರು:

  • OpenAPI spec ಫೈಲ್.
  • Client SDK generation step.
  • ಬಳಕೆಯಿಲ್ಲದ Postman collection.
  • Manual TypeScript interfaces ಇರುವ ಫೋಲ್ಡರ್.

ರೆಪೊ (repo) ಹೆಚ್ಚು ಲೀನ್ (lean) ಆಯಿತು ಮತ್ತು ಫೀಡ್‌ಬ್ಯಾಕ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ನಂತರ ಬರುವ ಬದಲು ಡೆವಲಪ್‌ಮೆಂಟ್ ಸಮಯದಲ್ಲಿಯೇ ಲಭಿಸಿತು.

tRPC ನ ಮಿತಿಗಳು

ಎರಡೂ ಕಡೆಯವರು TypeScript ಬಳಸಿದಾಗ ಮಾತ್ರ tRPC ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಈ ಕೆಳಗಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಅಸಮರ್ಥವಾಗಬಹುದು:

  • ಮೊಬೈಲ್ ತಂಡವು Swift ಅಥವಾ Kotlin ಬಳಸುತ್ತಿದ್ದರೆ.
  • API ಅನ್ನು ಬಾಹ್ಯ ಪಾಲುದಾರರು ಬಳಸಬೇಕಿದ್ದರೆ.
  • ನಿಮಗೆ ಸಾರ್ವಜನಿಕವಾದ, ಭಾಷೆ-ತಟಸ್ಥ (language-agnostic) ಇಂಟರ್ಫೇಸ್ ಬೇಕಿದ್ದರೆ.

ಮೈಗ್ರೇಷನ್‌ಗೆ ವಾಸ್ತವವಾಗಿ ಏನು ಬೇಕಾಯಿತು

ಆ ಎರಡು ವಾರಗಳ ಪ್ರಯತ್ನವು ಕೇವಲ ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿತ್ತು. ಡೆವಲಪರ್ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಬೇಕಾಯಿತು:

  • tRPC ನ ಕ್ಲೈಂಟ್ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಬಳಸಲು ಪ್ರತಿಯೊಂದು fetch ಕಾಲ್ ಅನ್ನು ಮರುಬರೆಯುವುದು.
  • Error-handling ಲಾಜಿಕ್ ಅನ್ನು ಸರಿಹೊಂದಿಸುವುದು.
  • ರೊ (raw) HTTP ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಲೋಡಿಂಗ್ ಮತ್ತು ರಿಟ್ರೈ ಸ್ಟೇಟ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ UI ಘಟಕಗಳನ್ನು (components) ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು.

ನೀವು ಬದಲಾಯಿಸುವ ಮೊದಲು ಕೇಳಬೇಕಾದ ಪ್ರಶ್ನೆಗಳು

  • ಫ್ರಂಟ್‌ಎಂಡ್ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಎರಡೂ TypeScript ಬಳಸುತ್ತವೆಯೇ? ಹಂಚಿಕೆಯ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಇಲ್ಲದಿದ್ದರೆ, tRPC ತನ್ನ ಮುಖ್ಯ ಪ್ರಯೋಜನವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
  • ಎರಡೂ ಕಡೆಗಳಿಗಾಗಿ ಒಂದೇ ತಂಡ ಜವಾಬ್ದಾರಿಯಾಗಿದೆಯೇ? ಮಾಲೀಕತ್ವದ ಅಂತರವು (Ownership gaps) ಮತ್ತೆ ಕಾಂಟ್ರಾಕ್ಟ್ ವ್ಯತ್ಯಾಸಗಳಿಗೆ (contract drift) ಕಾರಣವಾಗಬಹುದು.
  • ನೀವು ಯಾವುದಾದರೂ ನಿರ್ದಿಷ್ಟ ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಕೇವಲ ಟ್ರೆಂಡ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತಿದ್ದೀರಾ? ಉತ್ಪಾದಕತೆಯ ಹೆಚ್ಚಳವು ನಿಜವಾಗಿಯೂ ಇರುತ್ತದೆ, ಆದರೆ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಂತಿರಬೇಕು.

2025 ರಿಗಾಗಿ ಒಂದು ಹೈಬ್ರಿಡ್ ವಿಧಾನ

ಅನೇಕ ತಂಡಗಳು ಎರಡೂ ಸ್ಟ್ಯಾಕ್‌ಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ ಉತ್ತಮ ಸಮತೋಲನವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತವೆ:

  • ಇಂಟರ್ನಲ್ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್‌ಗಳಿಗಾಗಿ tRPC – ಇಲ್ಲಿ ಕೋಡ್‌ಬೇಸ್ ಸಂಪೂರ್ಣವಾಗಿ TypeScript ಆಗಿರುತ್ತದೆ ಮತ್ತು ಒಂದೇ ತಂಡವು ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
  • Webhooks, ಪಬ್ಲಿಕ್ APIಗಳು ಮತ್ತು ಪಾಲುದಾರರ ಇಂಟಿಗ್ರೇಷನ್‌ಗಳಿಗಾಗಿ REST – ಇಲ್ಲಿ ಭಾಷೆ-ತಟಸ್ಥ (language-agnostic) ಪ್ರವೇಶದ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು ಉದ್ದೇಶಕ್ಕೂ ಸರಿಯಾದ ಸಾಧನವನ್ನು ಬಳಸುವುದರಿಂದ, ಬಾಹ್ಯ ಬಳಕೆದಾರರಿಗೆ ಅಗತ್ಯವಿರುವ ಮುಕ್ತತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತಲೇ ಇಂಟರ್ನಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಅನ್ನು ವೇಗವಾಗಿರಿಸಬಹುದು.

ಸಾರಾಂಶ: REST ಬದಲಿಗೆ tRPC ಅನ್ನು ಬಳಸುವುದರಿಂದ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಕಾಂಟ್ರಾಕ್ಟ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಬಹುದು ಮತ್ತು ಎಡಿಟ್ ಮಾಡುವ ಸಮಯದಲ್ಲೇ ಬಗ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು, ಆದರೆ ಇಡೀ ಸ್ಟ್ಯಾಕ್ TypeScript ಅನ್ನು ಹಂಚಿಕೊಂಡಾಗ ಮತ್ತು ತಂಡವು ಮೈಗ್ರೇಷನ್ ವೆಚ್ಚವನ್ನು ಭರಿಸಲು ಸಾಧ್ಯವಾದಾಗ ಮಾತ್ರ ಇದರ ಪ್ರಯೋಜನಗಳು ಸಿಗುತ್ತವೆ. ಮಿಶ್ರ ತಂತ್ರವು (mixed strategy) non-TypeScript ಬಳಕೆದಾರರನ್ನು ಹೊರಗಿಡದೆಯೇ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.