Websockets in Remix #992
-
Hey, Is it possible to setup web sockets in Remix on an action function? Anyone who has an example? I saw this example where they use express to setup sockets: https://blog.logrocket.com/how-to-implement-websockets-in-react-native/ |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 1 reply
-
If I am not wrong, there are different ways to deploy Remix, you can either deploy to serverless platforms (Vercel, AWS via Architect, Cloudflare Workers) or deploy an entire server, either using Remix server or Express server. You could try choosing Express when you create your Remix app and add a WebSocket route there. |
Beta Was this translation helpful? Give feedback.
-
You can do that if you use the Express adapter, also check #389 where we discussed some ideas about adding built in support for WS. |
Beta Was this translation helpful? Give feedback.
-
An example is available at https://github.com/remix-run/remix/tree/main/examples/socket.io |
Beta Was this translation helpful? Give feedback.
-
I think a way which Remix could just punt on Websockets support is by supporting client-only routes and state management. I'm new to Remix, so LMK if this is already supported, but here's my thinking. WS ServersFor WS servers, we should be using hosted solutions anyway. AWS APIGateway (APIG) supports this wonderfully; I also hear chatter of CloudFlare Workers. What APIG does is gives you a WS wss://endpoint clients connect to, which routes $connect $disconnect to a Lambda, for stuffing your connection-ids into a DB (Dynamo, RDS, etc). Then you REST POST to that endpoint to send messages, and it handles maintaining connections and routing messages. Meaning no long-running server (Express), saves money and complexity - and loose coupling for better architecture / scaling. Client-only stateThen, Remix code (only on the browser) could connect to that ws:// endpoint to send/receive messages. Broadcasting to that endpoint is handled via Remix API, or external services (Lambda). But in order too receive the message without Remix caring how things are handled client-server, the client only receives the message (standard react-use-websocket or such). For this to work, we'd need to catch it globally so we're not creating websocket connections per component; then propagate that down to the subcomponents. Ideally using common React global state management like Zustand, Redux, contexts, etc. With client-only global state management like this, we could either populate a component with received data; or just tell the component to refetch from the server, as I've seen discussed elsewhere (the SWR mindset). In which case the Websocket setup wouldn't be sending much data, just sending routes which need refreshing Client-only routes (optional)And ideally (not necessary for the above setup, but just a selfish need), we'd also be able to route parts of the app which don't need server data from Remix; just data sent via Websockets. I imagine this is already possible by just not implementing TL;DRIf Remix allows client-only global state management, we can handle the rest. Just use APIG to manage connections and messaging; push down to client either (a) new data; or (b) routes which need refreshing to fetch new data. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
If I am not wrong, there are different ways to deploy Remix, you can either deploy to serverless platforms (Vercel, AWS via Architect, Cloudflare Workers) or deploy an entire server, either using Remix server or Express server.
You could try choosing Express when you create your Remix app and add a WebSocket route there.