Why do people use SplitLink? (http + websocket)

Why not just use websockets for everything? Just curious.
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

Looking for more? Join the community!