Writing A Websocket Server In Javascript Deno

Introduction

Real-time communication has become essential for modern web applications, enabling features like live notifications, collaborative editing, instant messaging, and interactive dashboards. Deno, the modern JavaScript runtime developed by the creator of Node.js, offers built-in WebSocket support that simplifies building these real-time features. With its secure-by-default architecture, TypeScript support, and streamlined API, Deno provides an excellent foundation for WebSocket server development.

This guide walks you through creating a WebSocket server using Deno's native APIs, covering everything from basic setup to production-ready security implementations. Whether you're building a live chat application, real-time collaboration tool, or IoT dashboard, understanding WebSocket server development in Deno gives you the tools to create responsive, interactive experiences for your users. The skills you develop here transfer directly to our web development services, where we build custom real-time solutions for clients across industries.

What Makes Deno Ideal for WebSocket Servers

Deno addresses several pain points that developers encounter with Node.js when building real-time applications. The runtime includes native WebSocket support through the Deno.upgradeWebSocket() API, eliminating the need for external dependencies or third-party libraries. This integration means you can create fully functional WebSocket servers with minimal code while maintaining compatibility with web standards MDN Web Docs.

The security model in Deno requires explicit permissions for network access, file system operations, and other sensitive capabilities. When running a WebSocket server, you specify exactly which ports and networks your application can access, reducing the attack surface of your real-time applications. This approach aligns with security best practices for production deployments where minimizing privileges helps contain potential breaches Transloadit DevTip.

TypeScript support is built directly into Deno, meaning your WebSocket server code benefits from type safety without additional build steps or configuration. This becomes particularly valuable in larger applications where maintaining consistency across server and client codebases prevents runtime errors and improves developer productivity. Our team leverages these capabilities when building custom web applications that require reliable real-time communication.

Setting Up Your Development Environment

Before creating your first WebSocket server, ensure Deno is installed on your system. The installation process varies by operating system, but all methods result in a single executable that provides the complete runtime environment.

For Unix-based systems including macOS and Linux, you can install Deno using a simple shell command that downloads and configures the runtime automatically. The installation script adds the Deno executable to your path, making the deno command available globally. Windows users have similar options through PowerShell or the Windows Subsystem for Linux.

After installation, verify your setup by running the version command, which displays the current Deno release. Deno 2.6 and later versions include the WebSocket APIs used throughout this guide, so ensure you're running a recent enough version to access all features. The runtime updates regularly, and staying current ensures you benefit from performance improvements and security patches.

Create a dedicated project directory for your WebSocket server to keep your files organized. Within this directory, you'll create separate files for the server code and any client-side examples you want to test. Deno projects don't require a package.json or node_modules directory, so your project structure remains clean and straightforward.

Creating Your First WebSocket Server

The foundation of a Deno WebSocket server is the Deno.serve() function, which handles HTTP requests and can upgrade connections to WebSocket protocol. This dual-purpose approach means your server can serve both the WebSocket endpoint and any static files needed for client applications.

Create a file named server.ts in your project directory and add the following code to implement a basic WebSocket server that echoes received messages back to clients. This server implementation demonstrates several key concepts in WebSocket development. The handler function receives all HTTP requests, and we check for the upgrade header to determine whether to create a WebSocket connection or serve a regular response. When upgrading, Deno.upgradeWebSocket() returns both the WebSocket object and the HTTP response needed to complete the handshake.

Deno.serve({
 port: 8080,
 async handler(request) {
 if (request.headers.get("upgrade") !== "websocket") {
 // Serve the client HTML file for regular HTTP requests
 const file = await Deno.open("./index.html", { read: true });
 return new Response(file.readable);
 }

 // Upgrade the connection to WebSocket
 const { socket, response } = Deno.upgradeWebSocket(request);

 socket.onopen = () => {
 console.log("CONNECTED");
 };

 socket.onmessage = (event) => {
 console.log(`RECEIVED: ${event.data}`);
 // Echo the message back to the client
 socket.send("pong");
 };

 socket.onclose = () => console.log("DISCONNECTED");
 socket.onerror = (error) => console.error("ERROR:", error);

 return response;
 },
});

Event handlers for onopen, onmessage, onclose, and onerror define how your server responds to the connection lifecycle. The onmessage handler receives data from clients and can process it, store it, or broadcast it to other connected clients depending on your application needs.

