நிதானத்தை இழக்காமல் ஒரு ஸ்ட்ரீமிங் AI சாட் கிளையண்ட்டை உருவாக்கினேன்
AI நிகழ்நேரத்தில் (real-time) பதிலளிக்கும் ஒரு சாட் இடைமுகத்தை (chat interface) உருவாக்க விரும்பினேன். அந்த மென்மையான டைப்ரைட்டர் விளைவை (typewriter effect) நான் எதிர்பார்த்தேன்.
நான் நினைத்ததை விட இது கடினமாக இருந்தது. பிரச்சனை AI-இல் இல்லை. பிரச்சனை API மற்றும் பிரவுசருக்கு இடையிலான பைப்லைனில் (pipeline) இருந்தது.
இதைத் தீர்க்க நான் மூன்று வெவ்வேறு வழிகளை முயற்சி செய்தேன்.
காத்திருப்பு முறை (The Wait Method) நான் API-ஐ அழைத்து, முழுப் பதிலையும் காட்டும் முன் காத்திருந்தேன். இது வேலை செய்தது, ஆனால் UI பல வினாடிகள் அப்படியே உறைந்து போனது (froze). ஆப் பழுதாகிவிட்டது என்று பயனர்கள் நினைத்தனர். அவர்கள் மீண்டும் மீண்டும் "Send" பொத்தானை அழுத்தினார்கள். இது ஒரு மோசமான பயனர் அனுபவம் (user experience).
போலிங் முறை (The Polling Method) சர்வர் ஒரு job ID-ஐ அனுப்ப வேண்டும் என்று நினைத்தேன். அதன் பிறகு கிளையண்ட் ஒவ்வொரு வினாடியும் அப்டேட்களைக் கேட்கும். இதற்கு அதிகப்படியான சர்வர் மேலாண்மை தேவைப்பட்டது. அப்டேட்கள் சீரற்ற துண்டுகளாக (random chunks) வந்தன. அது சீராக இல்லை.
WebSocket முறை (The WebSocket Method) நான் Socket.IO-வை முயற்சி செய்தேன். இது மிகப்பெரிய சிக்கலைச் சேர்த்தது. ரீகனெக்ஷன்கள் (reconnections), ஹார்ட் பீட்ஸ் (heartbeats) மற்றும் ஸ்டேட் சிங்க்ரோனைசேஷன் (state synchronization) ஆகியவற்றை நான் நிர்வகிக்க வேண்டியிருந்தது. ஒரு சாதாரண சாட் ஆப்பிற்கு, WebSockets என்பது தேவையற்ற சிக்கல் (overkill).
தீர்வு மிகவும் எளிமையானது: Server-Sent Events (SSE).
பெரும்பாலான AI API-கள் ஏற்கனவே HTTP வழியாக SSE மூலம் பதில்களை அனுப்புகின்றன. நான் சிக்கலான கருவிகளைத் தேடுவதை நிறுத்திவிட்டு, நேட்டிவ் fetch API-யைப் பயன்படுத்தினேன்.
response.body.getReader()-ஐப் பயன்படுத்துவதன் மூலம், நான் பைட்டுகளின் ஸ்ட்ரீமை (stream of bytes) நேரடியாகப் படித்தேன். நான் SSE புரோட்டோகாலை (protocol) நானே பகுப்பாய்வு செய்தேன். இந்த அணுகுமுறை UI-ஐ சுறுசுறுப்பாக (responsive) வைத்திருக்கும் மற்றும் நிலையான HTTP-யைப் பயன்படுத்துகிறது.
ஏன் இது வேலை செய்கிறது:
- WebSocket சர்வர் தேவையில்லை.
- சிக்கலான ரீகனெக்ஷன் லாஜிக் தேவையில்லை.
- SSE-ஐ ஆதரிக்கும் எந்த API-யுடனும் இது வேலை செய்யும்.
AbortController-ஐப் பயன்படுத்தி நீங்கள் ஸ்ட்ரீமை எளிதாக நிறுத்தலாம்.
இதில் சில சாதக பாதகங்கள் உள்ளன:
- ஒரு கோரிக்கை (request) இல்லாமல் கிளையண்டிற்கு அப்டேட்களை அனுப்ப முடியாது.
- இணைப்பு துண்டிக்கப்பட்டால், பாதியிலேயே இருக்கும் பதிலைத் தவறவிட்டுவிடுவீர்கள்.
நீங்கள் ஒரு சாட் ஆப் உருவாக்குகிறீர்கள் என்றால், இருவழித் தொடர்பு (bidirectional communication) தேவைப்படும் வரை WebSockets-ஐத் தவிர்க்கவும். HTTP ஸ்ட்ரீமிங்கையே பின்பற்றுங்கள். அது எளிமையானது மற்றும் நம்பகமானது.
உங்கள் ஸ்ட்ரீமிங் உத்தி (streaming strategy) என்ன? நீங்கள் WebSockets அல்லது SSE பயன்படுத்துகிறீர்களா? கமெண்ட்களில் என்னிடம் சொல்லுங்கள்.
ஆதாரம்: https://dev.to/__c1b9e06dc90a7e0a676b/i-built-a-streaming-ai-chat-client-without-losing-my-mind-3gi0