My team is developing a WEB based finance application and there was a bit of an argument with a colleague where to keep the calculations - purely in back-end or keep some in front-end too?

Brief explanation:
We are using Java (ZK, Spring) for front-end and Progress 4gl for back-end. Calculations that involve some hardcore math & data from database are kept in back-end, so I'm not talking about them. I'm talking about the situation where the user enters value X, it is then added to the value Y (shown in screen) and the result is shown in the field Z. Pure and simple jQuery-ish operations, I mean.

So what would be the best practice here:

1) Add values with JavaScript that saves from going to the back-end and back and then validate them at the back-end "on save"?

2) Keep all the business logic in the same place - therefore bring the values to the back-end and do the calculations there?

3) Do the calculations in the front-end; then send data to the back-end, validate them there, do the calculations again and only if the results are valid and equal, display them to the user?

4) Something else?

Note: We do some basic validation in Java but most of it is still in the back-end as all the other business logic.

Increase of data that would be sent by recalculating everything in a back-end wouldn't be a problem (small XML size; servers and bandwidth would withstand the increased amount of operations done by users).

Rule of thumb: when it uses a strongly-typed language.
–
DenAug 4 '14 at 12:43

1

Automated Unit Testing will be easier if all logic is in the back end. If 90% has to be the back end and 10% can be in the back-end, then I would put 100% in the back end.
–
IanAug 4 '14 at 14:23

3

@Ian: you can do automated unit testing for front end codes as well if you structure your code well.
–
Lie RyanAug 4 '14 at 15:30

1

Rule of thumb: Whenever you can get away with it.
–
goldilocksAug 4 '14 at 19:38

1

Rule of thumb: assume the user is hacking your JavaScript and doing their own calculations. From a security standpoint, the calculations have to be done on the back-end. You can do both, too: JS can provide quicker feedback, but the calculations that actually count are done on the server.
–
SnowmanAug 4 '14 at 21:58

2 Answers
2

As always, such decisions involve a trade-off between different goals, some of which conflict with each other.

Efficiency would suggest that you perform calculations in the front-end - both because that way the user's computer uses more power and your server uses less, and because the user sees faster feedback, which improves the user experience.

Security demands that any state-changing operations cannot rely on data being checked or computed in the client computer, because the client computer may be under the control of a malicious attacker. Therefore, you must validate anything that comes from untrusted sources server-side.

Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort.

Superficially this sounds as if everything has to be done server-side, but that isn't always the case. If you can easily maintain the duplicated code (e.g. by auto-generating a javascript validator from your server-side Java validator), then repeating the computation can be a good solution. If the data involved are all unimportant, e.g. if the user could cheat only themselves and not you if they manipulate values, then server-side validation isn't necessary. If your response time is dominated by completely different bottlenecks so that a round-trip delay is not perceptible, then UX considerations aren't decisive, etc. Therefore you have to consider how strong each of these pressures is in your situation, and decide accordingly.

I would want to add that Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort. is not correct because [1] Validation in front-end can provide quick feedback to user to make corrections if needed. [2] Validation in back-end is not as responsive, and thus does not the provide the user the best opportunity to make corrections. User would need to wait and redo more work. So I think the two validations are not exactly the same.
–
InstructedAAug 4 '14 at 12:34

7

That's not what I wanted to get across - maintainability does imply "don't repeat yourself", and according to this principle the repetition is certainly bad. If there were no other considerations, you shouldn't do it. The fact that it's nevertheless often a good idea is because there are other considerations which contradict this principle, i.e. better usability through quick turnaround.
–
Kilian FothAug 4 '14 at 12:41

@randomA You are misapplying that principle, if you mean that something that needs to be validated on the server should only be calculated on the server, because if the "server validated value" (or anything dependent on it) returned to the client is then at some point sent back to the server, you have to validate it again anyway -- useless. Or else you need some system of secure references, which may be yet more inefficient. I'd say if you can do a calculation on the client, do it on the client, but also never trust what the client tells you.
–
goldilocksAug 4 '14 at 19:34

@goldilocks What you said in bold is also what I agree too, you have to validate everything on the back-end. My point was that: validation on front-end is more responsive, so not entirely the same as validation on back-end.
–
InstructedAAug 5 '14 at 4:39

You assume there's a one-front-end -> one-back-end relationship which is not always true, back-ends should be thought of as being capable or serving more than one front-end application, thus you cannot assume anything.

If calculations use a big ammount of data, it would'nt be efficient to hold it in the front-end

If calculations uses the database, you will not be able to replicate in the front end

My recommendation

Have the database enforce as much business rules as posible in the model, including foreign keys, primary keys, check constraints and triggers

Have the business layer throw exceptions when business rules are not met (either because the database returned an error or because the business layer itself validated the data )

If and only if response time is unacceptable, do validations or preprocessing using Ajax ( the work will not be really done in JavaScript, it will be done in the backend without having to reload the page )

You can do simple validation in JavaScript like not allowing an empty value, or values that are too long, or out of range (for the last you may want to generate the ranges from the back-end )

The problem with having the database enforce business rules is reporting violations to the front end! If the front end enforces business rules it can quickly feedback meaningful error messages to the user. If the back-end does it there is a lot of clunky two way traffic between the front and back ends as errors are reported one at a time.
–
James AndersonNov 28 '14 at 13:06

@JamesAnderson There's no longer "the front-end". There can be several front-ends to the same database, or several databases to several front-ends. Also, having the back-end enforce business rules doesn't mean the front-end is prohibited to do it. I highlighted that in the second bullet point.
–
user61852Nov 28 '14 at 13:11