Running Your Server

Execute your server using the Deno run command with appropriate permissions. The --allow-net permission grants network access, while --allow-read permits serving static files from your local filesystem:

deno run --allow-net=0.0.0.0:8080 --allow-read=./index.html server.ts

The 0.0.0.0:8080 specification tells Deno to listen on all network interfaces at port 8080, making your server accessible to clients on your network. Adjust the port number as needed for your deployment environment. Once running, your server listens for incoming connections and handles WebSocket upgrades automatically. Console logging helps you monitor connections and debug issues during development, while in production you might integrate with logging systems for operational visibility.

Key Concepts

• Handler Function: Receives all HTTP requests and determines whether to upgrade to WebSocket or serve regular content. The handler is the central point for request processing and can route traffic based on headers, paths, or any other request characteristics.

• Upgrade Process: Deno.upgradeWebSocket() returns both the WebSocket object and HTTP response, enabling seamless protocol transition without closing the original connection. This method handles the WebSocket handshake protocol, validating the upgrade request and preparing the connection for bidirectional communication.

• Event Handlers: onopen, onmessage, onclose, and onerror define server behavior throughout the connection lifecycle. Properly implementing these handlers ensures your application responds appropriately to connection events, handles incoming data correctly, and cleans up resources when connections terminate.

Building a Client for Testing

Testing your WebSocket server requires a client implementation that can establish connections and send or receive messages. Create an index.html file in your project directory with the following client-side code. This client connects to your server, automatically sends a "ping" message upon establishing a connection, and continues sending pings every five seconds. The server responds with "pong" messages, demonstrating bidirectional communication.

<h2>WebSocket Test</h2>
<p>Sends a ping every five seconds</p>
<div id="output"></div>

<script>
 const wsUri = "ws://127.0.0.1:8080/";
 const output = document.querySelector("#output");
 const websocket = new WebSocket(wsUri);
 let pingInterval;

 function writeToScreen(message) {
 output.insertAdjacentHTML("afterbegin", `<p>${message}</p>`);
 }

 function sendMessage(message) {
 writeToScreen(`SENT: ${message}`);
 websocket.send(message);
 }

 websocket.onopen = (e) => {
 writeToScreen("CONNECTED");
 sendMessage("ping");
 pingInterval = setInterval(() => {
 sendMessage("ping");
 }, 5000);
 };

 websocket.onclose = (e) => {
 writeToScreen("DISCONNECTED");
 clearInterval(pingInterval);
 };

 websocket.onmessage = (e) => {
 writeToScreen(`RECEIVED: ${e.data}`);
 };

 websocket.onerror = (e) => {
 writeToScreen(`ERROR: ${e.data}`);
 };
</script>

The client-side WebSocket API follows web standards that work consistently across all modern browsers. The WebSocket constructor takes the server URL and automatically initiates the connection handshake. Event handlers for open, message, close, and error events allow your client to respond to connection state changes and incoming data. Open this HTML file in a web browser while your server runs to see the connection establish and message exchange in real time.

Understanding the WebSocket Connection Lifecycle

WebSocket connections progress through distinct states that your server code must handle appropriately. Understanding these states helps you build robust applications that respond correctly to connection events and avoid sending messages to closed connections.

• CONNECTING (0): The initial handshake is in progress, and the connection isn't yet ready for data transfer. While this state is typically brief, your client code should account for it when establishing connections to avoid sending data before the connection is ready.

• OPEN (1): The WebSocket connection is established and ready for bidirectional communication. This is when your onopen event handler fires, indicating it's safe to send messages to the server. Both client and server maintain this state until one party initiates closure.

• CLOSING (2): A close frame has been sent or received, signaling the intention to terminate the connection. During this transitional state, any queued messages should be sent, but new messages shouldn't be added since the connection will close shortly.

• CLOSED (3): The connection has been fully terminated. At this point, no further communication is possible, and attempting to send messages results in errors. Your cleanup code should run in the onclose handler to release resources and update application state.

Understanding the full lifecycle matters for building robust real-time applications because connection failures can occur at any point. Your code must handle unexpected disconnections gracefully, implement reconnection logic when appropriate, and avoid sending messages to connections that are no longer active. This prevents errors and ensures users receive a consistent experience even when network conditions fluctuate.

Checking Connection Readiness

Before sending messages, verify the socket is in the OPEN state to prevent errors:

