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
- each of this preview is built on-demand by the backend when the front requests it
- a pool of 8 standard
ajaxrequests are running in queue until all previews are loaded
Let 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 others
- each preview can be built almost instantly by the back-end
- each preview's
base64payload weighs virtually nothing (a few
- establishing an
httpconnection actually takes most of the time
- of course, no more than around 8
ajaxrequests can work concurrently
- if the user leaves to another view while 8 requests are being handled, the browser will wait to have some room in his
ajaxqueue 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 faster
So, my questions are:
could using a
socketdramatically 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
socketbe 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?
EmberJS for the front with
Flask for the back.