T
tRPC

❓-help

Why do people use SplitLink? (http + websocket)

BBen-xD12/20/2023
Why not just use websockets for everything? Just curious.
BBeBoRE12/20/2023
HTTP APIs are easier to scale and often less resource intensive. Most use cases don’t need long running connections.
BBen-xD12/21/2023
It's an interesting point on using resources - though that should definitely be measured (since you're saying use both HTTP + WS, not just WS, or just HTTP). Websocket messages are more efficient than http requests, which send the headers on every request, including possibly a large JWT. It can also require establishing a new connection and handshake with the server. I've seen benchmarks from websocket backends (centrifugo) that mention 500mb of memory for 10k websocket clients - we already need to pay this cost because we're using websockets. For an app that already uses websockets for subscriptions, I don't see the value of also using HTTP, I really value the consistency of using websockets for everything - it simplifies authentication as well. Note: my tRPC APIs still do support HTTP because I use trpc-panel, which uses HTTP (it also doesn't support subscriptions). I just currently use wsLink on the client/browser, not splitLink. I'm still genuinely curious if I'm missing something. Is that performance impact obvious that we don't need to measure? or have you already measured it? I really wonder why go for the split link
BBen-xD12/21/2023
Ahh, just found this interesting post: https://stackoverflow.com/a/29933428/7365866
Stack Overflow
What are the pitfalls of using Websockets in place of RESTful HTTP?
I am currently working on a project that requires the client requesting a big job and sending it to the server. Then the server divides up the job and responds with an array of urls for the client to
BBen-xD12/21/2023
Ahh, I guess you do lose caching

Looking for more? Join the community!