Why do people use SplitLink? (http + websocket)
Why not just use websockets for everything? Just curious.
4 Replies
HTTP APIs are easier to scale and often less resource intensive. Most use cases don’t need long running connections.
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
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
Ahh, I guess you do lose caching