Add support for TRPC and MQTT

[Rednas83]

Are there any plans (or interest) in expanding h3's ecosystem to support additional communication protocols, or to provide guidance on integrating them?

Specifically:
tRPC To enable fully type-safe RPC communication between frontend and backend (especially in Nuxt/Nitro contexts).
MQTT For real-time, event-driven communication, commonly used in IoT or pub/sub scenarios.

[faner11]

Looking forward to tRPC

[amondnet]

Try using oRPC. Supports Nuxt and H3

[kricsleo]

Have you considered the h3 - middleware, is it flexible enough to integrate tRPC/MQTT, similar to how oRPC - H3 Adapter does? 🤔

[pi0]

I haven’t checked their docs but if they export a fetchable interface, we might just mount them on a prefix?

[productdevbook]

@pi0 This is already solved by the ecosystem — no changes needed in h3 core.

tRPC

tRPC has a Fetch API adapter that works with any fetch-compatible server. With h3 v2, integration is straightforward:

import { fetchRequestHandler } from "@trpc/server/adapters/fetch";

app.use("/trpc/**", (event) =>
  fetchRequestHandler({
    endpoint: "/trpc",
    req: event.req,
    router: appRouter,
    createContext: () => ({}),
  })
);

Community packages also exist: trpc-nitro-adapter, trpc-nuxt.

oRPC

oRPC already has an official h3 adapter using RPCHandler with event.req:

app.use("/rpc/**", async (event) => {
  const { matched, response } = await handler.handle(event.req, { prefix: "/rpc" });
  if (matched) return response;
});

MQTT

MQTT is a pub/sub protocol fundamentally different from HTTP — it doesn't fit h3's request/response model. MQTT clients/brokers (like mqtt.js, aedes) should be used directly alongside h3, not through it.

Why this works

h3 v2 is built on web standard Request/Response. Any library that exports a fetch-compatible handler can be mounted via app.use() or app.mount(). No special adapters needed in h3 core — as you mentioned, "if they export a fetchable interface, we might just mount them."

Can this be closed?

[productdevbook]

Updating my earlier comment after deeper investigation. While tRPC/oRPC do work with h3, there IS a friction point:

The Context Bridge Problem

h3 middleware sets auth/user data on event.context, but this doesn't reach mounted fetch handlers:

// h3 middleware sets context
app.use((event, next) => {
  event.context.user = await authenticate(event);
  return next();
});

// ❌ app.mount() creates new Request — event.context is lost
app.mount("/rpc", rpcHandler);

// ✅ app.use() works but requires manual context bridging
app.use("/rpc/**", async (event) => {
  const { response } = await handler.handle(event.req, {
    context: { user: event.context.user }, // manual copy
  });
  return response;
});

Root cause: mount() at src/h3.ts:147 creates new Request(url, event.req) — this is a plain web Request with no h3 context. The mounted handler can't access event.context.

Potential h3 improvement

app.mount() could accept a context factory option:

app.mount("/rpc", rpcHandler, {
  context: (event) => ({ user: event.context.user }),
});

Or the mounted Request could carry context via a header or symbol — but this is a design decision.

@pi0 Is this worth addressing in h3 core, or should RPC adapters handle context bridging themselves?

[pi0]

Thanks for summary @productdevbook. I think after #1342 the issue with carried context would be solved as we will use a proxy instead of chaging context.