숨겨진 AJAX는 가짜 성능을 요구하는 것이 얼마나 안전합니까?

숨겨진 AJAX 요청은 무엇입니까?

사용자의 작업이 즉시 발생하도록 설계된 숨겨진 AJAX 요청의 사용이 증가한 것으로 나타났습니다. 이 유형의 AJAX 요청을 비 블로킹이라고합니다. 사용자가 발생하고 있음을 인식하지 않고 AJAX 요청이며 백그라운드에서 수행되며 작업이 조용합니다 ( AJAX 호출이 성공적으로 완료되었음을 나타내는 자세한 내용은 없습니다 ). 목표는 작업이 실제로 완료되지 않았을 때 즉시 발생했음을 표시하는 것입니다.

다음은 비 차단 AJAX 요청의 예입니다.

• 사용자는 이메일 모음에서 삭제를 클릭합니다. 항목이받은 편지함에서 즉시 사라지고 다른 작업을 계속할 수 있습니다. 한편 AJAX 요청은 백그라운드에서 항목 삭제를 처리 중입니다.
• 사용자는 새 레코드 양식을 작성합니다. 저장을 클릭하십시오. 새 항목이 목록에 즉시 나타납니다. 사용자는 계속 새 레코드를 추가 할 수 있습니다.

명확히하기 위해 AJAX 요청을 차단하는 예가 있습니다.

• 사용자는 이메일 모음에서 삭제를 클릭합니다. 모래 시계 커서가 나타납니다. AJAX 요청이 이루어지고 응답 할 때 모래 시계 커서가 꺼집니다. 사용자는 작업이 완료 될 때까지 잠시 기다려야합니다.
• 사용자는 새 레코드 양식을 작성합니다. 저장을 클릭하십시오. AJAX 로더 애니메이션이 적용되면 양식이 회색으로 바뀝니다. "데이터가 저장되었습니다"라는 메시지가 표시되고 새 레코드가 목록에 나타납니다.

위의 두 시나리오의 차이점은 비 차단 AJAX 설정은 운영 수행에 대한 피드백을 제공하지 않으며 차단 AJAX 설정은 그렇지 않다는 것입니다.

숨겨진 AJAX 요청의 위험

이 스타일의 AJAX 요청의 가장 큰 위험은 AJAX 요청이 실패하면 웹 애플리케이션이 완전히 다른 상태에있을 수 있다는 것입니다.

예를 들어, 비 차단 예;

• 사용자는 많은 이메일을 선택합니다. 삭제 버튼을 클릭하십시오. 작업이 즉시 발생하는 것처럼 보입니다 (항목이 목록에서 사라짐). 그런 다음 사용자는 편지 쓰기 버튼을 클릭하고 새 이메일을 입력하기 시작합니다. 현재 JavaScript 코드가 AJAX 요청이 실패했음을 발견했습니다. 스크립트가 오류 메시지를 표시 할 수 있지만 현재로서는 의미가 없습니다.

대안 적으로, 차단 예;

• 사용자는 많은 이메일을 선택합니다. 삭제 버튼을 클릭하십시오. 모래 시계가 보이지만 작동하지 않습니다. "error. blah blah blah"라는 오류 메시지가 나타납니다. 이메일 목록으로 되돌아 가고 삭제하려는 이메일이 여전히 선택되어 있습니다. 다시 삭제를 시도 할 수 있습니다.

비 차단 AJAX 요청을 수행 할 때 다른 기술적 위험도 있습니다. 사용자는 브라우저를 닫고 다른 웹 사이트로 이동할 수 있으며 현재 웹의 다른 위치로 이동하여 오류 응답의 컨텍스트를 무의미하게 만들 수 있습니다.

그렇다면 왜 그렇게 인기가 있습니까?

Facebook, Google, Microsoft 등.이 모든 대형 도메인은 비 차단 AJAX 요청을 점점 더 많이 사용하여 작업 이 즉각적으로 수행되는 것처럼 보이게 합니다. 또한 저장 또는 제출 버튼 이 없는 양식 편집기가 증가했습니다 . 필드를 떠나거나 Enter 키를 누르 자마자. 값이 저장됩니다. 어떤이 프로필이 업데이트되었습니다 메시지 또는 저장하는 단계.

