Art of Code
Back to Blog
Web Development

Cap'n Web: The 10KB RPC Library That Could Replace REST and GraphQL

Cloudflare just dropped Cap'n Web, a sub-10KB RPC library that lets you chain multiple API calls into a single network round trip. Here is why it matters and how it stacks up against REST, GraphQL, tRPC, and gRPC in 2026.

Curious Adithya10 min read
Cap'n Web: The 10KB RPC Library That Could Replace REST and GraphQL

The API Layer Problem Nobody Solved

Every backend developer has lived through the same cycle. You build REST endpoints, your frontend team complains about over-fetching or under-fetching data. Someone suggests GraphQL, and suddenly you are learning a new query language, setting up resolvers, and maintaining schemas that drift out of sync with your actual code.

tRPC fixed some of this for TypeScript teams by giving you end-to-end type safety without schemas. But it still has limitations. You cannot chain dependent calls in a single round trip. You cannot have the server call the client back. And you are locked into the TypeScript ecosystem.

Now Cloudflare has released something that rethinks the entire approach. It is called Cap'n Web, and it might be the most interesting API architecture shift since GraphQL landed in 2015.

What Is Cap'n Web?

Cap'n Web is a JavaScript/TypeScript-native RPC system built by Kenton Varda at Cloudflare. If that name sounds familiar, it should. Kenton created Cap'n Proto (the serialization protocol) over a decade ago and made significant contributions to Protocol Buffers and gRPC at Google before that.

The core idea is deceptively simple: what if calling a remote API looked exactly like calling a local JavaScript function?

Not in a hand-wavy, leaky-abstraction way. In a way where you literally write await api.hello("World") and the library handles everything: serialization, transport, batching, and even chaining multiple calls into a single network round trip.

The entire library compresses to under 10 KB with zero dependencies. For comparison, the Apollo GraphQL client weighs in at around 30-40 KB gzipped. tRPC's client is roughly 15 KB. Cap'n Web delivers more functionality in a fraction of the size.

How It Actually Works

Let us walk through a basic setup.

Server Side (Cloudflare Worker)

class MyApiServer extends RpcTarget {
  hello(name) {
    return `Hello, ${name}!`;
  }

  getMyName() {
    return "Alice";
  }
}

export default {
  fetch(request) {
    if (new URL(request.url).pathname === "/api") {
      return newWorkersRpcResponse(request, new MyApiServer());
    }
    return new Response("Not found", { status: 404 });
  }
};

No schema files. No route definitions. No method decorators. You write a class with methods, and those methods become your API.

Client Side

let api = newWebSocketRpcSession("wss://example.com/api");
let result = await api.hello("World");
console.log(result); // "Hello, World!"

That is it. No fetch calls, no URL construction, no parsing response bodies, no figuring out whether this should be GET or POST. You call a function and get a result.

The Feature That Changes Everything: Promise Pipelining

This is where Cap'n Web goes from "neat" to "genuinely revolutionary."

Consider a common pattern: you authenticate a user, get back a token, then use that token to fetch their profile. In REST, that is two sequential HTTP calls. In GraphQL, you would need to restructure your schema to support this in one query. In tRPC, you would use a batch call but still need to await the first result.

In Cap'n Web:

let batch = newHttpBatchRpcSession("/api");

let namePromise = batch.getMyName();
let result = await batch.hello(namePromise);

Look carefully at that second line. We are passing namePromise directly into batch.hello() without awaiting it first. The name has not come back from the server yet. It is still a promise.

But Cap'n Web makes this work. The client sends a single HTTP request that says: "Call getMyName, then take whatever it returns and pass it into hello." One round trip. Two operations. Zero waterfalls.

This works because Cap'n Web returns special proxy objects instead of regular JavaScript promises. These proxies record every operation you perform on them and batch everything into a single network call when you finally await.

Bidirectional RPC: The Server Calls You Back

Most API protocols are one-directional. The client sends a request, the server responds. Even WebSocket-based APIs typically require you to set up separate event handlers for server-initiated messages.

Cap'n Web treats both sides as equals. When you pass a function over RPC, the recipient gets a stub. Calling that stub actually makes an RPC call back to wherever the function was originally created.

// Client passes a callback to the server
await api.subscribe(notification => {
  console.log("Server says:", notification);
});

The server can invoke that callback at any time. No special WebSocket event handling. No pub/sub infrastructure. The callback just works, as if both computers were running the same program.

The Map Innovation: Array Processing Without Round Trips

Processing arrays of data usually means either fetching everything at once (potentially huge payloads) or making N requests for N items (the N+1 problem).

Cap'n Web introduces a .map() function that solves this elegantly:

let friends = api.authenticate(token).listFriends();

let friendsWithPhotos = friends.map(friend => {
  return { friend, photo: api.getUserPhoto(friend.id) };
});

let results = await friendsWithPhotos;

None of this has made a network call yet. Not the authenticate, not the listFriends, not the map. Everything is recorded.

When you hit that final await, Cap'n Web sends a single request. The server authenticates, gets the friends list, fetches each friend's photo, and returns everything at once.

Under the hood, Cap'n Web uses a "record-replay" mechanism. It runs your .map() callback once with a placeholder value, records what RPC calls you made, and converts those into a set of instructions sent to the server. The server replays those instructions for each array element.

