For scenarios requiring a constant exchange of information, such as streaming data or real-time updates. After the initial handshake, data is exchanged directly over the connection with minimal overhead.
Lower latency is especially beneficial for high-frequency message exchanges. Gaming, live auctions, or real-time dashboards are well suited. I also think that real time collaboration is under-explored.
JSON-RPC is request-response only; the server cannot send unsolicited messages. gRPC supports bidirectional streaming, but I understand that setting it up is more complex than WebSockets.
I will concede that horizontal scaling of RPC is easier because there's no connection overhead.
Ultimately, it really depends on what you're trying to build. I also don't underestimate the cultural aspect; fair or not, JSON-RPC feels very "enterprise microservices" to me. If you think in schemas, RPC might be a good fit.
Why can't the server send unsolicited messages in JSON-RPC?
I've implemented bidirectional JSON-RPC in multiple projects and things work just fine, even going as far as sharing most of the code.
Yep, the web server and client can both act as JSON-RPC servers and clients. I've used this pattern before too with Web Workers, where the main thread acts as both client (sending requests to the worker) and server (fielding requests from the worker).
> WebSocket connections can be unexpectedly blocked, especially on restrictive public networks.
What? How would public network even know you’re running a websocket if you’re using TLS? I dont think it’s really possible in general case
> Since SSE is HTTP-based, it's much less likely to be blocked, providing a reliable alternative in restricted environments.
And websockets are not http-based?
What article describes as challenges seems like very pedestrian things that any rpc-based backend needs to solve.
The real reason websockets are hard to scale is because they pin state to a particular backend replica so if the whole bunch of them disconnect at scale the system might run out of resources trying to re-load all that state
I agree here. I have had an experience of scaling WebSockets server to 20M connections on a single server (with this one https://github.com/ITpC/LAppS.git). However there are several issues with scaling WebSockets, on the backends as well: mutex locking, non-parallel XOR of input stream, utf8 validation.
I do not know the state of the above repository code, it seems that it was never updated for at least 5 years. There were bugs in HTTP parsing in the client part for some cases. Though vertical scalability was excellent. Sad this thing never reached production state.
I remember this one in particular making me upset, simply because of another extra buffer pass for security reasons that I believe are only to prevent proxies doing shit they never should have done in the first place?
It's not a very good man-in-the-middle if it can't handle a ubiquitous protocol from 2011 based on http/1.1. More like an incompetent bureaucrat in the middle.
Eh, if you're dealing with corporate network proxies all bets are already off. They keep blocking connections for the most random reasons until everyone is opening ssh tunnels just to get work done. Websockets are a standard feature of the web, if you cut off your ears don't complain about loss of hearing. Unless, you're explicitly targeting such corporations as clients, in which case - my condolences.
Im old enough to have worked with asn.1 and its various proprietary “improvements” as well as SOAP/wsdl and compared to that working with protobuf/stubby (internal google predecessor to grpc) was the best thing since sliced bread
Great many folks are completely ineffective in remote setting. Some are not but many are. Simple as that. No real estate mogul conspiracy theories necessary
Are there studies to this effect? Any empirical evidence companies can give plotting productivity decline and subsequent increase after RTO? Or is it all just vibes?
How would you even do a study like that? Besides, looking at scientific studies is not how businesses make decisions. They sometimes use studies as justification but there's a difference.
> SpaceX can provide unique interfaces for Payloads with mechanical interfaces other than 8", 15", or 24". The Sales team will contact you with pricing if you select this optional service.
Weird reaction to say the least assuming you were happy with the product. I've been on calls where the vendor is already on thin ice because the product doesn't work and we're just making sure they are taking us seriously, where AE knuckleheads try to use that as an opportunity to upsell a higher tier of support or something. That's annoying and ime never goes well.
Offering an annual contract though, which presumably comes with a volume discount is a totally normal practice that should benefit both parties assuming it's executed well.
> That last point is especially funny considering how startups lie, too, like having a landing page and no product but collecting emails like you do.
How dare companies do market research with potential buyers to know what to build before they start building it! If only we could setup massive factories that pump out hot garbage that nobody wants and build roads to nowhere like the soviets did.