AJAX 요청은 확실하지 않으며 완료 될 때까지 성공한 것으로 취급해서는 안되지만 많은 주요 웹 응용 프로그램이 그렇게 작동합니다.

비 차단 AJAX 호출을 사용하여 반응 형 응용 프로그램을 시뮬레이션하는 웹 사이트가 빠른 비용으로 불필요한 위험을 감수합니까?

이것이 경쟁력을 유지하기 위해 우리가 따라야하는 디자인 패턴입니까?

실제 반응만큼 "가짜"성능은 아닙니다. 인기있는 이유는 여러 가지가 있습니다.

• 오늘날 인터넷 연결은 상당히 안정적입니다. AJAX 요청 실패의 위험이 매우 낮습니다.
• 수행되는 작업은 실제로 안전에 중요하지 않습니다. 이메일이 서버에서 삭제되지 않으면 최악의 경우 다음에 페이지에 올 때 다시 삭제해야합니다.
• 요청이 실패하면 작업을 실행 취소하도록 페이지를 디자인 할 수 있지만 서버와의 연결이 끊겼다는 것을 의미하기 때문에 실제로 미묘 할 필요는 없습니다. "연결이 끊어졌습니다. 최근 변경 사항을 저장할 수 없습니다. 나중에 다시 시도하십시오."라고 말하는 것이 더 쉽습니다.
• 보류중인 AJAX 요청을 하나만 허용하도록 페이지를 설계 할 수 있으므로 상태가 서버와 너무 동기화되지 않습니다.
• AJAX 요청이 보류중인 동안 페이지를 닫거나 다른 곳으로 이동하려고하면 브라우저가 경고합니다.

서버가 응답 할 때까지 사용자가 다른 작업을 수행하는 것을 차단하는 것보다 원격에서 장애가 발생하는 경우 무언가가 작동하고 오류를 표시한다고 가정합니다.

전자 메일 클라이언트는 실제로 이에 대한 좋은 예입니다. 5 개의 전자 메일이있는 목록이 있고 최상위 전자 메일을 선택 DEL하면 처음 세 개의 전자 메일을 세 번 칠 때 삭제 될 것으로 예상합니다 . "비 차단 AJAX"를 사용하면이 기능이 제대로 작동합니다. 키를 누를 때마다 선택한 이메일이 즉시 제거됩니다. 문제가 발생하면 오류가 표시되고 제대로 삭제되지 않은 전자 메일이 다시 표시되거나 페이지가 다시로드되어 일관성이없는 로컬 상태가 제거됩니다.

따라서 가장 일반적인 경우 , 즉 성공은 유용성을 향상시킵니다. 에서 드문 경우 - 실패 - 유용성이 저하됩니다 (삭제 된 요소를 다시 표시하거나 응용 프로그램이 "다시 시작"한다)는 보통 일반적인 경우에 대한 최적의 사용성을 갖고 싶어하는 응용 프로그램을 작성하지 오류가 발생하는 경우에 때.

사용자는 소프트웨어가 무대 뒤에서하는 일에 신경 쓰지 않습니다. 즉, 자신의 행동이 눈에 띄는 영향을 미치고 자신의 속도에 맞게 작업하기를 원합니다.

이메일 삭제와 같이 클라이언트 측에서 작업이 성공한 경우 서버 측에서도 작업을 수행하는 것이 좋습니다. 삭제가 실패한 이유는 무엇입니까? 어떤 종류의 제한으로 인해 (예를 들어, 보관 된 전자 메일을 제거 할 수없는 경우), 사용자는 자신의 작업이 실패 하기 전에 이를 알고 있어야합니다 .

오류가 더 심각한 것으로 인해 발생한 경우 (데이터베이스 충돌이라고 함) 작업을 저장하고 시스템이 다시 작동 할 때 다시 시도하는 방법이 있어야합니다.

이를 관리하는 좋은 예는 Facebook이 채팅을 처리하는 방법입니다. 사용자가 갑자기 연결을 끊는 것을 막을 방법이 없으므로 사용자가 떠나기 전에 보낸 메시지를 읽을 수 없습니다. 시스템은 오류를 표시하는 대신 모든 해당 메시지를 저장하고 사용자가 돌아올 때 사용할 수 있도록합니다. 데이터가 손실되지 않습니다.

