We have a web application which currently operates like this on a typical view/page:the front has to display 100+ previews (in the form of base64 images)each of this preview is built on-demand by the backend when the front requests ita pool of 8 standard ajax requests are running in queue until all previews are loadedLet me illustrate this with a picture:Sometimes the user does something that modifies some of the previews and those (and only those) have to be requested again by the front. In this case it goes like this:At this moment, waiting for 100+ previews to load initially can take a long time (between 30 and 50 seconds), which is very annoying.Before coming to the actual question, let me state a few points:each preview is totally independent from the otherseach preview can be built almost instantly by the back-endeach preview's base64 payload weighs virtually nothing (a few kb)establishing an http connection actually takes most of the timeof course, no more than around 8 ajax requests can work concurrentlyif the user leaves to another view while 8 requests are being handled, the browser will wait to have some room in his ajax queue before loading elements from the new view, which is very annoying (the new view can remain empty for many seconds before something happens)we can't bulk all the previews in one big request because sometimes (and it's not predictable), it happens that a particular preview takes a lot of time (several seconds) to built, and we don't want to penalize the other previews which could be loaded much fasterSo, my questions are:could using a socket dramatically improve connection time so that the app is much more responsive at initial loading and in case of modifications in previews?could messages exchanged in this socket be asynchronous so that if we ask for 100+ previews at the same time, they will all be loaded very quickly? And if so, is there a maximum number of concurrent messages in the socket?can all the concurrent messages for which the front is currently waiting for, be instantly dropped if the user exits this view to visit another one? or does it even matter if there are virtually no concurrent messages limit?We're using EmberJS for the front with EmberData and Flask for the back.
Asynchronous socket.io for lots of concurrent messages
concurrency;async;websockets;ember.js