Five Common Ajax Anti-Patterns

Ajax Pattern에 이어서 Ajax Anti-Pattern도 나왔군요. (빠르기도해라.. -_-;;)

1. 타이머가 필요 없음에도 불구하고 폴링을 위해서 타이머를 사용하는 경우
 - Polling on a timer when you don't need to.
타이머는 지정한 시간 단위마다 호출되는 기능을 가지고 있습니다. 이러한 기능들을 이용하여 애니메이션을 보여주는 기능에 사용할 수 있습니다.

그러나, 이러한 만들어진 목적을 벗어나서 많은 곳에 사용할 경우, 타이머의 기능이 원하는 시간에 호출되지 못할 수도 있습니다. (자바스크립트는 단일 스레드를 사용하기 때문입니다.)

1. XMLHttpRequest를 보낸 후 응답을 받기 위해서 타이머를 사용 - onreadystatechange의 callback 메카니즘을 사용
   
2. 사용자 입력단어에 따른 검색 결과(Auto-Complete)를 보여주기 위해서 타이머를 - onkeyup의 callback 메카니즘을 사용

2. Callback을 받을 때, 리턴 결과를 확인하지 않는 경우
 - Not inspecting the return results in the callback.
XMLHTTPRequest를 사용해서 응답을 받는 경우 (onreadystatechange의 callback으로 메소드가 호출될 때) readyState나 status를 확인해보지 않고 사용을 하는 경우, 응답이 전부 도착하지 않는 경우라도 계속하여 state가 변화되고, 따라서, onreadystatechange의 callback이 호출되게 됩니다.

따라서, 불완전한 데이터를 전송 받게되어서 에러가 발생할 수 있게 되는 것이죠.

1. readyState와 status 체크함으로 해결할 수 있습니다. (req는 request입니다.)
   if (req.readyState == 4 && req.status == 200 ) {
   

   }

3. HTML만으로 될 일을 복잡한 XML로 하는 경우
 - Passing complex XML when HTML would be better.
서버사이드의 부하를 줄이기 위해서 클라이언트로 부하를 덜어오는 것 자체는 나쁘지 않습니다. 그러나, 클라이언트가 복잡해진다는 말은 많은 양의 자바스크립트(브라우져 호환성도 생각해야죠.)가 사용되어야 하는 의미이므로 항상 좋은 것은 아닙니다.

서버와 클라이언트 사이에서 잘 균형이 잡혀야되지 한 쪽에 부하를 주어서는 안됩니다. (정렬하거나 검색하거나,  추가, 삭제같은 동적인 작업이 필요하다면, 더 복잡한 클라이언트라도 괜찮습니다. 그러나, 단순하게 보여주는 즉, HTML로 대체될 수 있는 작업이라면 HTML로 작성하세요.)

4. JavaScript(JSON)를 사용하지 않고 XML 데이터를 주고 받는 경우
-  Passing XML when you should pass JavaScript code.
JSON을 쓰게되면,

1. 코드를 쉽게 짤 수 있습니다.
   
2. 전송하는 데이타의 양이 작아집니다. (실험한 데이터로는 52%까지 줄였다고 하네요.)
   
3. 데이터를 읽어들이는 속도가 빠릅니다. (실험했을 때는 9%정도 줄였다고 합니다만 정확하게는 데이터의 종류에 따라 달라질 수 있습니다. 복잡한 데이터의 경우는 XML이 더 빠릅니다.)

5. 서버에서 너무 많은 일을 하는 경우
 - Doing too much on the server
한 페이지의 테이블을 정렬하는 작업같은 경우는 서버에서 수행하는 것보다 JavaScript에서 처리하는게 더 빠르고 효율적입니다.

가장 중요한것은 치우치지 않는 균형감각이 아닐까 싶네요. ^^

출처 :

InfoQ의 Five Common Ajax Anti-Patterns와 원본기사인 IBM의 Ajax and XML의 Five Ajax anti-patterns