The instruction set is intentionally not Turing-complete. You cannot run arbitrary JavaScript on the server through .map(). It only supports the operations that the RPC protocol itself can represent. This is a security feature, not a limitation.

How Cap'n Web Compares to Everything Else in 2026

The API layer landscape has gotten crowded. Here is an honest comparison:

Cap'n Web vs REST

REST is universal and simple. It works with any language, any client, any server. REST still appears in 70% of job postings as of early 2026. But REST forces you to think in terms of HTTP methods, URLs, status codes, and JSON serialization. Cap'n Web lets you think in terms of functions and objects.

Choose REST when you need a public API consumed by unknown clients. Choose Cap'n Web when both client and server are JavaScript and you control both sides.

Cap'n Web vs GraphQL

GraphQL solved the over-fetching problem but introduced a new query language, schema definitions, resolvers, and specialized tooling. GraphQL mentions in job postings have actually dropped from 40% to 25% since early 2025.

Cap'n Web solves the same waterfall problem through promise pipelining without any new language. Mutations in GraphQL are notoriously awkward. In Cap'n Web, they are just function calls.

Choose GraphQL for complex, deeply nested data models where fragment co-location matters. Choose Cap'n Web when your API is more about operations than data queries.

Cap'n Web vs tRPC

tRPC is the closest comparison. Both give you type-safe, function-style API calls in TypeScript. tRPC has strong adoption (15% of job postings and climbing) and tight Next.js integration.

But Cap'n Web goes further: promise pipelining, bidirectional calls, and the map innovation are features tRPC does not offer. tRPC also requires both client and server to share a TypeScript project or monorepo. Cap'n Web works across any JavaScript runtime.

Choose tRPC if you are already in a Next.js monorepo and want mature ecosystem support. Choose Cap'n Web if you need advanced RPC features or work with Cloudflare Workers.

Cap'n Web vs gRPC

gRPC dominates service-to-service communication with its binary protocol and 60-80% bandwidth savings. But gRPC in the browser requires gRPC-Web proxies and Protocol Buffer code generation.

Cap'n Web uses JSON (human-readable, debuggable) and works natively in every browser. Different tools for different jobs.

Choose gRPC for internal microservice communication. Choose Cap'n Web for browser-to-server communication.

The Object Capability Security Model

One feature that does not get enough attention is Cap'n Web's security model. It uses an object capability pattern. Instead of checking permissions on every request, you structure your API so that having a reference to an object IS the permission.

class MyApi extends RpcTarget {
  authenticate(credentials) {
    if (!valid(credentials)) throw new Error("Unauthorized");
    return new AuthenticatedSession(credentials.userId);
  }
}

class AuthenticatedSession extends RpcTarget {
  constructor(userId) {
    super();
    this.userId = userId;
  }

  getProfile() {
    return db.getUser(this.userId);
  }

  listFriends() {
    return db.getFriends(this.userId);
  }
}

If you have not authenticated successfully, you never get a reference to AuthenticatedSession. You cannot call getProfile or listFriends because you do not have the object. No middleware. No token validation on every endpoint. The architecture itself enforces security.

Transport Flexibility

Cap'n Web works over three transports out of the box:

  • WebSocket for persistent connections with full bidirectional support
  • HTTP batch mode for stateless request/response patterns (single round trip per batch)
  • postMessage() for communication between iframes, web workers, or browser extensions

You can also implement custom transports. The protocol does not assume anything about the underlying communication channel.

What Cloudflare Is Already Doing With It

This is not just a theoretical exercise. Cloudflare has already deployed Cap'n Web in production for their "remote bindings" feature in Wrangler. This lets local development instances of Cloudflare Workers communicate with production services through RPC, replacing what would otherwise be complex HTTP proxy setups.

Should You Use It Today?

Honest answer: probably not in production yet. Cap'n Web is open source under the MIT license and available on GitHub, but it is still early. The ecosystem is small, community resources are limited, and there will be bugs.

But you should absolutely study it. The concepts behind Cap'n Web, especially promise pipelining and the record-replay mechanism, represent genuine innovations in how we think about client-server communication. Even if you never use Cap'n Web directly, understanding these patterns will make you a better API designer.

The JavaScript RPC space is evolving fast. REST is not going anywhere for public APIs. GraphQL has found its niche in complex data-heavy applications. tRPC owns the TypeScript monorepo workflow. And now Cap'n Web is carving out territory for advanced, capability-based RPC in the JavaScript ecosystem.

The best API choice in 2026 is not about picking a winner. It is about understanding what each tool does best and matching it to your specific problem.

Key Takeaways

  • Cap'n Web is a sub-10KB RPC library from Cloudflare with zero dependencies
  • Promise pipelining lets you chain multiple API calls into a single network round trip
  • Bidirectional RPC means the server can call client functions and vice versa
  • The .map() function processes arrays server-side without extra round trips using record-replay
  • Object capability security model eliminates the need for auth middleware on every endpoint
  • Works over WebSocket, HTTP, and postMessage out of the box
  • Created by Kenton Varda, who also built Cap'n Proto and contributed to Protocol Buffers
  • Still early stage, but the concepts are worth studying regardless of adoption