I have a requirement where the server has to respond after a huge process time. One way around is server polling, however I wan't to refrain from overburdening the client as well as the server. I am thinking of using websockets for this purpose. If I end up doing so, what would be the best technique and what risks can it bring along?
What do you mean by "risks"? There are no risks if you don't have bugs....
You should make sure that you reconnect the websocket if it disconnects. On reconnect, make sure that the server correctly updates the state or session for the client so that your client receives the result even though there were interruptions. Store the result in the state on the server if the client is not connected and send the result on reconnect.
By the way, there is a difference between JavaScript and Java Script. I think, you meant the former... (or to quote someone's profile message: "Java is the same to JavaScript as car is to carpet"^^)
If the processing job is of a larger scale, perhaps a notification center / job queue listing could be a better combination?
You can give the user a continuous feedback on the processing via web socket messages, there are so many ways to accomplish this kind of functionality, it all depends on what you would like to give back.
If the user is logged in with a session/token you can subscribe the user to a unique room where you send messages directly to this user, on progress or final completion.
What do you mean by safe? Risks? Important for client to get a feedback of the processing? Client may leave the site and come back later, doesn't retrieve the message because it's event based, unless you store the feedback in a queue that is delivered when the user is online and you only remove the message from queue once the client replies with a 'notification-read' message.
Hey Frode,
Thanks, Probably I would end up trying this along with few precautions about the connection mentioned by Marco.
With "Risks" & "Being Safe" I mean to know about common issues(if any) which the community might have already faced and wanted to avoid that.
Regards, Abhik
Mario Giambanco
Director of User Experience Development
IE < 11 is a risk - ie: it's not supported.