The client and the server communicate many times and in different ways.

The first instance of communication occurs when the code that executes on the client machine has to be sent. We mentioned earlier that one of the advantages of using the web as opposed to native apps is that we would not have to install them all the time. As it turns out, this comes with some trade-offs as well, because every time we visit a website, we have to download all of its layout and code. Most commonly, this is in the form of HTML (for layout), CSS (for style), and JavaScript (for functionality).

The preceding figure shows the simplest models of client-server communication on the web, where the client executes and displays what the server sends it.

One of the steps in the previous figure entails processing and executing the code sent by the server. In richer and more complex applications, the execution of code itself can lead to more requests being made to the server. In our case, we want to display a constantly changing temperature and humidity to the user. It would be quite a poor experience for the user if they had to refresh and download the files all over again just to see the new readings.

One approach we can take to solving this problem is making repeated requests to the server at fixed time intervals in order to get new values. Once we get this information, we can update the UI.

These HTTP requests that are made by the web page itself are called AJAX requests (Asynchronous JavaScript and XML). AJAX requests are different from traditional HTTP requests in that they do not request and load the entire web page all over again. Instead, they only request for the information that is needed. In our case, this is the current information about the temperature and humidity.

One limitation with this process is that it is the browser that has to make a request to the server each time it wants new data. This process of polling is not always efficient because of the following reasons:

• The browser has to constantly request for the new temperature readings at fixed intervals regardless of whether they have actually changed
• Even when the readings have changed, it only update on the frontend as and when the browser polls for new readings again

Both of these problems are solved by making use of a more advanced mode of communication, called web sockets. The main cause of these issues is that the server cannot notify the browser. It can only provide information when the browser requests for it. This restriction is mainly there for security reasons, but it's still a pain to handle when you want true real-time updates. Web sockets provide a solution to this problem by allowing the server to push information to the browser. This is done after the browser and server both establish a socket connection with each other. Instead of the request-response model, the browser and server both create a channel between each other, after which information can be sent across the channel, either from the browser to the server or vice-versa.

Now we have solved both of the limitations we were facing earlier. The trade-off with using web sockets, however, is that they take more resources to manage on the server side, so while it's great to use sockets if you only have a few users, you might want to look at how your application would scale as your user-base grows. Additionally, web sockets are not supported on older and legacy browsers, so only use them if you are sure your user-base has access to newer versions of browsers.

So far, we have discussed three methods of client-server communication:

• Standard HTTP requests
• AJAX requests
• Web sockets

Each method comes with its own pros and cons, and while developing our application, we are going to be making use of all three methods of communication.