> The "refresh causes load" issue can be solved by doing long-polling instead of short-polling.

...and now you have to greatly scale up your backend infrastructure to be able to handle all those open connections to handle each and every single active user.

▲

o11c 2 days ago | parent [-]

With any decent backend implementation, idle connections should be really cheap - measured in individual pages, and the hard part is figuring out how to count the kernel side.

▲

motorest 2 days ago | parent [-]

> With any decent backend implementation, idle connections should be really cheap (...)

Not exactly. With sync calls each server instance can handle only a few hundred connections. With async calls each instance can in theory handle tens of thousands of concurrent requests but each polling response van easily spike CPU and network loads. This means your "it works on my machine" implementation barely registers any load whereas once it enters operation your dashboards start to look very funny and unpredictable, and your scaling needs become far greater just to be able to gracefully handle those spikes. This is a radical departure from classic request-and-response patterns where load is more predictable.

	▲	nasretdinov 2 days ago \| parent [-]
		With long polling you don't have the application logoc handle the waiting part — that would be too expensive. You typically have a separate service that holds the open connections until notified to then call the actual backend