How can we remove business logic from the frontend for complex, highly interactive UI's? Should business logic always live exclusively on the backend?

Question

I have a UI for a tool with a fair amount of user interaction.

Imagine a sports tournament predictor where you select which team will finish 1st in the group, 2nd in the group etc., with the winners of each group progressing to the quarter finals and so on. The user's task is to predict who finishes where. The user can select to add teams to the group and then re-order them within the group afterwards.

The business rules for determining which teams from each group progress to the final is actually quite complex. We ideally want this logic to live only on the backend, within our domain model.

The problem is that, with 36 teams, the game will have users making changes to the UI very often and the UI must remain responsive. If the business rules for determining who wins are implemented on the frontend this is fine - after all, all that matters is the user's predictions - but if we don't want that we'll have to implement this with API calls.

There are two possibilities that I see:

Option 1:

Every time the user adds a team to a group, re-orders a group or selects a quaterfinal / semifinal / final winner, we make an API call. Since there are 36 teams in the tournament, they will be doing this a lot. The API call sends the users selections to the backend, which determines group winners etc., and that data is returned and rendered on the frontend. We could try to do this in a non-blocking way, with clever delays and batching to reduce the number of API calls, but it would still result in dozens of calls for each user and the user having to wait for the backend to respond at times.

Option 2:

We either duplicate the business logic on the frontend or we have the business logic only in the frontend, in which case the backend becomes a fairly dumb data store. This means we have frontend domain models. THis might work in this particular use case where we always trust user data, but in my head I am wondering about future projects where we don't trust user data and we have to have the business logic implemented on the backend.

Which is preferable?

Answer 1

Duplicate the logic.

Basically you always have two problems.

1. Ensure all business rules are always followed. (backend)
2. create a UI which makes it easy to follow the business rules. (front end)

You might be able to create a simple UI which by its very nature follows the business rules without knowing them, for example if you are dragging and dropping teams then the user will never be able to use the same team twice. You dont need to explicitly state the rule.

However, with more complicated rules, say, I don't know, you have to work out that the selected loser is only valid for certain picks in some group, Then replicating the logic in the UI is the way to go.

For rules where a large amount of data is required, say, calculate the price offered on the bet based on the latest odds, customer special offers and don't show any numbers that will change on submission. Then the backend is the right place, because you need the latest data, it has to match the backend calc etc etc that cant be done on the front end.

Some rules might be edge cases where you are happy to simply present the user with an error on submission. Say, if the match ends before you submit. In these cases you can just omit the logic from the front end.

So the Presentation layer doesn't have to duplicate the Business Logic. It has to create Presentation Logic which allows the user to comply with the business logic.