Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/danekf/web-socket-exploration

Self guided exploration and writeup about web sockets. Explanation, use and examples
https://github.com/danekf/web-socket-exploration

http nodejs ruby websocket

Last synced: 5 days ago
JSON representation

Self guided exploration and writeup about web sockets. Explanation, use and examples

Awesome Lists containing this project

README 

        


Web Sockets, a mystery to be solved.








As developers, we need to remain aware of the use cases and limitations of the communication protocols we interact with. Each protocol will have its own pros/cons. Differences include, but are not limited to, how a protocol handles encoding, confirmation of receipt, error handling, flow control, queuing, etc...



As web developers we deal mostly with the client-server model and are familiar with the HTTP protocol. However there is another option for protocol that is favoured when a site requires specific features that use real time data, such as live chats or data for a multiplayer game. That protocol is called Web Socket.



This repository aims to explore web sockets on a high level through explanation and demonstration.







  Table of Contents

    



(back to top)






## What is the client/server model

Prior to diving into Web Socket, it is important to briefly go over how a client/server model functions on a high level.


In this model, data is stored and managed by a server. This data could be login information,a database of products, a database of client information, web pages, or any other information that someone might want to access.


The client is the end user who wants to access or modify this data.






In order to use that data the client will make a request to the server, and the server will respond with the formatted data. The major difference between an HTTP request and a web socket is with how this communication is established and maintained.



(back to top)






## How does an HTTP request function

An HTTP request functions as a SINGLE interaction between a client and a server. The client reaches out to the server and will ask for data to be given to it (a GET request) or to modify data on the server with supplied information (a PUT request). Once the response is sent from the server, and the client has confirmed receipt the connection is closed.(The connection will also close if the client has not confirmed receipt of data within a configured amount of time, this would be a timeout condition.)



Below is an example of a request from a client using axios, which is a module to simplify requests for JavaScript.



```sh

#This example shows how axios can be used to make a request to a website in JavaScript

const axios = require('axios');



const getThisRepo = () =>{

  axios

    .get('https://github.com/danekf/web-socket-exploration#What%20is%20a%20web%20socket?')

    .then(response => {

      #Do something is a placeholder function to show where axios could do something with the received response.

      doSomething(response);

    })

}

```



This example illustrates one way the browser would have reached out to a DNS (Domain Name System) provider to receive THIS github repository. The client formulates a '.get' request and 'then' waits for the response from the server. Once a response is received, the connection is closed and then "doesSomething" with the response. 



Alternatively we could make a request using the command line action "CURL". In this example we would get the raw data required to render and run the webpage. This can be run in any modern terminal. 





```

curl https://github.com/danekf/web-socket-exploration#What%20is%20a%20web%20socket?

```



In either case, this example demonstrates that a request is made, the server processes the request and then sends the data to the client. At this point the connection is closed. In order for the client to receive more data the client must make a new request to the server.


The image below, taken from betterprogramming, illustrates this interaction clearly.



  

    

    




Unfortunately this method of data transfer has its limitations. suppose we wanted to start a chat on a webpage. How would we handle this? We might need a client to check at intervals for new data, but deciding on this interval would end up being complex. We do not want to need to establish a brand new connection every time we need to get or send data. 


What if we looked at a more complex situation such as an online multiplayer game where data needs to be sent and received very quickly. Making multiple requests, and closing them each time would be much too intensive and introduce issues where data is not received in time.


It would be ideal to have the client and server remain connected until the interaction reaches its conclusion, regardless of how long that may take. This is the issue that web socket attempts to solve.



(back to top)
  





## What is a web socket

A web socket is a protocol used in the client/server model, much like HTTP, but is a continuous communication between the client and the server. The request begins in a similar way to an HTTP request but the requested address starts with 'ws:' rather than 'http:'. However the protocol is what is defined as a 'framed' protocol. This means that each time data is sent between the client and the server it follows a standard format, with regulated size and use for each 'chunk' of that data. One such example of the standard is the RFC6455 framing protocol,  which this article covers in great technical detail.



Once the server receives the request, instead of returning an HTTP response, it will return a 'handshake'. This confirms to the client that the request was received and sends the data required to complete the connection.



At this point, the client and server will remain in constant communication until either one chooses to terminate the connection (or the connection is lost). 



Here is an example image, taken from geeksforgeeks.org which illustrates this clearly.




    

      

  



Once the communication is established, both the client and the server can send data to each other in a full duplex manner. This means that they are both able to send data at any point, including when data is being sent by the other. This is a much more ideal protocol for examples such as a live chat, or for an online game since both parties are actively listening at all times.





(back to top)









## A Deeper Dive

Now that we have an understanding of what a websocket is, and WHY it exists. The next step is to run through an example of a simple web socket server/client.


The chosen example will use NodeJs and the websocket npm package to create a simple websocket server and client to show the simplicity of establishing a connection.


Click here to explore my solution



(back to top)






## Managed Solution VS Self Hosted Server

When looking at implementing a web socket, on of the final questions to ask ourselves is whether to self host a solution or use a third party managed solution.


For self hosting, popular servers include FAYE for Ruby or websocket in NodeJS (as seen with the Deeper Dive example). A self hosted solution, while the most complex solution, is the most flexible. You are able to tailor each step of the process yourself and optimize yourself.


While it is easy to setup a simple web socket server and client, it may be of interest to leverage a managed solution.



A managed solution, such as Pusher offers pre-built solutions to lower development time and allows your team to focus on what you want your application to achieve, rather than implementing the web socket. They also have the ability to scale solutions easily as your application use grows, once again lowering the development burden. For a smaller team this is a very attractive prospect and is well worth considering when you want to focus your team's attention on other features. A pre-built solution also allows for easier addition of realtime data later into development, when a smaller subset of realtime features is required.


(back to top)






## Final Thoughts

While web socket is very flexible and useful when sending data, it is more complex to setup and its power might not be worth the extra development time for simple requests. A best practice would be to set out your requirements, if your application requires frequent back and forth data, such as realtime updates, then consider a web socket for that element.



Otherwise it would seem best to implement a more simple HTTP request. Should the need arise to get some real time data, it is possible to implement at a later date, whether it is a custom solution or a third party one. 


(back to top)






## References :

    

  • 

  • 

  • https://www.wallarm.com/what/a-simple-explanation-of-what-a-websocket-is
    • 

  • https://betterprogramming.pub/sending-type-safe-http-requests-with-go-eb5bd1f91558
    • 

  • https://www.geeksforgeeks.org/what-is-web-socket-and-how-it-is-different-from-the-http/
    • 

  • https://pusher.com/tutorials/build-a-realtime-stock-ticker-with-ruby-and-pusher-channels/
    • 

  • https://sookocheff.com/post/networking/how-do-websockets-work/
    • 

  • https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
    •