function isSocketReady(socket: WebSocket): boolean {
 return socket.readyState === WebSocket.OPEN;
}

socket.onmessage = (event) => {
 if (!isSocketReady(socket)) {
 return;
 }
 // Handle message safely
};

This pattern prevents race conditions where code attempts to send messages during the brief window when a connection is closing. Always check readyState before sending data, especially in code paths that might execute rapidly or asynchronously.

Broadcasting Messages to Multiple Clients

Real-world applications often require sending messages to multiple connected clients simultaneously. A chat room, for example, needs to broadcast each user's message to all other participants. This requires maintaining a collection of active connections and iterating through them when broadcasting.

The Set data structure efficiently tracks connected WebSocket instances. When a message arrives, the server iterates through all clients and sends the message to each one except the original sender. The readyState check ensures you only send to connections that can actually receive data.

const clients = new Set<WebSocket>();

Deno.serve({
 port: 8080,
 async handler(request) {
 if (request.headers.get("upgrade") !== "websocket") {
 return new Response(null, { status: 501 });
 }

 const { socket, response } = Deno.upgradeWebSocket(request);

 socket.onopen = () => {
 clients.add(socket);
 console.log(`Client connected. Total clients: ${clients.size}`);
 };

 socket.onmessage = (event) => {
 // Broadcast to all connected clients except the sender
 for (const client of clients) {
 if (client !== socket && client.readyState === WebSocket.OPEN) {
 client.send(event.data);
 }
 }
 };

 socket.onclose = () => {
 clients.delete(socket);
 console.log(`Client disconnected. Total clients: ${clients.size}`);
 };

 socket.onerror = (error) => console.error("ERROR:", error);

 return response;
 },
});

Tracking Connected Clients

Managing a collection of connected clients requires careful attention to both adding and removing connections. When a client establishes a connection, the onopen handler adds the WebSocket to the Set. When connections close, whether gracefully or due to errors, the onclose handler removes them. This ensures your client set remains accurate and doesn't accumulate dead connections.

The broadcasting loop iterates through all connected clients and sends the incoming message to each one. The check for client !== socket prevents echo-back to the sender, while the readyState === WebSocket.OPEN check ensures you only send to connections capable of receiving data. This pattern scales to hundreds or thousands of concurrent connections, though very large deployments may require additional infrastructure like load balancers or message queues to distribute load across multiple server instances.

Implementing Security Best Practices

Production WebSocket servers face security challenges including malicious input, connection abuse, and denial-of-service attacks. Implementing safeguards protects your application and the clients connecting to it.

Input Validation

All incoming messages should be validated before processing to prevent injection attacks and unexpected behavior:

function validateMessage(data: unknown): boolean {
 if (typeof data !== "string") {
 return false;
 }

 try {
 const message = JSON.parse(data);
 return typeof message === "object" && message !== null && typeof message.type === "string";
 } catch {
 return false;
 }
}

socket.addEventListener("message", (event) => {
 if (!validateMessage(event.data)) {
 socket.send(JSON.stringify({ type: "error", message: "Invalid message format" }));
 return;
 }
 // Process valid messages
});

This validation function checks that incoming data is a properly formatted JSON object with a type field, ensuring your application receives expected message structures. Beyond JSON validation, consider validating message content against your application's schema, checking for prohibited patterns, and sanitizing any user-generated content before storing or broadcasting it.

Rate Limiting

Prevent clients from overwhelming your server with excessive messages by implementing rate limiting:

class RateLimiter {
 private requests = new Map<string, number[]>();
 private readonly limit: number;
 private readonly window: number;

 constructor(limit = 100, window = 60000) {
 this.limit = limit;
 this.window = window;
 }

 isAllowed(clientId: string): boolean {
 const now = Date.now();
 const timestamps = this.requests.get(clientId) || [];
 const recent = timestamps.filter((time) => now - time < this.window);

 if (recent.length >= this.limit) {
 return false;
 }

 recent.push(now);
 this.requests.set(clientId, recent);
 return true;
 }
}

The rate limiter tracks message timestamps per client, allowing a configurable number of messages within a time window. Clients exceeding the limit can be disconnected or temporarily blocked. Consider setting limits based on your application's requirements--chat applications might allow higher rates than systems processing complex computations.

Message Size Limits

Constrain message sizes to mitigate denial-of-service attacks that attempt to exhaust server memory:

