Cloudflare workers expand beyond HTTP with socket APIs and Socket Workers

Cloudflare has announced it is developing APIs and infrastructure to support TCP, UDP, and QUIC-based protocols in Cloudflare Workers. Once released, developers will be able to use non-HTTP socket connections to and from a Worker or Durable Object as easily as they currently use HTTP and WebSockets.

Today, Cloudflare Workers support HTTP and WebSocket connections through the standardized fetch() and WebSocket APIs. Cloudflare has demonstrated a proof-of-concept using an off-the-shelf Deno-based Postgres client driver to communicate with a remote Postgres server through a WebSocket connection established via a secure Cloudflare Tunnel.

import { Client } from './driver/postgres/postgres'

export default {
  async fetch(request: Request, env, ctx: ExecutionContext) {
    try {
      const client = new Client({
        user: 'postgres',
        database: 'postgres',
        hostname: 'https://db.example.com',
        password: '',
        port: 5432,
      })
      await client.connect()
      const result = await client.queryArray('SELECT * FROM users WHERE uuid=1;')
      ctx.waitUntil(client.end())
      return new Response(JSON.stringify(result.rows[0]))
    } catch (e) {
      return new Response((e as Error).message)
    }
  },
}

The working example replaces the TCP socket API calls in the Postgres driver with standard fetch and WebSocket APIs. A WebSocket connection is then opened to a remote Cloudflare Tunnel daemon running next to the Postgres server, effectively creating TCP-over-WebSockets.

Connecting to a backend data center via a Cloudflare Tunnel

Although this approach works and performs well, it has limitations. It requires additional infrastructure—namely, the Cloudflare Tunnel daemon instance—to be running alongside the database. Moreover, tunneling TCP over WebSockets, which is itself tunneled over HTTP via TCP, is inefficient. Cloudflare acknowledges this works, but believes it can do better.

Designing a standard socket API for JavaScript

A significant challenge is that no standard API exists for socket connections in JavaScript. Node.js developers are familiar with net.Socket and net.TLSSocket objects, while Deno recently introduced Deno.connect() and Deno.connectTLS(). These APIs accomplish the same goal but differ considerably from one another.

Cloudflare has decided against creating yet another non-standard, platform-specific API. Instead, the company is inviting other JavaScript runtime platforms to collaborate on a new, eventually standardized socket API that works consistently across runtimes.

Here is a rough sketch of the proposed approach for opening and reading from a simple TCP client connection:

const socket = new Socket({
  remote: { address: '123.123.123.123', port: 1234 },
})
for await (const chunk of socket.readable)
  console.log(chunk)

Or this example of sending a simple "hello world" packet using UDP:

const socket = new Socket({
  type: 'udp',
  remote: { address: '123.123.123.123', port: 1234 },
});
const enc = new TextEncoder();
const writer = socket.writable.getWriter();
await writer.write(enc.encode('hello world'));
await writer.close();

The API is designed to work generically on both the client and server side; across TCP, UDP, and QUIC; with or without TLS; and without relying on mechanisms unique to any single JavaScript runtime. It will build on widely supported Web Platform standards, including EventTarget, ReadableStream, WritableStream, AbortSignal, and promises, making it familiar to developers who work with fetch(), service workers, and async/await.

interface Socket : EventTarget {
  constructor(object SocketInit);

  Promise<undefined> update(object SocketInit);

  readonly attribute ReadableStream readable;
  readonly attribute WritableStream writable;
  
  readonly attribute Promise<undefined> ready;
  readonly attribute Promise<undefined> closed;

  Promise<undefined> abort(optional any reason);
  readonly attribute AbortSignal signal;
 
  readonly attribute SocketStats stats;
  readonly attribute SocketInfo info;
}

Introducing Socket Workers

Opening socket client connections is only half of what Cloudflare has planned. The company also considered using non-HTTP protocols for inbound connections to Workers. This would enable scenarios such as implementing an entire database on the edge inside Workers, with non-HTTP clients connecting directly to it. Other possibilities include SMTP servers, MQTT message queues, VoIP platforms, packet filters, transformations, inspectors, or protocol transcoders.

To support these use cases, Cloudflare will introduce Socket Workers—Workers that can be connected to directly using raw TCP, UDP, or QUIC protocols, bypassing HTTP entirely. Many details remain in development, but the concept involves deploying a Worker script that handles "connect" events in a manner similar to how "fetch" events work today. The idea builds on the same common socket API being developed for client connections:

addEventListener('connect', (event) => {
  const enc = new TextEncoder();
  const writer = event.socket.writable.getWriter();
  writer.write(enc.encode('Hello World'));
  writer.close();
});

Development status and early access

The socket API for JavaScript and Socket Workers are under active development, with initial focus on improving Workers' ability to connect efficiently to backend databases. Developers can join a waitlist for early access to Database Connectors and Socket Workers. Cloudflare plans to work with early users and technology partners to develop, refine, and test these new capabilities, expecting that Socket Workers will significantly expand the range of intelligent distributed applications that can run at the network edge.