Do processing on the front-end or the back-end?

Question

Do processing on the front-end or the back-end?

Navigation

#1 by (2 votes)

7

In the client-side and server-side separation architecture, it is common to doubt who is responsible for doing some processing.

On the one hand, processing on the client-side can be beneficial to server-side performance, which will deliver the resource to be consumed, formatted and perhaps rendered on the front end.

On the other hand, the server-side. Placing server-side processing has the advantage of scaling and relying on features managed by the organization itself.

Contextualizing in REST

At the beginning of the REST architecture, the backend is responsible for delivering the resource, for example:

GET vnb.rs/api/produtos/1
{
  "nome": "Caneca",
  "variações": [
    {
      "cor": "azul",
      "preço": 15.00
    },
    {
      "cor": "vermelha",
      "preço": 18.00
    }
  ]
}

If I needed the minimum and maximum value of the variations (from 15.00 to 18.00 reais) of this mug, would it be the front-end or the back-end?

What defines what kind of data can be processed on the client side?

single-page-application lado-do-servidor lado-do-cliente

asked by anonymous 20.04.2018 / 23:25

1 answer

How to make Visual Studio recognize the 'use strict' directive? How to export an HTML / C # (Razor) page containing SVG elements for PDF?

score 2 · Answer 1

It depends a lot on what the application proposes, but considering a web-based system where search engine indexing is basically irrelevant (since it is a system and not a website), I use the following strategy:

The back end is only responsible for responding to requests with pure data (in json, for example) and performing what the back end always does (validations, processes, data manipulation). That is, it avoids putting up dynamic views.
In views, I do not use loops or backend conditions, I send the basics (an html with a script call inside) and leave it to be mounted by my javascript framework on the client side.

This strategy causes some impacts, such as:

The server does not have to process things over, easing the processes (it seems that not, but in generations of reports this can be a differential).
The data that travels between server and client is just pure data, no tags and information that can be built into the client. Imagine a screen with 1000 records, going back a thousand "tr's" and "td's" instead of just returning the data string and mounting the screen, there is a performance gain if the guy's internet does not help much.
As I put everything into the client, I can give better feedback on the processes that are occurring on the client. For example: the client asks me for a report, I make a request on the backend and then I can inform that I am collecting the information, when it arrives I can inform that I am processing the information.

What can impact is to perform on the client side, when the machine is not good for processing too much information and slows down. But in this case it would be necessary to analyze how many clients this occurs, if it really is a big impact, how often this client has this problem and so on.

I've been using this strategy for a few years now and have already implemented it in a vehicle tracking company, where reports were gigantic. I can tell you that I got great feedback from both the clients and the board. Since the server was relieved to mount views, letting parallel processes run faster, and customers got better feedback than what was happening on the screen.