const MAX_MESSAGE_SIZE = 1024 * 1024; // 1MB

socket.addEventListener("message", (event) => {
 if (typeof event.data === "string" && event.data.length > MAX_MESSAGE_SIZE) {
 socket.send(
 JSON.stringify({
 type: "error",
 message: "Message size exceeds limit",
 })
 );
 return;
 }
 // Process message
});

Setting reasonable limits prevents malicious clients from sending extremely large messages that could impact server performance or crash the application. A 1MB limit suits most applications, though you might adjust based on your specific use case. Remember that text messages, JSON payloads, and binary data all count toward this limit.

Performance Optimization Strategies

Building high-performance WebSocket servers requires attention to connection management, message handling efficiency, and resource utilization. These optimizations help your application scale to handle more concurrent connections while maintaining responsive communication.

Efficient Message Processing

Avoid blocking operations in your event handlers. When processing messages requires significant computation, consider offloading work to separate tasks or worker threads. This keeps your WebSocket loop responsive to new messages and connection events. For applications with high message volumes, implementing message batching can reduce the overhead of individual sends. Rather than sending each update immediately, queue messages and send them in periodic batches. The trade-off is slightly increased latency in exchange for better throughput.

Connection Lifecycle Management

Properly close connections that have been inactive for extended periods to free server resources. Implement heartbeat messages that clients must respond to within a timeout period. Clients that fail to respond can be safely disconnected, preventing zombie connections from accumulating:

const HEARTBEAT_INTERVAL = 30000;
const TIMEOUT_MS = 60000;

setInterval(() => {
 for (const socket of clients) {
 if (socket.readyState !== WebSocket.OPEN) {
 clients.delete(socket);
 continue;
 }
 // Check last activity timestamp and close stale connections
 if (Date.now() - socket.lastActivity > TIMEOUT_MS) {
 socket.close();
 clients.delete(socket);
 }
 }
}, HEARTBEAT_INTERVAL);

Memory Efficiency

WebSocket connections consume memory for their internal buffers and any application state you maintain. Monitor memory usage in production and consider implementing connection limits based on your server's available resources. For very large-scale deployments, distributed architectures using multiple server instances behind a load balancer provide horizontal scaling.

Integration with Modern Web Applications

WebSocket servers built with Deno integrate seamlessly with modern frontend frameworks and backend architectures. For Next.js applications, your WebSocket server typically runs alongside the Next.js dev server or as a separate production service. During development, you might run both servers and configure your frontend to connect to the WebSocket server's port. In production, deploying the WebSocket server as a separate service allows independent scaling based on connection counts.

Authentication for WebSocket connections can reuse existing session mechanisms. When a client establishes a WebSocket connection, include authentication tokens in the initial request headers or query parameters. Your server validates these credentials before completing the upgrade, ensuring only authenticated clients can establish real-time connections.

State synchronization between your WebSocket server and database requires careful design. Changes made through your WebSocket handlers should persist to your database, while database changes initiated elsewhere need a mechanism to push updates to connected clients. This might involve your WebSocket server subscribing to database change events or integrating with a message bus that distributes updates.

Conclusion

Building WebSocket servers with Deno combines the simplicity of web standards with the security and developer experience of a modern runtime. The built-in Deno.upgradeWebSocket() API handles the complexity of connection upgrades, while Deno's permission system ensures your real-time applications follow security best practices from day one. Start with the basic echo server implementation, then progressively add features like broadcasting, authentication, and rate limiting as your application requirements grow.

The patterns demonstrated here provide a foundation for building production-ready real-time applications, whether you're creating collaborative tools, live dashboards, or interactive experiences that keep users engaged with instant feedback. As you extend your WebSocket server, remember to test under realistic load conditions and monitor performance metrics. Real-time features often become critical paths in user experience, making reliability and responsiveness essential for user satisfaction.

If you're building complex real-time applications and want expert guidance, our web development team has extensive experience with Deno, WebSockets, and modern frontend architectures. We help businesses implement robust real-time features that scale, from collaborative editing platforms to live data dashboards and beyond. Contact us to discuss how we can help bring your real-time application ideas to life.

Sources

1. MDN Web Docs: Writing a WebSocket server in JavaScript (Deno)
2. Transloadit: Real-time file processing with Deno and WebSockets
3. Deno Official Website