Ajax: Where should my business logic sit?

In my recent Ajax In Action talk I gave at the Central PA code camp, I had some interesting side discussions with people about Ajax. One of the topics that seemed to come up is: "Where should my business logic sit?"

I always tell people that it needs to sit on the server and not on the client. The two points that it is based upon is speed and security. Since security is an easier topic to cover I will start there.

Now for years that I have been moderating on JavaRanch.com, one of the questions I see pop up is how can I secure my code, images, HTML markup, CSS, and so on. The real answer is anything that is rendered in a browser is basically "Open Source" since there is no way to really protect it. All of this information is "downloaded" into the cache so everyone has a copy of it. You can destroy all the formatting by eliminating returns and changing variable names, but it still can be deciphered by anyone that has time. So basically if security is very important for you, than your business logic has to be on the server. (If I see anyone saying right click scripts and no tool bars are the way to avoid this in my comments I am going to laugh. Give me 5 seconds to send you the source code.)

Now speed of execution is also a point that was brought up. Your server running server side code should be a lot faster than most people's computers running JavaScript. Get a person with 10 browser windows open, word and excel, acrobat reader, outlook, media player, and those spyware apps running and say bye to the memory and speed. Ever run a for loop with 3000 interactions? Some people's browsers choke and freeze up. This is one main reason to stick with the server for business logic is more reliability in processing information. Plus most servers are built to crunch data. Why use a browser running JavaScript that has poor memory management (unless you built your server side app. with poor memory management, but that is a different story!)

A counter argument was putting business logic before making the request limits the amount of data being sent to the server. This is true for certain applications. Look at the type ahead suggest that I wrote in Ajax In Action. We use logic to determine if we need to make the request. Do you have the correct data or should we send the XHR to the server to get more data. BUT you do not see me building my query string directly from the JavaScript opening up a big hole for any SQL injections. I have seen that with some implementations people have showed me on forums and email. Major No No! Please delete my database table!

In general you should put your business logic on the server. The clientside should be handling the displaying of the data (aka the user interface portion.) It is just like our classic postback web application. You never built querys or logic with JavaScript code and saved it in a hidden text field for the server side code to read. All of that is done behind the scenes out of the view of the people. That same idea should apply to your Ajax applications. If you are accessing databases, algorithms, etc. you need to keep this information secure on the server. Ajax or even a classic postback form can open this up to attack, so you need to always secure your data and check for the injection attacks.

Hopefully I answered some people's questions on this topic with my quick rambling. I know I did not go into any great detail or have sample code, but I am sure I got some points across.

Eric Pascarello

Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages