> ## Content Index > Fetch the complete content index at: https://www.karls.io/llms.txt > Use this file to discover other available public pages before exploring further. # AI Agent Chat: Choosing Between WebSockets and Server-Sent Events - URL: https://www.karls.io/ai-agent-progress-chat-websocket-server-sent-events/ - Published: 2025-02-17T13:47:31.000Z - Updated: 2025-11-23T16:15:57.000Z - Description: Discover how to power your AI agent chat by choosing the right real-time communication protocol. In this article, we dive into the pros and cons of WebSockets and Server-Sent Events - Author: Karl Scerbiakas - Tags: NestJS **TL;DR 🚀** - **AI Agent Progress** – Continuing with **LangChain (TypeScript) + NestJS** for automation. - **Streaming Challenge** – Needed a way to stream responses efficiently. - **WebSockets vs. SSE** – WebSockets are **low-latency but resource-intensive**; SSE is **simpler, scalable, and secure**. - **Chose SSE** – Works well with NestJS and natively supported, easier to implement, auto-reconnects, and scales with HTTP. - **Limitations?** – SSE is **one-way only** (server → client) but not a problem for this use case. - **What’s next?** – Retrieval-Augmented Generation (RAG), Observability & Further AI-driven automation for Marketing. 🚀 ## **Introduction** As firstly I mentioned my one of previous articles I mentioned that I started working on an AI Agent. [How AI is Transforming SEO and Content MarketingAI is reshaping digital marketing by automating content creation, optimizing keywords, and improving search rankings. This article explores how businesses—especially smaller ones—leverage AI to compete more effectively, streamline SEO, and enhance marketing ROI.![](https://storage.ghost.io/c/dd/39/dd396245-c33e-4f42-bdff-f3441f887f6d/content/images/icon/favicon-1.ico)Karolis ScerbiakasKarolis Ščerbiakas![](https://storage.ghost.io/c/dd/39/dd396245-c33e-4f42-bdff-f3441f887f6d/content/images/thumbnail/photo-1674027444485-cec3da58eef4)](https://www.karls.io/ai-marketing/) In this article I want to follow up on progress. Expand on that tech stack has been chosen. ## Tech Stack I've decided to build the agent's intelligence on **LangChain** and with **NestJS** ![gray TV remote](https://images.unsplash.com/photo-1517669137467-b2c221703e93?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDJ8fGxhbmd8ZW58MHx8fHwxNzM5Nzg1MTk1fDA&ixlib=rb-4.0.3&q=80&w=2000) Photo by [Immo Wegmann](https://unsplash.com/@tinkerman?ref=karls.io) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) ### What is LangChain? - **LangChain** is a framework for building applications powered by large language models (LLMs). - It simplifies tasks like **prompt chaining, memory management, data integration, and workflow orchestration**. - Ideal for building **AI agents, chatbots, and retrieval-augmented generation (RAG) applications**. - Has a **TypeScript implementation**. Which I am big fan of. - Also it makes easy to integrate with **NestJS** and leverage its **DI** container to inject services, instead of leveraging micro services. If you'd like to learn more about when to or not to use it you can read more: [The Real Benefits of Micro Services in NestJS (And When They Aren't Worth It)](https://www.karls.io/the-real-benefits-of-micro-services-in-nestjs-and-when-they-arent-worth-it/) By leveraging **LangChain** on Typescript I've implemented the ai agent chat functionality. One of the main challenges and considerations was Chat UX. **ChatGPT** has already set a bar high with chat experience, but leveraging streaming. One might assume that streaming is achieved through WebSockets. WebSockets has many benefits and quite a few drawbacks. ![programming language illustration](https://images.unsplash.com/photo-1527427337751-fdca2f128ce5?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDF8fHdlYnNvY2tldHN8ZW58MHx8fHwxNzM5Nzg3MDg4fDA&ixlib=rb-4.0.3&q=80&w=2000) Photo by [Christopher Robin Ebbinghaus](https://unsplash.com/@cebbinghaus?ref=karls.io) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) ### ✅ WebSockets: Pros - Low latency. This makes them ideal for quick back and forth message sending. - Supports **simultaneous sending and receiving**, unlike traditional HTTP requests. - **Persistent Connection** – Reduces overhead by maintaining a single connection instead of opening new ones for each message. However, ### ❌ WebSockets: Cons - **High Resource Consumption** – Maintaining persistent connections **increases memory and CPU usage**. Unlike stateless HTTP requests, WebSockets require **dedicated server resources** for each connection, making large-scale deployments more challenging. (Ensuring there will be enough servers to handle connections and managing budget). - **Security Considerations** – WebSockets **do not include built-in authentication** or authorization mechanisms. Common approaches, like sending **JWT tokens with each message**, require additional validation logic, and none are as straightforward as traditional API authentication. 👉 **Key Takeaway:** While WebSockets offer low-latency, full-duplex communication, their resource demands and security concerns **make them less suited for real-time applications**. ### **🧐** What are the options ? - **Server-Sent Events (SSE)** – Simpler than WebSockets, ideal for **one-way streaming**. - **Polling/Long Polling** – Works with older architectures but **adds latency** and wastes resources. I went with **Server-Sent Events (SSE).** NestJs already supports it out of the [box](https://docs.nestjs.com/techniques/server-sent-events?ref=karls.io). One thing is to make sure to return the RxJS observable from the controller method and decorate method with `@Sse` decorator. Let's go quickly over SSE Pros & Cons. ## Join Devs Who Are Building Better Backend Systems Get production-tested NestJS patterns, microservices insights, and GCP Cost hacks. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### ✅ Server-Sent Event: Pros - **Simplicity** – Uses standard HTTP connections, making it **easier to implement** compared to WebSockets. Especially with NestJS. - **Lightweight & Efficient** – SSE operates over a single HTTP connection. - **Automatic Reconnection** – Built-in support for **auto-reconnect**, meaning clients can automatically re-establish the connection if interrupted. Handled by the browser. - **Secure by Default** – SSE leverages existing HTTP/HTTPS security mechanisms. No need for extra implementation for authentication and authorization. - **Scalability-Friendly** – Easier to scale with HTTP load balancers, since it uses **standard HTTP connections** rather than a stateful protocol like WebSockets. Before I close off I would like to mention that there are some cons to the Server-Sent events, though in my use case they are irrelevant. ### ❌ Server-Sent Event: Cons - **One-Way Streaming** – Ideal for applications that require server-to-client updates. To update backend you must to send another **POST/PUT** request to backend to make an update to your state to alter SSE and if required trigger reconnection. - While SSE scales better than WebSockets in some contexts, it still faces **limitations with very high-frequency updates** or large numbers of clients, particularly in cloud environments where maintaining long-lived HTTP connections can be costly and hit limits, but generally this is a good problem to have. It means that your project amounted to something 🤭 So to conclude, when it came to **streaming responses**, I initially evaluated WebSockets but ultimately opted for **Server-Sent Events (SSE)** due to its **simplicity, built-in security, and scalability**. While SSE has some **limitations, such as one-way streaming**, these were not critical for my use case.