2

I'm teaching myself about Mojolicious and websockets. So far I've got a web page that displays rows from a database, and has buttons to add, delete, and update rows, and to select columns for sorting.

At the moment, it uses 'one-shot' websockets in the javascript 'onclick' handlers for each button, and that works.

Would it be more in-keeping with the intention of websockets, for the sockets to be kept alive and used for multiple clicks? I think the answer should be 'yes', because otherwise it will get messy if the user clicks a button several times quickly.

And, as a question of style, should I just have one websocket that handles different types of interaction between browser and server, or separate websockets for each type? Having one websocket would require code to analyse the messages and decide what to do about them. Whereas several websockets would each be simpler, but that would require repetition of error-handling code etc.

I know that's a wordy and philosophical question, but I want to get overall shape of the application right before I develop it further.

Chris Dennis
  • 995
  • 7
  • 16

2 Answers2

3

An Ajax call is an efficient way for a client to request some specific information from a server in a one-shot type of approach.

A webSocket is best for a situation where you're doing rapid fire communication from client to server (so many requests that you benefit from a persistent connection) or when you want the server to be able to send data to the client at will (since you have to have a persistent connection to send data from server directly to client).

Using a one-shot webSocket (where you create the webSocket, use it and then close it) for an occasional request of data from client to server is not the most optimal way to do things because there is additional overhead to setting up the webSocket that is not present in the ajax call as the two ends negotiate whether both sides support webSockets and agree to change the protocol from http to webSocket.

A one-shot webSocket connection would look like this:

  1. client establishes TCP socket to server
  2. client sends initial HTTP request with webSocket upgrade headers
  3. server responds that it is OK to upgrade to webSocket protocol
  4. client sends message
  5. server receives message and sends response
  6. client receives response
  7. client closes TCP connection

An Ajax call would look like this:

  1. client establishes TCP socket to server
  2. client sends HTTP request to server
  3. server receives request and sends response
  4. client receives response
  5. client closes connection

And, when coding in the browser, the Ajax call is automatically closed (since it is designed for one-shot requests) so the client doesn't even have to code that last step.

So, if you're just requesting some information from the server upon an end-user click, then it seems likely that an Ajax call is a more efficient approach (and simpler to implement).

jfriend00
  • 683,504
  • 96
  • 985
  • 979
1

Having read around the subject a bit more, and toyed with the code, I conclude the following:

  1. It depends what you're trying to do. As ever.
  2. Ajax is probably good for one-shot messages, as jfriend00 says.
  3. For my needs, it's going to be better to use a single persistent websocket. It cuts down on code repetition, but means I'll have to invent a simple command/response sequence of my own for dealing with the messages.

To make sure the websocket stays open, I've adapted John Henry's idea.

Community
  • 1
  • 1
Chris Dennis
  • 995
  • 7
  • 16