Neon Functions आता अमर्याद कालावधीचे स्ट्रीमिंग कनेक्शन्स (unlimited-duration streaming connections) सपोर्ट करते, ज्यामुळे AI एजंट्स बहुतेक सर्व्हरलेस वर्कलोड्सना बंद करणाऱ्या टाइमआउट मर्यादांमध्ये न अडकता सेकंद, मिनिटे किंवा त्यापेक्षा जास्त काळ लाईव्ह चॅनेल उघडे ठेवू शकतात. चॅट-स्टाईल असिस्टंट्स किंवा टूल्स वापरणारे बॉट्स तयार करणाऱ्यांसाठी हा बदल महत्त्वाचा आहे, कारण तुटलेली स्ट्रीम संभाषण थांबवते आणि वापरकर्त्याचा अनुभव खराब करते.

सर्व्हरलेस आणि AI एजंट्स यांच्यात विसंगती का होती

बहुतेक सर्व्हरलेस प्लॅटफॉर्म्स जलद, 'फायर-अँड-फॉरगेट' (fire-and-forget) कामांसाठी बनवलेले असतात. संसाधने (resources) अंदाजित ठेवण्यासाठी ते एक्झिक्यूशनवर कडक मर्यादा घालतात—अनेकदा फ्री टियर्सवर १० सेकंद आणि पेड प्लॅन्सवर ६० सेकंद. मात्र, एक AI एजंट विचार करण्यासाठी, बाह्य टूल्स वापरण्यासाठी आणि टोकन्स जनरेट होताना ते पाठवण्यासाठी वेळ घेतो. ही "विचार करण्याची" (thinking) प्रक्रिया अनेकदा दहा सेकंदांच्या पुढे जाते आणि मॉडेल आउटपुट देत असेपर्यंत टोकन स्ट्रीम सुरू राहू शकते. जेव्हा प्लॅटफॉर्मचा टाइमर संपतो, तेव्हा तो कनेक्शन बंद करतो आणि क्लायंटला तुटलेली स्ट्रीम दिसते.

Neon चे उत्तर: डिफॉल्टनुसार दीर्घकाळ चालणारे स्ट्रीमिंग

Neon Functions ही परिस्थिती पूर्णपणे बदलून टाकते. कोणतीही विशेष कॉन्फिगरेशन न करता, WebSockets किंवा Server-Sent Events (SSE) द्वारे डेटा देण्यासाठी फंक्शन कॉल अनिश्चित काळासाठी उघडा राहू शकतो. प्लॅटफॉर्म दीर्घकालीन स्ट्रीमला एक सामान्य विनंती (request) मानतो, त्यामुळे डेव्हलपर्स स्ट्रीम जनरेट करण्याचे लॉजिक लिहितात आणि बाकीचे काम Neon कडे सोपवतात.

एका अलीकडील चाचणीमध्ये, दोन एंडपॉइंट्सनी हे वर्तन प्रदर्शित केले:

  • Heartbeat endpoint – फंक्शनने ९० सेकंदात दर सेकंदाला एकदा "tick" प्रसारित केले. सामान्य सर्व्हरलेस टियर्सनी १० किंवा ६० सेकंदांनंतर विनंती थांबवली असती; Neon ने फंक्शन स्वतःहून पूर्ण होईपर्यंत कनेक्शन जिवंत ठेवले.
  • Token-relay endpoint – फंक्शनने प्रत्येक टोकन तयार होताच AI मॉडेलकडून क्लायंटला टोकन्स स्ट्रीम केले. वापरकर्त्यांना संपूर्ण मजकूर येण्याची वाट पाहण्याऐवजी उत्तर शब्दशः येताना दिसले.

दोन्ही उदाहरणांसाठी क्लायंटकडून केवळ एकच विनंती आवश्यक होती; यासाठी कोणत्याही पोलिंग (polling) किंवा कीप-अलाईव (keep-alive) युक्त्यांची गरज नव्हती.

कोणाला फायदा होईल आणि कोणी सावध राहावे

संवादात्मक असिस्टंट्स (conversational assistants), टूल्स वापरणारे एजंट्स किंवा टप्प्याटप्प्याने निकाल देण्याची गरज असलेल्या कोणत्याही सेवा तयार करणाऱ्या टीम्सना याचा त्वरित फायदा होतो: टाइमआउटची समस्या संपते. याचा परिणाम म्हणजे सोपे कोड, कमी लॅटन्सी (latency) आणि अधिक सुलभ वापरकर्ता अनुभव.

काही महत्त्वाचे मुद्दे (trade-offs) लक्षात घेणे आवश्यक आहे:

  • Request-only model – Neon Functions अशा स्ट्रीम्स हाताळते ज्या सक्रिय विनंतीशी (active request) जोडलेल्या असतात. ज्या बॅकग्राउंड जॉब्सना विनंतीपेक्षा जास्त काळ टिकून राहणे आवश्यक आहे, त्यांना अजूनही Inngest किंवा तत्सम वर्कफ्लो इंजिनसारख्या स्वतंत्र शेड्युलरची गरज आहे.
  • Cold starts – निष्क्रिय असलेल्या फंक्शन्सचा स्केल शून्य (scale to zero) होऊ शकतो, त्यामुळे पुढच्या विनंतीला 'कोल्ड-स्टार्ट' विलंब होऊ शकतो. एक सक्रिय स्ट्रीम स्केलिंग खाली करण्यास प्रतिबंध करते, परंतु निष्क्रियतेनंतरच्या पहिल्या विनंतीला तरी स्टार्ट-अप खर्च सोसावा लागतो.

पुढे काय पाहावे

थोडक्यात सांगायचे तर: Neon Functions ने ती टाइमआउटची मर्यादा काढून टाकली आहे ज्याने AI डेव्हलपर्सना दीर्घकाळ पर्यायी मार्ग (workarounds) शोधण्यास भाग पाडले होते. एजंटला विचार करण्यासाठी आणि बोलण्यासाठी जितका वेळ हवा आहे तितका वेळ विनंती उघडी ठेवू दिल्याने, Neon स्ट्रीमिंग AI एजंट्स तैनात करणे इतर कोणत्याही सर्व्हरलेस फंक्शनइतकेच सोपे बनवते.