Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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).

share|improve this question
add comment

6 Answers

up vote 14 down vote accepted

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.

share|improve this answer
1  
+1 for hiding the layers. SQL injection comes to mind... –  jmq Mar 6 '12 at 20:40
    
I don't think SQL injections have anything to do with moving most of your logic to the client-side. Even if you move data processing to the client-side, you still need some sort of server-side service which would actually run SQL queries (unless you want to make your database username and password public). That service is responsible for validating and escaping data. There is no difference there - you MUST validate and escape any input on your server-side ALWAYS. There is simply no way around it. –  Pius May 25 '13 at 7:57
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment
  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

share|improve this answer
add comment

Client Side Versus Server Side

Client side processing is in line with the more popular REST standards as well as MVC as opposed to page based approaches and SOAP. The emergence of these trends and focus on AJAX and Html-RIA, client side scripting is on the rise and more popular; however, due to security concerns and client capability, client-side scripting has a particular niche and should not be used for everything.

Considerations:

Mobile

If a large segment of your target audience will be mobile users, heavy processing should be left up to the server.

Cross-browser consistency

Web standards have come a long way and this may not be as much of a concern, but every web developer knows that IE 6,7, and 8 and sometimes Safari can act funny on the server side--certain functions may not run because of security restrictions and others because of un-implemented standards. It's also important to note that the end user can configure a browser to have certain restrictions or even completely turn client-side processing off (no javascript!). If consistency is a requirement for 100% of users (and especially if you're doing something unorthodox) server side is most important.

Security

Any data manipulation that you want to secure needs to be done on the server. Any data that is processed on the client side is absolutely open for manipulation. For example, if you have a javascript function that processes some information that then gets posted back into the system--it would be very easy to manipulate the result just before it is posted back even if you have exemplary back-end security

UI/UX

Client-side processing is left for the user interface and creating rich internet applications (RIAs). It is used to create animations, effects, user interactions, as well as dynamically loading content through AJAX calls instead of re-loading a whole page.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.