chore: add Hono examples

[yusukebe]

This PR adds new examples. They will show how to implement Cap'n Web servers on Cloudflare Workers, Deno, and Node.js with Hono.

[kentonv]

I imagine this doesn't work on Bun, since it doesn't use the standard WebSocket API under the hood. Is that right?

I wonder if it makes sense to write a custom transport specifically for Hono, that uses Hono's wrapper and so works with all runtimes Hono supports?

Although I see Hono's upgradeWebSocket is actually different for each runtime, so perhaps this code can't really be totally runtime-independent anyway?

What do you think?

[yusukebe]

I deeply dived. Bun uses their original ServerWebSocket. This object does not have addEventListener, so the following error is thrown with the code like deno.ts:

Code:

import { Hono } from 'hono'
import { upgradeWebSocket, websocket } from 'hono/bun'
import { MyApiServer } from './my-api-server'
import { newWebSocketRpcSession } from 'capnweb'

const app = new Hono()

app.get(
  '/api',
  upgradeWebSocket((_c) => {
    return {
      onOpen(_event, ws) {
        newWebSocketRpcSession(ws.raw!, new MyApiServer())
      }
    }
  })
)

export default {
  fetch: app.fetch,
  port: 8787,
  websocket
}

Error:

---

But Bun's ServerWebSocket can handle the methods, such as message or error. So, I think Cap'n Web can work on Bun with a wrapper or something.

My idea to connect Cap'n Web and Hono is to create the adapter(or should we say it's a transport?) like this:

// ...
import { newHonoRpcResponse } from 'capnweb' // or @hono/capnweb-server

const app = new Hono()

app.all('/api', (c) => {
  return newHonoRpcResponse(c, new MyApiServer(), {
    upgradeWebSocket
  })
})

export default app

With this API, you can run it on any runtime supported by Hono, using upgradeWebSocket. It is the same interface between them. We can also make it support Bun by wrapping the ServerWebSocket inside.

This is PoC, but it works:

https://gist.github.com/yusukebe/ec1747487bc22f06eb14e348abb7370c#file-capnweb-server-hono-ts

For example, the Bun code:

import { Hono } from 'hono'
import { upgradeWebSocket, websocket } from 'hono/bun'
import { MyApiServer } from './my-api-server'
import { newHonoRpcResponse } from './capnweb-server-hono.ts'

const app = new Hono()

app.all('/api', (c) => {
  return newHonoRpcResponse(c, new MyApiServer(), {
    upgradeWebSocket
  })
})

export default {
  fetch: app.fetch,
  port: 8787,
  websocket
}

The above case is to support Bun on the Hono side.

[kentonv]

Sorry for the long delay here, I got slammed with too many things in the last month (the benchmark saga, Connect, some vacation time, ...)

But I'd like to get back to this!

So picking this conversation back up:

OK, it looks like you've written newHonoRpcResponse() which handles all the cross-runtime stuff. That's nice and would be nice to ship somewhere.

But also I think Cap'n Web needs to support Bun directly, independent of Hono. I wonder if there's a way we can ship this compat layer that isn't specific to Hono, but such that Hono can leverage it? But I see that Hono seems to have some of its own code already in hono/ws which adapts various WebSocket runtime APIs, and you are building on top of that. So maybe it doesn't actually make sense to support Bun and Hono-Bun at the same time after all?

Anyway, I would like to ship newHonoRpcResponse() somewhere. I suppose it should be part of Cap'n Web, but of course we don't want Cap'n Web itself to have a dependency on Hono. Is there a way to ship this code with Cap'n Web as an optional add-on that doesn't force the dependency, or do we need to make it a separate package? I'm not that experienced with JavaScript tooling...

[threepointone]

there are plenty of hono-* packages, so hono-capnweb can totally be a thing (or even officially as a @hono/ package

[yusukebe]

@kentonv

But also I think Cap'n Web needs to support Bun directly, independent of Hono. I wonder if there's a way we can ship this compat layer that isn't specific to Hono, but that Hono can still leverage?

I think it's possible to make Cap'n Web support Bun without Hono. The difference between Bun's API and others is only the interface. I'll take a look at it deeply.

[kentonv]

Yes, I do want to directly support Bun's API, that's #61... I'm just wondering if it makes any sense for the Hono adapter to then reuse that code, or if the Hono adapter should be totally separate. It looks like Hono already adapts WebSockets to use a more common interface across runtimes so it might make sense for the Hono adapter to just be totally independent of the Bun adapter.

there are plenty of hono-* packages, so hono-capnweb can totally be a thing (or even officially as a @hono/ package

Yeah I suppose. Should the code be in a separate repo or should we make a "packages" directory in this repo?

[yusukebe]

Ah, there is a ready #61! The approch by @grampelberg is great. With it, we can make Cap'n Web support Bun independent of Hono. Let's discuss it on #61.

We, Hono side, will develop "Cap'n Web Adapter" as @hono/capnweb in our repo (honojs/middleware), not in this repo.

Regarding this PR, I'll revise after creating @hono/capnweb.

[yusukebe]

Hi. We released @hono/capnweb:

https://github.com/honojs/middleware/tree/main/packages/capnweb

If you want to use Cap'n Web with Hono, you can use it. So, these examples are no longer needed. I'll close this PR now, but we may have to update the README to point out @hono/capnweb. Anyway, thanks.