Do front-end or back-end processing?

Asked

Viewed 975 times

8

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

On the one hand, processing on the client-side can be beneficial for server-side performance, which takes care of delivering the resource so that it is consumed, formatted and perhaps processed on the front end.

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

Contextualizing in REST

In the principles of REST architecture, the back end is responsible for the delivery of 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, the person responsible for this calculation would be the front-end or back-end?

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

  • Interestingly, until a few years ago, information processing was done almost exclusively on the server, as it was difficult for the client to have a machine that could handle the work well. Today we are already in a different reality: even smartphones have the capacity to perform heavy functions, which allows us to pass on much of the responsibility to the client, saving server resources and reducing the cost of the project (#Usetheplatform).

  • I don’t have a complete answer, but one argument to favor server-side Remattering is that search engines will only be able to index your site right if the information is already in HTML.

  • Interesting your question, @Pedro. Today there is the pre-render of pages, very useful for indexing Single-page Applications. This is the great difficulty for Spas in general.

  • What’s available on the client’s side :) And maybe that’s the answer, except I didn’t understand the question

  • 2

    I believe that in general the more on the client side the better, but there are cases where this can change, if your application is focused on users who do not have very powerful machines, a tool to be used with heavy applications or you are making an internal system for a sustainable company that still uses windows Xp

  • I agree with @Guilherme, I think that the level of responsibility regarding processing on the client side depends a lot on the business and the type of application you want to develop. If your system is serving supermarket computers that still have Windows 95, it is good to take the responsibility of processing data from these guys.

Show 1 more comment

1 answer

2

It depends a lot on what the application is proposed, but considering a web-based system where indexing by search engines is basically irrelevant (since it’s 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 mounting dynamic views.
  • In the views, I don’t use loops or back-end 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 has some impacts, such as:

  • The server does not need to process things extra, relieving processes (it seems not, but in generations of reports this can be a differential).
  • The data that moves 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 on the screen, there is a performance gain if the guy’s internet doesn’t help much.
  • As I assemble everything in the customer, I can give a better feedback of the processes that are taking place in the customer. For example: the client asks me for a report, I make a request in the back end 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 the performance on the client’s side, when his machine is not good for processing a lot of information and causes a slowness. But in this case it would be necessary to analyze how many customers this occurs, if it really is a big impact, how often this customer has this problem and etc.

I’ve been using this strategy for a few years and have already implemented it in a vehicle tracking company, where the 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, allowing parallel processes to run faster, and customers had better feedback than what was happening on the screen.

  • As for this feedback, I believe it would make no difference between waiting 1s for the server and 1s for the machine or 2s for the server (in most cases), in some cases it is possible to show small parts of these reports (or any other data), which would be interesting, the customer looks at one part and when he finishes the next part will be ready

Browser other questions tagged

You are not signed in. Login or sign up in order to post.