Can I connect to a regular node express with socket.io?
My idea is that I will host the socketio nodejs server in some server, and then use it with my nextjs project, the problem is that I'm not sure if that is capable with TRPC.
Where would I interact with the socket? It cannot be through procedures ( I'm assuming ).
How would I maintain the open connections, if not instanciating through the createTRPCNext function?
I know about the whole https://github.com/trpc/trpc/tree/main/examples/next-prisma-websockets-starter shenanigans, and I tried that way first, but I'm deploying to vercel right now, and as I understood, this would be a blocker and I would need to host the websocket server in another place either way, on the example case, render.com
There should be docs explaining that when you RUN that project, you're actually starting a node server on one port with a regular
The architecture in that case just provides the type safety solution and allows you to interact with the socket through the procedures. Again, if I'm using another service either way hosted somewhere else, having WAY less boilerplate config code in the tradeoff for the typesafety seems not worth it.
Plust the whole configuration process took close to 2 days of work and I've still not figured it out, btw if anyone wants to help on that would be a solution too.
Where would I interact with the socket? It cannot be through procedures ( I'm assuming ).
How would I maintain the open connections, if not instanciating through the createTRPCNext function?
I know about the whole https://github.com/trpc/trpc/tree/main/examples/next-prisma-websockets-starter shenanigans, and I tried that way first, but I'm deploying to vercel right now, and as I understood, this would be a blocker and I would need to host the websocket server in another place either way, on the example case, render.com
There should be docs explaining that when you RUN that project, you're actually starting a node server on one port with a regular
node run xxxThe architecture in that case just provides the type safety solution and allows you to interact with the socket through the procedures. Again, if I'm using another service either way hosted somewhere else, having WAY less boilerplate config code in the tradeoff for the typesafety seems not worth it.
Plust the whole configuration process took close to 2 days of work and I've still not figured it out, btw if anyone wants to help on that would be a solution too.
