architectural question. Can a client have business logic?

Question

Software design

architectural question. Can a client have business logic?
It just seems to me that now they have begun to get confused in the definitions of a thick and thin client.
If the SPA application receives objects from the back-end and, according to them, follows the rules, the principles of a particular business allow you to send ready-made JSON to the back-end for saving, where the back-end checks the relevance of the data, repeats the business logic. Can a SPA application be called a thin client?

Answer 1

There is no confusion, the problem is that in some cases the clients have become so thick that the entire database is actually pumped out to the client, then it is synchronized according to cunning logic. As a result, with complex calculations, it all barely moves on the client, because on the client it will not work to buy another RAM stick or add a rack. Therefore, the trend for thin clients has gone. Spa can be either thick, when everything is downloaded from the server, all this can work offline, when the Internet is synchronized, or thin, when data is simply received and displayed, and the server is responsible for everything more complicated than 2 + 2. But there is no way to make a big application thick spa, you can make an application on electron thick.
The client can have logic within its interactivity, that is, if goods are added to the cart, then it makes no sense to make a separate request and calculate the amount on the server (provided that, for example, there is no discount that depends on the entire history of the user's orders in recent years and there is no task to ensure consistency on all devices where the user is logged in and could make orders in parallel, etc.). But only the backend can be responsible for generating an invoice with a total amount.

Answer 2

In short: Yes.
Longer:
People have always been confused in definitions and will be confused. Yes, and it is difficult to somehow take a definition that was made a long time ago for some technologies and architectures and pull on modern, other realities. Of course, you can also put a hedgehog on a cactus, but it is better to spend these efforts on something more useful.
Even the term SPA application is no longer so relevant and does not fit so well with what is being written now.
Call the client a client, the server a server, and that will suffice. Although of course at a nerd party in a buzzword contest you might lose if that's important to you.

Answer 3

In the general case, it can and even should, so that the client does not slow down the application after each button. But business logic on the client should only be allowed within the framework of client trust. That is, the backend sends data and conditionally ready-made formulas to the client, and he plays with them further for his pleasure. But when the user wants to fix the result in the database on the back, here again you need to check that the user has not cheated anything, has not made a mistake and is not a hacker.
You can call it a thin client. But it depends on how much logic is rendered to the client. If there are many, then this is no longer a thin client. For example, a shooter-type game is the main logic on the server, but decent calculations on the client as well.