두 옵션 사이에서 타협 할 수 있습니다. 예를 들어, 사용자가 이메일을 삭제 한 경우 서버에서 확인을받을 때까지 이메일을 빨간색 또는 회색으로 표시 한 다음 목록에서만 제거 할 수 있습니다. 한 작업이 보류중인 동안에도 사용자는 다른 작업을 수행 할 수 있으므로 차단되지는 않지만 아직 사용자의 작업이 아직 커밋되지 않았다는 알림이 약간 남습니다.

Amazon AWS는 다음과 같은 접근 방식을 취합니다. 인스턴스를 중지 / 시작할 때 인스턴스를 선택할 수있는 확인란이 스피너로 바뀌므로 (몇 초 동안 아무 작업도 수행 할 수 없음) 다른 인스턴스와 상호 작용

필자는 이것이 기존 사이트보다 응용 프로그램처럼 작동하고 브라우저에서 양식 데이터 확인과 같이 더 많은 처리를 수행하는 점점 더 많은 웹 사이트와 함께 제공된다고 생각합니다. 코드가 신뢰할 수 있고 정상적인 조건에서 코드가 성공할 것으로 예상되는 한 문제가 너무 많지는 않습니다.

"현재 JavaScript 코드가 AJAX 요청 실패를 감지했습니다. 스크립트에 오류 메시지가 표시 될 수 있지만 현재로서는 의미가 없습니다."

왜 무의미해야합니까? 이메일 목록으로 돌아가서 삭제를 다시 수행 할 수 있습니다. 왜 대신 기다려? 실제로 "위험"은 많지 않으며 빠르다고 "보이지"않고 실제로 더 빠르게 작동합니다. 활동이 "중요하지"않다면 왜 느려 집니까?

제 2c는 : "비 차단"Ajax 작업과 나쁜 디자인 선택이있는 다른 상황을 갖는 것이 더 좋은 상황입니다. 예 : YouTube 동영상 투표 작은 시작을 클릭하는 동안 페이지의 어떤 부분도 막히고 싶지 않습니다. 조용히 실패하는 것이 좋습니다. 확인 메시지조차도 과잉 상태입니다. 그러나 이메일 삭제에 대한 귀하의 예는 차단 유형 Ajax 요청에 대한 필수 자격이 있습니다.

Mongo DB는 이와 같은 작업을 수행합니다 (데스크톱 애플리케이션 예제로 간주 될 수 있음). 작업에 대해 다양한 "쓰기 문제"가 있으며, "즉시 반환하고 아무 것도 기다리지 않음"에서 "네트워크 전송 성공을 확인할 때까지 차단"에 이르기까지 각 작업에 대해 다른 값으로 구성 할 수 있습니다. "반환"을 클릭하여 "원격 시스템에서 디스크 쓰기를위한 내용이 예약 될 때까지 기다렸다가 다시옵니다". 분명히 Mongo 드라이버를 사용하여 C ++와 같은 데스크톱 씩 클라이언트를 만드는 경우 최소한 "중요도"(예 : 새 전자 메일 확인) 및 기타 엄격한 쓰기 문제에 대한 DB 작업에 대해 가장 가벼운 쓰기 문제를 설정해야합니다. .

비 차단 Ajax의 유용성을 보았지만 너무 많이 발생한다는 데 동의합니다. 어느 시점에서 사진 업로드를 위해이 작업을 수행하는 유명한 "소셜 네트워킹"사이트가 하나 이상있었습니다. 업로드 할 사진을 선택한 다음 bam을 선택하면 즉시 완료되었음을 알리고 다음 날 더 많은 사진을 추가하고 싶거나 다음에 이미 추가했다고 생각했을 때 충분히 사용하십시오. 찾을 수 없었습니다. 나중에 그들은 포기하고 실제로 응답을 기다리는 데 시간이 걸렸습니다 (실제로는 "사진 업로드 실패, 나중에 시도"와 같은 메시지가 표시 될 수 있습니다).