Coordinating the response from the server between the front-end and back-end

When developing a site or a web application, which is essentially more complex than a normal landing page, the development team should consist of at least front side and back side. During the work and communication of these two groups, it is very important that there are no disputes between them, but only mutual understanding is present. This article will discuss why this is important, and how it affects the quality of the code on the front-side and the speed of creating the project as a whole.

Why is it important to coordinate the server response format between the front and the back sides?

The importance of this aspect is that at the moment when the backend party gives certain data to the front party, for the latter there are no problems in processing the response from the server, drawing certain elements on the page with the help of this data, and so on. It is clear that the first thing that comes to mind in such moments is that the backend side provides such a response from the server so that the front end developers do not need to somehow modify the received response and carry out some manipulations directly on the front side. For example, even the name of the variable in the response from the server is important, not to mention the nestedness of the data or the format in which the data comes. Therefore, the answer is quite simple in order to reduce the number of manipulations that will be carried out on the front end side with the response from the server.

An example of a consistent format for the select input element

In order to better understand when it is very necessary to coordinate it, I would like to show a real example of such a case. On the page, you need to draw an ordinary select field, which containselements, whichin turn store the value and label. The HTML markup for such an element is quite simple and can be seen below:

<select>
    <option value="" hidden>  Choose option  </option>
    <option value="Some value 1">Some label 1</option>
    <option value="Some value 2">Some label 2</option>
    <option value="Some value 3">Some label 3</option>
</select> 

And for example, the backend returns data for these selects in the following format:

{ selectsValues: [{"value": "Some value 1}, {"value": "Some value 2"}, {"value": "Some value 3,}]} 
{ selectsLabels: [{"label": "Some label 1}, {"value": "Some label 2"}, {"value": "Some label 3,}]} 

However, the user does not need to see the value value in the select ribbon, and it is a bad practice in this case to hang an onClick event handler on each select, which will be triggered every time the user changes the value in the select field, and which will compare the selected value with the required label. This will greatly load our application, making a request to the server every time after changing the data in the select field.

It's all quite simple to draw and create when you know how many options there will be and what their value and label will be, respectively. However, when the response comes from the server, it is necessary to agree on how the back-end should give data to the front-end. The best such solution would be to return an array of objects of the type:

{ selects: [{"value": "Some value 1, "label": "Some label 1"}, {"value": "Some value 2, "label": "Some label 2"}, {"value": "Some value 3, "label": "Some label 3"}]} 

Already with such a response from the server, we can change our previous code to an improved one that will be universal for using data for the select element. So, using the code example below, when changing an option, you can always automatically track both the value of this option and its label, which is very convenient:

<select>
    <option value="" hidden> Choose option </option>
    {selects?.map((item, i) => (
        <option key={i} value={item.value}>
            {item.label}
        </option>
    ))}
</select>

It is not difficult to understand, after comparing the results, how much better the second approach looks, and how much easier it is to understand and maintain in the future, regardless of how the project the developers are working on may expand. In conclusion, I would like to say that before creating various elements on the page that depend on the work of the server side, it is always necessary to agree on the format of the data that will be returned to the frontend, because, as we have already defined in this article, it is possible to distinguish such advantages of this approach:

1. It can save development time for both the back-end side and the front-end side
2. This reduces the efforts of the interface developers to process such data.
3. In the future, such code is easier to maintain and understand
4. The code looks cleaner.