Wasp•3mo ago

How to externalize the socket.io server?

I saw a previous post by someone that asked a similar question about externalizing the socket server. I've already open up the CORS setting on my server so that any client can send their requests. The thing is that using my postman debugger on the following uri doesn't give too much information: ws://localhost:3001

Error: connect ECONNREFUSED 127.0.0.1:3001
Handshake Details
Request URL: http://localhost:3001/
Request Method: GET
Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: sCMgelsJC8oNtcybifLvfQ==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: localhost:3001

Error: connect ECONNREFUSED 127.0.0.1:3001
Handshake Details
Request URL: http://localhost:3001/
Request Method: GET
Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: sCMgelsJC8oNtcybifLvfQ==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: localhost:3001

If I investigate from the client side, I see a different token generated for the client app. I suppose the client is redirected to the backend server if I see the following websocket popup in the dev panel in my browser: ws://localhost:3000/?token=iYirTHOg-k0x After this all goes directly over localhost:3001 Can someone explain how the auth system works for websockets? and how the flow of websockets work for .wasp in frontend and backend and let me know how I can plug in my external sources? Should I define my own websocket system to externalize? or can I use the existing tooling with minimal changes?

3 Replies

kapa.ai•3mo ago

Hi @gabriel. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Wasp provides a built-in, integrated WebSocket experience using Socket.IO for both the client and server. Here’s how the flow and auth system work, and what’s possible regarding externalizing the Socket.IO server: WebSocket Flow & Auth in Wasp - Server Setup: You define your WebSocket logic in a function (commonly webSocketFn) that receives the Socket.IO io server instance and a context object. This is where you register event handlers and can access user info if authenticated. Wasp automatically injects the JWT into the connection, and if valid, attaches the user to socket.data.user on the server side. This allows you to identify users in your event handlers.
Example:

  export const webSocketFn = (io, context) => {
    io.on('connection', (socket) => {
      const username = getFirstProviderUserId(socket.data.user) ?? 'Unknown';
      // ...
    });
  }

  export const webSocketFn = (io, context) => {
    io.on('connection', (socket) => {
      const username = getFirstProviderUserId(socket.data.user) ?? 'Unknown';
      // ...
    });
  }

Defining the Events Handler - Client Connection: The client uses the useSocket hook to get the socket instance and connection status. Wasp handles the connection automatically unless you set autoConnect: false in your Wasp file.
useSocket Hook - URL Routing: By default, the client connects to the server’s WebSocket endpoint. If you see connections like ws://localhost:3000/?token=..., it’s because the client is connecting through the frontend, which proxies to the backend (usually on port 3001). After the handshake, communication is direct with the backend. CORS and External Clients - Wasp’s server sets CORS to allow all origins by default, but you can adjust this in your server code if needed.
CORS Configuration Issue - If you want to connect external clients (like Postman or another frontend), you need to ensure: - The server is running and accessible on the correct port. - The CORS settings allow the origin of your external client. - The client provides a valid JWT token if authentication is required. Externalizing the Socket.IO Server Currently, Wasp’s WebSocket server is tightly integrated with its backend. There is no official support for running the Socket.IO server as a standalone/external service. If you want to emit events from outside the webSocketFn, the current workaround is to export the io instance from your webSocketFn and import it elsewhere in your backend code.
Workaround for Accessing io If you want to fully externalize the WebSocket server (e.g., run it as a separate service or use a different backend), you would need to implement your own WebSocket system outside of Wasp’s abstractions. Wasp’s built-in tooling is not designed for this use case, and you would lose the automatic integration with Wasp’s auth and context. Summary - Wasp’s WebSocket system is designed for tight integration between client and server, with built-in auth and context. - You can connect external clients if you handle CORS and authentication. - To fully externalize the WebSocket server, you would need to implement your own system, as Wasp does not currently support this natively. - For advanced use cases, exporting the io instance is the recommended workaround for now. If you need more flexibility, consider building your own WebSocket server and connecting it to your Wasp app as needed, but be aware this will require more manual setup and integration work. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @gabriel, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Vinny (@Wasp)•3mo ago

Hey @gabriel did the bot answer your question? I'm ccing @miho here since he is our websockets expert.

gabrielOP•3mo ago

Thx, the bot didn't help me😅 but i think i might need external service to manage this at scale😅

Gaming

Programming

How to externalize the socket.io server?

Did you find this page helpful?