Pros/cons between emphasizing client-side or server-side processing

Question

Why would I want to write a web app with lots of processing server-side?

To me, writing the program client-side is a huge advantage because it takes away as much server load as possible because it only has to send data to the client with minimal processing.

I see very little on writing web-apps besides writing it server-side and treating client-side as only a view. Why would I ever want to do this? The only advantage I see is that I can write in whatever language I want (http://www.paulgraham.com/avg.html).

Answer 1

There are two major issues.

1. The first is easy--you usually don't know what sort of resources are available on the client side. If it requires 1.5GB to process something, can you really push that onto an unknown client browser (IE, Safari, Opera, Firefox, etc.) on an unknown client platform? Will the client appreciate his system dogging when you overwhelm it?

2. The second is more architectural--what layers do you want to expose to the outside world? Most would agree that it's incredibly risky to expose your data layer. How about your service layer? Do you really want to deliver that logic out there? If you do, are you also exposing the entry points to your data layer? If you keep the service layer server side, then what's left? The UI, right? See reason 1 about for considerations on how much of that lives on the server and how much on the client.

Answer 2

First and foremost is Security. Push all your logic out to the client and it is fair game for hackers and exploits.

Anything with any perceived value won't last 5 minutes, and will be gamed or hacked or exploited and break your system pretty badly.

Answer 3

Primarily it will be a duplication of effort. Most likely any data from the client will have be checked and processed at the server level again.

The server cannot assume that your rich/robust client sent the data, so with anything data being sent, the server must validate it and process. So it makes sense to put it there.

However, I beleive some logic can be done at the client level for a better UI experience.

You are correct, why send data to the server if is not complete or incorrect. It's easy to check for required fields or for properly formatted phones or email addresses. I never liked submitting a form and then waiting 5 seconds to tell me I forgot to enter a field. That kind of processing, sure, do it on the client and make sure it is correct and using client side logic for a fast response to the user. As you have pointed out, a bonus side effect would be that your server would have to deal with less bad data requests. BUT, the server still has to validate also, so you are duping logic. But, your users will be happier.

There is a fine line here. Simple validation logic OK, core business logic not OK.

Answer 4

A big part is keeping your processing close to your data. If you've got hundreds of GB of data you're obviously not going to ship that to a client. With data access speeds increasing this is becoming less of an issue, but if you've got a Big Data site you still want to do as much filtering and narrowing on the server as you can before shipping it out.

Answer 5

1. First of all you need to understand the architecture of web applications, most if not all are 3-tier:

a) Client/Presentation - HTML and Javascript, may contain ActiveX/Flash/Java Applets/Silverlight. I will go out on a limb and add native mobile applications which communicate with a backend server. Basically the role of this layer is to provide an interface for the user of the system to interact with it.

b) Business Logic - PHP/RoR/Java where the data from the client is collected, processed and store and where client requests for data are processed and sent back to the client

c) Backend Data Store - provides persistent storage for the system information

1. So where do you do the validation, in all layers. Why?

a) Client side - ensure the user enters correct data, required fields etc

b) Business logic - filter, sanitize and validate client data. Run more complex business rules to ensure that the data is well formed for storage. Some of the validation done at the front end is repeated here, due to the fact that there may be different clients, take for example browsers the Javascript can be disabled. It may also accept data from different sources via APIs for example, so it all needs to be validated.

c) Backend Data Store - constraints ensure that the data is well formed for storage and later retrieval.

So where do you focus your validation efforts, use each layer to perform the validation that suits it best, and leave more complex rules for the layer that can handle it