ನಾನು ನನ್ನ ತಲೆ ಕೆಡಿಸಿಕೊಳ್ಳದೆ ಒಂದು ಸ್ಟ್ರೀಮಿಂಗ್ AI ಚಾಟ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ

AI ನಷ್ಟು ನೈಜ ಸಮಯದಲ್ಲಿ (real-time) ಪ್ರತಿಕ್ರಿಯಿಸುವ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಾನು ನಿರ್ಮಿಸಲು ಬಯಸಿದ್ದೆ. ನನಗೆ ಆ ಸುಗಮ ಟೈಪ್‌ರೈಟರ್ ಎಫೆಕ್ಟ್ (typewriter effect) ಬೇಕಿತ್ತು.

ಇದು ನಾನು ಅಂದುಕೊಂಡಿದ್ದಕ್ಕಿಂತ ಕಷ್ಟವಾಗಿತ್ತು. ಸಮಸ್ಯೆ AI ನಲ್ಲಿರಲಿಲ್ಲ. ಸಮಸ್ಯೆ ಎಂದರೆ API ಮತ್ತು ಬ್ರೌಸರ್ ನಡುವಿನ ಪೈಪ್‌ಲೈನ್ (pipeline) ಆಗಿತ್ತು.

ಇದನ್ನು ಪರಿಹರಿಸಲು ನಾನು ಮೂರು ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ.

  1. ವೇಟ್ ವಿಧಾನ (The Wait Method) ನಾನು API ಅನ್ನು ಕರೆ ಮಾಡಿ, ಪೂರ್ಣ ಪ್ರತಿಕ್ರಿಯೆ ಬರುವವರೆಗೆ ಕಾಯುತ್ತಿದ್ದೆ. ಇದು ಕೆಲಸ ಮಾಡಿತು, ಆದರೆ UI ಹಲವಾರು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಸ್ಥಗಿತಗೊಂಡಿತು (froze). ಅಪ್ಲಿಕೇಶನ್ ಕೆಟ್ಟುಹೋಗಿದೆ ಎಂದು ಬಳಕೆದಾರರು ಭಾವಿಸಿದರು. ಅವರು ಪದೇ ಪದೇ "Send" ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿದರು. ಇದು ಕೆಟ್ಟ ಬಳಕೆದಾರ ಅನುಭವವಾಗಿತ್ತು (bad user experience).

  2. ಪೋಲಿಂಗ್ ವಿಧಾನ (The Polling Method) ಸರ್ವರ್ ಒಂದು job ID ಅನ್ನು ಕಳುಹಿಸಲಿ ಎಂದು ನಾನು ಯೋಚಿಸಿದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ ಕೇಳುತ್ತಿತ್ತು. ಇದಕ್ಕೆ ಹೆಚ್ಚಿನ ಸರ್ವರ್ ನಿರ್ವಹಣೆಯ ಅಗತ್ಯವಿತ್ತು. ಅಪ್‌ಡೇಟ್‌ಗಳು ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಬಂದವು. ಅದು ಸುಗಮವಾಗಿರಲಿಲ್ಲ.

  3. WebSocket ವಿಧಾನ (The WebSocket Method) ನಾನು Socket.IO ಅನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ. ಇದು ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆಯನ್ನು ತಂದಿತು. ನಾನು reconnectionಗಳು, heartbeats ಮತ್ತು state synchronization ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಯಿತು. ಒಂದು ಸರಳ ಚಾಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ WebSockets ಅತಿಯಾಗಿತ್ತು (overkill).

ಪರಿಹಾರವು ಸರಳವಾಗಿತ್ತು: Server-Sent Events (SSE).

ಹೆಚ್ಚಿನ AI APIಗಳು ಈಗಾಗಲೇ HTTP ಮೂಲಕ SSE ಬಳಸಿ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ನಾನು ಸಂಕೀರ್ಣ ಪರಿಕರಗಳಿಗಾಗಿ ಹುಡುಕುವುದನ್ನು ನಿಲ್ಲಿಸಿ, native fetch API ಅನ್ನು ಬಳಸಿದೆ.

response.body.getReader() ಅನ್ನು ಬಳಸುವ ಮೂಲಕ, ನಾನು ಬೈಟ್‌ಗಳ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ನೇರವಾಗಿ ಓದಿದೆ. ನಾನು SSE ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಾನೇ ಪಾರ್ಸ್ (parse) ಮಾಡಿದೆ. ಈ ವಿಧಾನವು UI ಅನ್ನು ರೆಸ್ಪಾನ್ಸಿವ್ ಆಗಿರಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಟ್ಯಾಂಡರ್ಡ್ HTTP ಅನ್ನು ಬಳಸುತ್ತದೆ.

ಇದು ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

  • ಯಾವುದೇ WebSocket ಸರ್ವರ್ ಅಗತ್ಯವಿಲ್ಲ.
  • ಯಾವುದೇ ಸಂಕೀರ್ಣ reconnection ಲಾಜಿಕ್ ಇಲ್ಲ.
  • SSE ಅನ್ನು ಬೆಂಬಲಿಸುವ ಯಾವುದೇ API ಜೊತೆಗೆ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.
  • ನೀವು AbortController ಬಳಸಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸುಲಭವಾಗಿ ನಿಲ್ಲಿಸಬಹುದು.

ಇದರಲ್ಲಿ ಕೆಲವು ಮಿತಿಗಳಿವೆ (trade-offs).

  • ವಿನಂತಿಯಿಲ್ಲದೆ (without a request) ನೀವು ಕ್ಲೈಂಟ್‌ಗೆ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
  • ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡರೆ, ನೀವು ಭಾಗಶಃ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

ನೀವು ಚಾಟ್ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ದ್ವಿಮುಖ ಸಂವಹನ (bidirectional communication) ಅಗತ್ಯವಿಲ್ಲದ ಹೊರತು WebSockets ಅನ್ನು ತಪ್ಪಿಸಿ. HTTP ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಳಸಿ. ಇದು ಸರಳ ಮತ್ತು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ.

ನಿಮ್ಮ ಸ್ಟ್ರೀಮಿಂಗ್ ತಂತ್ರ (strategy) ಯಾವುದು? ನೀವು WebSockets ಅಥವಾ SSE ಬಳಸುತ್ತೀರಾ? ಕಾಮೆಂಟ್‌ನಲ್ಲಿ ತಿಳಿಸಿ.

ಮೂಲ (Source): https://dev.to/__c1b9e06dc90a7e0a676b/i-built-a-streaming-ai-chat-client-without-losing-my-mind-3gi0