𝗜 𝗕𝘂𝗶𝗹𝘁 𝗮 𝗦𝘁𝗿𝗲𝗮𝗺𝗶𝗻𝗴 𝗔𝗜 𝗖𝗵𝗮𝘁 𝗖𝗹𝗶𝗲𝗻𝘁 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗟𝗼𝘀𝗶𝗻𝗴 𝗠𝘆 𝗠𝗶𝗻𝗱 ബുദ്ധിഭ്രമം സംഭവിക്കാതെ ഞാൻ ഒരു സ്ട്രീമിംഗ് AI ചാറ്റ് ക്ലയന്റ് നിർമ്മിച്ചു
AI തത്സമയം (real-time) പ്രതികരിക്കുന്ന ഒരു ചാറ്റ് ഇന്റർഫേസ് നിർമ്മിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. ആ സുഗമമായ ടൈപ്പ്റൈറ്റർ ഇഫക്റ്റ് (typewriter effect) എനിക്ക് വേണമായിരുന്നു.
ഞാൻ കരുതിയതിനേക്കാൾ പ്രയാസകരമായിരുന്നു അത്. പ്രശ്നം AI ആയിരുന്നില്ല. API-യും ബ്രൗസറും തമ്മിലുള്ള പൈപ്പ്ലൈൻ (pipeline) ആയിരുന്നു പ്രശ്നം.
ഇത് പരിഹരിക്കാൻ ഞാൻ മൂന്ന് വ്യത്യസ്ത വഴികൾ പരീക്ഷിച്ചു.
വെയിറ്റ് മെത്തേഡ് (The Wait Method) ഞാൻ API വിളിക്കുകയും പൂർണ്ണമായ മറുപടി ലഭിക്കുന്നത് വരെ കാത്തിരിക്കുകയും ചെയ്തു. ഇത് പ്രവർത്തിച്ചു, പക്ഷേ UI കുറച്ച് സെക്കൻഡുകൾ തണുത്തുറഞ്ഞു (froze) പോയി. ആപ്പ് തകരാറിലായെന്ന് ഉപയോക്താക്കൾ കരുതി. അവർ വീണ്ടും വീണ്ടും "Send" ബട്ടൺ അമർത്തിക്കൊണ്ടിരുന്നു. ഇതൊരു മോശം യൂസർ എക്സ്പീരിയൻസ് (user experience) ആയിരുന്നു.
പോളിംഗ് മെത്തേഡ് (The Polling Method) സെർവർ ഒരു ജോബ് ഐഡി (job ID) അയക്കുന്നുണ്ടോ എന്ന് നോക്കാം എന്ന് ഞാൻ കരുതി. തുടർന്ന് ക്ലയന്റ് ഓരോ സെക്കൻഡിലും അപ്ഡേറ്റുകൾക്കായി ചോദിക്കും. ഇതിന് കഠിനമായ സെർവർ മാനേജ്മെന്റ് ആവശ്യമായിരുന്നു. അപ്ഡേറ്റുകൾ ക്രമരഹിതമായ കഷണങ്ങളായിട്ടാണ് (chunks) വന്നത്. അത് സുഗമമായിരുന്നില്ല.
വെബ്സോക്കറ്റ് മെത്തേഡ് (The WebSocket Method) ഞാൻ Socket.IO പരീക്ഷിച്ചു. ഇത് വലിയ സങ്കീർണ്ണതകൾ ഉണ്ടാക്കി. റീകണക്ഷനുകൾ (reconnections), ഹാർട്ട്ബീറ്റുകൾ (heartbeats), സ്റ്റേറ്റ് സിൻക്രണൈസേഷൻ (state synchronization) എന്നിവ എനിക്ക് മാനേജ് ചെയ്യേണ്ടി വന്നു. ഒരു ലളിതമായ ചാറ്റ് ആപ്പിന് വെബ്സോക്കറ്റുകൾ (WebSockets) അമിതമായിരുന്നു.
പരിഹാരം ലളിതമായിരുന്നു: Server-Sent Events (SSE).
മിക്ക AI API-കളും ഇതിനകം തന്നെ HTTP വഴി SSE ഉപയോഗിച്ച് മറുപടികൾ അയക്കുന്നുണ്ട്. ഞാൻ സങ്കീർണ്ണമായ ടൂളുകൾ തിരയുന്നത് നിർത്തി, പകരം നേറ്റീവ് fetch API ഉപയോഗിച്ചു.
response.body.getReader() ഉപയോഗിച്ചുകൊണ്ട്, ഞാൻ ബൈറ്റുകളുടെ സ്ട്രീം (stream of bytes) നേരിട്ട് വായിച്ചു. ഞാൻ തന്നെ SSE പ്രോട്ടോക്കോൾ പാഴ്സ് (parse) ചെയ്തു. ഈ രീതി UI റെസ്പോൺസീവ് ആയി നിലനിർത്തുകയും സ്റ്റാൻഡേർഡ് HTTP ഉപയോഗിക്കുകയും ചെയ്യുന്നു.
എന്തുകൊണ്ടാണ് ഇത് പ്രവർത്തിക്കുന്നത്:
- വെബ്സോക്കറ്റ് സെർവർ ആവശ്യമില്ല.
- സങ്കീർണ്ണമായ റീകണക്ഷൻ ലോജിക് ആവശ്യമില്ല.
- SSE സപ്പോർട്ട് ചെയ്യുന്ന ഏത് API-യുമായും ഇത് പ്രവർത്തിക്കും.
- AbortController ഉപയോഗിച്ച് നിങ്ങൾക്ക് സ്ട്രീം എളുപ്പത്തിൽ നിർത്താം.
ഇതിന് ചില പരിമിതികളുണ്ട് (trade-offs).
- ഒരു റിക്വസ്റ്റ് ഇല്ലാതെ നിങ്ങൾക്ക് ക്ലയന്റിലേക്ക് അപ്ഡേറ്റുകൾ എത്തിക്കാൻ കഴിയില്ല.
- കണക്ഷൻ നഷ്ടപ്പെട്ടാൽ, ഭാഗികമായ മറുപടി (partial response) നിങ്ങൾക്ക് നഷ്ടപ്പെടും.
നിങ്ങൾ ഒരു ചാറ്റ് ആപ്പ് നിർമ്മിക്കുകയാണെങ്കിൽ, ബൈഡയറക്ഷണൽ കമ്മ്യൂണിക്കേഷൻ (bidirectional communication) ആവശ്യമുണ്ടെങ്കിൽ മാത്രം വെബ്സോക്കറ്റുകൾ ഉപയോഗിക്കുക. HTTP സ്ട്രീമിംഗിൽ തന്നെ തുടരുക. അത് ലളിതവും കൂടുതൽ വിശ്വസനീയവുമാണ്.
നിങ്ങളുടെ സ്ട്രീമിംഗ് സ്ട്രാറ്റജി എന്താണ്? നിങ്ങൾ വെബ്സോക്കറ്റുകളാണോ അതോ SSE ആണോ ഉപയോഗിക്കുന്നത്? കമന്റുകളിൽ എന്നോട് പറയൂ.
സ്രോതസ്സ്: https://dev.to/__c1b9e06dc90a7e0a676b/i-built-a-streaming-ai-chat-client-without-losing-my-mind-3gi0