So I was reverse proxying this new Social network app's API and saw an interesting endpoint

It was a websocket relaying what each live user's doing every 2.5s, to power the "xyz typing" under a post, or a simple online/idle.
The app's "live posts" ie most-recently created posts was also powered by it since they knew each user's state (instead of a periodic API call)

The performance is good even tho it's a new company + enough users

but now im curious how prevelant state-management is using such websockets .-.

if not taxing, i might move any API call which ive to ping every 15s or less to a live WS

Depends on your application.

It's pretty cheap to keep hundreds or even thousands of open sockets on the server. It's also relatively cheap to send the same content to many sockets at once. But the more 1:1 communication you have (e.g. lots of users using private chat at the same time), the more processing power you need to handle all the simultaneous workload, which can quickly become expensive.

Thats is a function of "online users", and the event propagation in the system.
Let assume that there are 100k total users. Online users with an open socket is 5% of that - for 5k users.
So need to handle 5k sockets - not a big problem.
In addition - not every thing that each of the 5k users does should be sent to all the other users - only his close circle. assume 5 in close circle and online.
So - lets add 1 event per 5sec. generated by 5k users. sent to 5 other users = 5 sec * 6 events * 5k users is 360k websocket events per minute. Can be handled by a small size server cluster, using kafka, redis, or similar.

This will not handle peaks well though, as 15k users will generate 1m events per minute.

@hitko hehh :o I never took sockets seriously for B2C thinking theyd be old and hefty + easy to overwhelm, n at most be used as RPC amongst backend systems

@magicMirror that sounds like a very reasonable number, given if uve 5k active users ud be making more than enough to afford a separate endpoint just for chat and still have profits left

tho im sure it wont be that easy, .NET core will find a way to slow things down n add overheads -.-

that said, last I touched sockets was in C-class during Uni, if c# being a bitch i cud just outsource the socket parts to a c++ dll and do unmanaged calls to it .-. tho thats just assuming that .NET will fuck things up

@azuredivay Back in the day, web servers (especially Apache) would spawn new workers for each open connection, making sockets extremely expensive. Most servers nowadays keep a fixed number of workers which handle requests using a queue, so as long as a socket doesn't do anything, it consumes barely any resources. Beware of that last part though, because when sockets aren't idle, they can easily generate lots of workload.