Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[@hono/vite-dev-server] add bun websocket support #140

Open
youcefs21 opened this issue May 19, 2024 · 3 comments
Open

[@hono/vite-dev-server] add bun websocket support #140

youcefs21 opened this issue May 19, 2024 · 3 comments

Comments

@youcefs21
Copy link

youcefs21 commented May 19, 2024

dev server does not run websocket:

import { Hono } from "hono";
import { createBunWebSocket } from "hono/bun";

const { upgradeWebSocket, websocket } = createBunWebSocket();

const app = new Hono();

const ws = app.get(
    "/ws",
    upgradeWebSocket((c) => {
        console.log("WebSocket connected");
        let intervalId: Timer;
        return {
            onOpen(_event, ws) {
                intervalId = setInterval(() => {
                    ws.send(new Date().toString());
                }, 200);
            },
            onClose() {
                clearInterval(intervalId);
            },
        };
    }),
);

export default {
    fetch: app.fetch,
    websocket,
};

desired behaviour: should connect to websocket server when new WebSocket("ws://localhost:5173/ws") is called
current behaviour: fetch requests work fine, websocket request hangs

@Blankeos
Copy link

+1 on this.

As a workaround I did this: (Separating 3000 backend and 3001 for ws)
honojs/hono#3013 (comment)

But encountered this: (Two instances of EventEmitter if I separate them, so not really viable for realtime stuff) trpc/trpc#5815 (comment)

It works fine on prod tho. Just dev that kinda sucks for devx.

@Blankeos
Copy link

Blankeos commented Jun 21, 2024

To add more to the discussion. Here's a video to demonstrate that visually.

I was thinking I could just change the HMR port so it doesn't conflict with each other inside vite.config.js (It did not work tho).

hono.dev.server.websockets.bug.mp4

Have not tested on Node yet. But will try if I can when I get time.

@yusukebe
Copy link
Member

yusukebe commented Jul 1, 2024

Hi @youcefs21 @Blankeos

Hmmmm. I've reconsidered this issue. However, the WebSocket matter is tricky for the Vite dev-server. We can trust fetch based API is common for Cloudflare, Deno, Bun, and Node.js. Unfortunately, however, WebSocket is not standardized. As for that, there is a difference between Bun and Node.js:

Bun:

import { Hono } from 'hono'
import { createBunWebSocket } from 'hono/bun'

const { upgradeWebSocket, websocket } = createBunWebSocket()

// ...

Bun.serve({
  fetch: app.fetch,
  websocket,
})

Node.js:

import { createNodeWebSocket } from '@hono/node-ws'
import { Hono } from 'hono'
import { serve } from '@hono/node-server'

const app = new Hono()

const { injectWebSocket, upgradeWebSocket } = createNodeWebSocket({ app })

app.get('/ws', upgradeWebSocket((c) => ({
  // https://hono.dev/helpers/websocket
})))

const server = serve(app)
injectWebSocket(server)

To enable supporting both, we may add the option for choosing the current running runtime of Vite like the following:

import devServer from '@hono/vite-dev-server'
import { defineConfig } from 'vite'
import { runtime } from '@hono/vite-dev-server/bun'

export default defineConfig({
  plugins: [
    devServer({
      runtime
    })
  ]
})

I think this is relevant to Vite's new environment API: vitejs/vite#16358

Perhaps we can use a different runtime in Vite, like Node.js or worked (or Bun?). So, the better way is not to hurry up and follow the Vite's action though we have to figure out a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants