Làm thế nào an toàn được ẩn các yêu cầu AJAX mà hiệu suất giả?


48

Yêu cầu AJAX ẩn là gì?

Tôi đã nhận thấy sự gia tăng trong việc sử dụng các yêu cầu AJAX ẩn được thiết kế để khiến hành động của người dùng dường như xảy ra ngay lập tức. Tôi sẽ đề cập đến loại yêu cầu AJAX này là không chặn. Đó là một yêu cầu AJAX được thực hiện mà người dùng không biết rằng nó đang diễn ra, nó được thực hiện ở chế độ nền và hoạt động của nó là im lặng ( không có gì dài dòng để chỉ ra việc hoàn thành cuộc gọi AJAX thành công ). Mục tiêu là làm cho hoạt động xuất hiện rằng nó đã xảy ra ngay lập tức khi nó thực sự chưa kết thúc.

Dưới đây là các ví dụ về yêu cầu AJAX không chặn;

  • Người dùng nhấp vào xóa trên một bộ sưu tập các email. Các mục biến mất ngay lập tức khỏi hộp thư đến của chúng và chúng có thể tiếp tục với các hoạt động khác. Trong khi đó, một yêu cầu AJAX đang xử lý xóa các mục trong nền.
  • Người dùng điền vào một biểu mẫu cho hồ sơ mới. Nhấp chuột lưu. Các mục mới xuất hiện trong danh sách ngay lập tức. Người dùng có thể tiếp tục thêm hồ sơ mới.

Để làm rõ, đây là các ví dụ về việc chặn yêu cầu AJAX;

  • Người dùng nhấp vào xóa trên một bộ sưu tập các email. Một con trỏ đồng hồ cát xuất hiện. Yêu cầu AJAX được thực hiện và khi nó đáp ứng, con trỏ đồng hồ cát sẽ bị tắt. Người dùng phải đợi một giây để hoạt động hoàn tất.
  • Người dùng điền vào một biểu mẫu cho hồ sơ mới. Nhấp chuột lưu. Biểu mẫu chuyển sang màu xám với trình tải AJAX hoạt hình. Một thông báo được hiển thị "Dữ liệu của bạn đã được lưu" và bản ghi mới xuất hiện trong danh sách.

Sự khác biệt giữa hai trường hợp trên là thiết lập AJAX không chặn không cung cấp phản hồi về hoạt động thực hiện và thiết lập AJAX chặn.

Nguy cơ của các yêu cầu AJAX ẩn

Rủi ro lớn nhất của kiểu yêu cầu AJAX này là ứng dụng web có thể ở trạng thái hoàn toàn khác khi yêu cầu AJAX không thành công.

Ví dụ, một ví dụ không chặn;

  • Người dùng chọn một loạt các email. Nhấp vào nút xóa. Các hoạt động dường như xảy ra ngay lập tức (các mục chỉ biến mất khỏi danh sách). Sau đó, người dùng nhấp vào nút soạn thảo và bắt đầu nhập một email mới. Tại thời điểm này, mã JavaScript phát hiện ra yêu cầu AJAX không thành công. Kịch bản có thể hiển thị một thông báo lỗi, nhưng nó thực sự là vô nghĩa tại thời điểm này.

Thay phiên, một ví dụ chặn;

  • Người dùng chọn một loạt các email. Nhấp vào nút xóa. Nhìn thấy một giờ kính, nhưng hoạt động thất bại. Họ nhận được một thông báo lỗi "lỗi. Blah blah blah". Chúng được đưa trở lại danh sách các email và chúng vẫn có các email mà chúng muốn xóa được chọn. Họ có thể cố gắng xóa chúng một lần nữa.

Ngoài ra còn có các rủi ro kỹ thuật khác để thực hiện các yêu cầu AJAX không chặn. Người dùng có thể đóng trình duyệt, có thể điều hướng đến một trang web khác và họ có thể điều hướng đến một vị trí khác trong trang web hiện tại khiến bối cảnh của bất kỳ phản hồi lỗi nào đều vô nghĩa.

Vậy tại sao nó lại trở nên phổ biến như vậy?

Facebook, Google, Microsoft, v.v .. tất cả các tên miền lớn này đang ngày càng sử dụng các yêu cầu AJAX không chặn để làm cho các hoạt động xuất hiện mà chúng được thực hiện ngay lập tức. Tôi cũng đã thấy sự gia tăng trong các trình soạn thảo biểu mẫu không có nút lưu hoặc gửi . Ngay khi bạn rời khỏi một lĩnh vực hoặc nhấn enter. Giá trị được lưu. Không có hồ sơ của bạn đã được cập nhật tin nhắn hoặc bước lưu.

Các yêu cầu AJAX không phải là một điều chắc chắn và không nên được coi là thành công cho đến khi chúng hoàn thành, nhưng rất nhiều ứng dụng web lớn đang hoạt động như vậy.

Các trang web này có sử dụng các cuộc gọi AJAX không chặn để mô phỏng các ứng dụng đáp ứng có rủi ro không cần thiết với chi phí xuất hiện nhanh không?

Đây có phải là một mẫu thiết kế mà tất cả chúng ta nên tuân theo để duy trì tính cạnh tranh?


20
Điều này được chứng minh bởi thực tế là hoạt động thành công có nhiều khả năng, do đó chậm chỉ để tránh trường hợp hiếm hoi phản hồi quá lạc quan là một sự đánh đổi tồi tệ. Chuyển sang các mối quan hệ cá nhân, bạn muốn tương tác với một người bình tĩnh, đầy nắng hay một người giả định rằng mọi thứ có thể sai sẽ trở nên sai lầm và hành động phù hợp?
Kilian Foth

1
Đối với tôi, điều mà tôi đang vật lộn với, đó là một ứng dụng máy tính để bàn có cả hoạt động và lỗi xảy ra ngay lập tức. Trong trường hợp, với các ứng dụng web, thao tác xảy ra ngay lập tức, nhưng lỗi bị trễ. Tuy nhiên, các trang web hoạt động với thiết kế của một ứng dụng máy tính để bàn.
Phản ứng

7
Bạn cũng đã xem xét những gì xảy ra khi ứng dụng máy tính để bàn của bạn ghi vào đĩa, nó thực sự đi vào bộ đệm hệ điều hành và đĩa bị lỗi trước khi nó có thể được ghi vào đĩa? Hoặc, đối với vấn đề đó, đĩa bị lỗi sau khi byte được ghi vào đĩa. Trong cả hai trường hợp, người dùng nghĩ rằng điều gì đó đã xảy ra khi nó thực sự không xảy ra.
kdgregory

2
@KilianFoth Tôi thích người cho rằng mọi thứ có thể sai, nếu người "nắng" sẽ đấm bạn và đánh cắp ví của bạn ở dấu hiệu rắc rối đầu tiên. Vì vậy, nó phụ thuộc vào quy mô của phản ứng của trang về thất bại.
Izkata

1
@BriptButkus Tôi nghĩ rằng những tin nhắn lưu là mới. Họ không ở đó khi tôi đặt câu hỏi. Tôi đã nhận thấy google thêm nhiều thông tin phản hồi gần đây, đó là hoạt động trong nền.
Phản ứng

Câu trả lời:


62

Đó không phải là hiệu suất "giả" nhiều như phản ứng thực sự. Có một số lý do tại sao nó phổ biến:

  • Kết nối Internet ngày nay khá đáng tin cậy. Nguy cơ thất bại của yêu cầu AJAX là rất thấp.
  • Các hoạt động đang được thực hiện không thực sự quan trọng an toàn. Nếu email của bạn không bị xóa trên máy chủ, điều tồi tệ nhất xảy ra là bạn phải xóa chúng lần sau khi bạn đến trang.
  • Bạn có thể thiết kế trang của mình để hoàn tác hành động nếu yêu cầu không thành công, nhưng bạn không thực sự phải tinh tế vì điều đó có nghĩa là kết nối của bạn với máy chủ bị hỏng. Thật dễ dàng hơn để nói "Mất kết nối. Không thể lưu các thay đổi gần đây. Hãy thử lại sau."
  • Bạn có thể thiết kế trang của mình để chỉ cho phép một yêu cầu AJAX đang chờ xử lý, do đó trạng thái của bạn sẽ không quá đồng bộ hóa từ máy chủ.
  • Trình duyệt cảnh báo bạn nếu bạn cố đóng hoặc điều hướng khỏi một trang trong khi yêu cầu AJAX đang chờ xử lý.

Cảnh báo chờ xử lý AJAX


8
Điểm cuối cùng đó, có phải tất cả các trình duyệt làm điều đó theo mặc định?
Svish

Tôi không biết. Tôi chỉ thử nghiệm nó trên IE9 và chrome mới nhất.
Karl Bielefeldt

3
Bạn rõ ràng không quen thuộc với Internet Úc, chưa kể đến những nơi nghèo nàn, đang phát triển và bị cô lập, thậm chí là di động trên một phương tiện di chuyển ...
hà mã

2
@hippietrail Vâng, bạn không thể làm mọi người vui vẻ mọi lúc.
KOVIKO

1
Khi người dùng gửi yêu cầu, anh ta không luôn yêu cầu một trang mới. Tôi nghĩ rằng các ứng dụng AJAX được thiết kế tốt có thể khiến chúng trở nên thú vị hơn, cho người dùng biết những gì đang diễn ra hiệu quả hơn là tải lại.
Frederik.L

32

Giả sử một cái gì đó sẽ hoạt động và hiển thị một lỗi trong trường hợp nó bị lỗi ở phía từ xa thì thân thiện với người dùng hơn nhiều so với việc chặn người dùng làm bất cứ điều gì khác cho đến khi có phản hồi từ máy chủ.

Một ứng dụng email thực sự là một ví dụ tuyệt vời cho điều này: Khi tôi có một danh sách với 5 email và một email hàng đầu được chọn, tôi hy vọng rằng khi nhấn DELba lần ba email đầu tiên sẽ bị xóa. Với "không chặn AJAX", điều này hoạt động tốt - mỗi khi tôi nhấn phím, email đã chọn sẽ bị xóa ngay lập tức. Nếu có lỗi xảy ra, một lỗi sẽ được hiển thị và các email không được xóa đúng sẽ được hiển thị lại HOẶC trang được tải lại để thoát khỏi trạng thái cục bộ không nhất quán.

Vì vậy, trong trường hợp phổ biến nhất - đó là thành công - nó cải thiện khả năng sử dụng. Trong trường hợp hiếm gặp - thất bại - khả năng sử dụng bị suy giảm (phần tử bị xóa hiển thị lại hoặc ứng dụng bị "khởi động lại") nhưng khi tạo một ứng dụng, bạn thường muốn có khả năng sử dụng tốt nhất cho các trường hợp thông thường, không phải trong trường hợp có lỗi.


1
+1 đây là điểm chính của vấn đề. Có rất nhiều sự an toàn theo mặc định mọi người thực hiện trong những ngày này đến mức trong trường hợp xấu nhất bạn vẫn không gặp phải lỗi người dùng thực sự: hãy tưởng tượng ứng dụng email không xóa được, hiện trạng thái cục bộ rất tệ và họ thử xóa email 4 bị sai với máy chủ, phần lớn các nhà phát triển back-end sẽ có một biện pháp an toàn để đảm bảo bạn chỉ xóa những gì người dùng hoàn toàn muốn và do đó việc sắp xếp sai này sẽ không gây ra lỗi xóa (nó có thể bị lỗi nhưng nó sẽ không xóa) .
Jimmy Hoffa

@JimmyHoffa bạn sẽ sử dụng một id email duy nhất trong yêu cầu xóa. Sẽ rất tệ khi gửi yêu cầu xóa dựa trên thứ tự hiển thị tùy ý của các email trong hộp thư đến của bạn.
Butussy Butkus

14

Người dùng không quan tâm đến những gì phần mềm của bạn đang làm đằng sau hậu trường: họ muốn hành động của họ có tác động rõ ràng và có thể hoạt động theo tốc độ của họ.

Nếu một hành động thành công ở phía khách hàng - như xóa email - thì đó cũng là công việc của bạn để làm cho nó thành công ở phía máy chủ. Tại sao việc xóa thất bại? Nếu đó là do một số hạn chế (ví dụ, bạn không thể xóa email đã được lưu trữ), người dùng nên được biết về điều đó trước khi hành động của mình thất bại.

Nếu lỗi xảy ra do lỗi nghiêm trọng hơn (giả sử sự cố cơ sở dữ liệu), bạn nên có cách lưu hoạt động và thử lại khi hệ thống hoạt động trở lại.

Một ví dụ điển hình của việc quản lý điều này là cách Facebook xử lý trò chuyện. Không có cách nào để ngăn người dùng ngắt kết nối đột ngột, điều đó có nghĩa là họ sẽ không thể đọc các tin nhắn bạn đã gửi trước khi họ rời đi. Thay vì hiển thị một lỗi, hệ thống sẽ lưu tất cả các tin nhắn đó và cung cấp chúng cho người dùng khi anh ta quay lại. Không có dữ liệu bị mất.


2
+1. Ví dụ trò chuyện tuyệt vời. Hầu hết người dùng mong muốn tin nhắn của họ sẽ được cung cấp ngay lập tức cho mọi người và vì những tin nhắn như vậy hiếm khi thất bại, người dùng sẽ ảo tưởng rằng đó là trường hợp.
Neil

1
@Niphra, "Tại sao việc xóa thất bại?" Mạng có thể thất bại vì nhiều lý do, không có lý do nào để làm với ứng dụng của bạn. Có bạn có thể làm để ngăn chặn điều đó.
Pacerier 16/2/2015

5

Bạn có thể thỏa hiệp giữa hai lựa chọn. Ví dụ: nếu người dùng xóa email, bạn có thể đánh dấu nó màu đỏ hoặc xám cho đến khi bạn nhận được xác nhận từ máy chủ và chỉ sau đó xóa nó khỏi danh sách. Người dùng vẫn có thể làm những việc khác trong khi một hành động đang chờ xử lý, do đó, nó không chặn, nhưng nó vẫn để lại một lời nhắc nhở cho người dùng rằng hành động của họ chưa được thực hiện.

Amazon AWS thực hiện phương pháp này: khi bạn dừng / bắt đầu một thể hiện, hộp kiểm cho phép bạn chọn nó biến thành một công cụ quay vòng (vì vậy bạn không thể làm gì với nó trong vài giây), nhưng điều này không chặn bạn tương tác với các trường hợp khác.


Đề xuất của bạn tương tự như cách gmail hiển thị văn bản "Đang lưu ..." trong khi XHR đang diễn ra và "Đã lưu" sau khi hoàn tất. Nếu nó luôn nói "Đã lưu", ai sẽ tin điều đó?
Butussy Butkus

3

Tôi nghĩ rằng, điều này đi kèm với ngày càng nhiều trang web cố gắng hoạt động như Ứng dụng và xử lý nhiều hơn trong trình duyệt (như xác thực dữ liệu biểu mẫu) so với các trang web truyền thống hơn. Tôi không thấy quá nhiều vấn đề ở chỗ miễn là mã của bạn đáng tin cậy và bạn có thể hy vọng nó sẽ thành công trong điều kiện bình thường.

Bạn nói "Tại thời điểm này, mã JavaScript phát hiện ra yêu cầu AJAX không thành công. Tập lệnh có thể hiển thị thông báo lỗi, nhưng thực sự nó là vô nghĩa tại thời điểm này."

Tại sao nó nên vô nghĩa? Bạn có thể quay lại danh sách Email và xóa lại. Tại sao phải chờ đợi thay thế? Thực tế không có nhiều "rủi ro" và chúng không "xuất hiện" nhanh, chúng thực sự hoạt động nhanh hơn. Vì vậy, nếu hoạt động không "quan trọng" tại sao phải chậm?


1
Có thể vô nghĩa không phải là từ đúng, nhưng ý tôi là thông báo lỗi thiếu ngữ cảnh tương đối, bởi vì người dùng hiện đang làm một cái gì đó hoàn toàn khác. Tôi đang cố nói rằng, đối với một người dùng web không biết gì, họ nghĩ rằng các email đã xóa thành công. Vì vậy, tại sao bây giờ, sau đó, họ nhận được một thông báo lỗi cho một cái gì đó họ "thấy" đã bị xóa. Đối với chúng tôi lập trình viên, chúng tôi hiểu, nhưng đối với ông nội sử dụng gmail thì họ sẽ không hiểu.
Phản ứng

Hầu hết mọi người thà sử dụng một ứng dụng trong đó mọi thứ xảy ra ngay lập tức, hệ thống phản hồi nhanh và có 1 trong 10.000 khả năng UI có thể cập nhật một cách kỳ lạ về lỗi hơn là một ứng dụng đóng băng trong một giây mỗi khi họ thay đổi giá trị.
Gort Robot

1

2c của tôi là: có những tình huống tốt hơn khi có nó, như bạn nói, đó là các hoạt động Ajax "không chặn" và các tình huống khác khi đó là một lựa chọn thiết kế tồi. Ví dụ: bình chọn một video YouTube. Bạn không thực sự muốn bất kỳ phần nào của trang bị chặn trong khi bạn nhấp vào phần bắt đầu nhỏ ở đó. Thà thất bại trong âm thầm. Ngay cả một tin nhắn xác nhận sẽ bị giết quá mức. Tuy nhiên, ví dụ của bạn với việc xóa email Tôi đủ điều kiện là bắt buộc đối với yêu cầu Ajax loại chặn.

Mongo DB làm một cái gì đó tương tự (và điều này có thể được coi là một ví dụ ứng dụng Máy tính để bàn). Họ có nhiều "Mối quan tâm bằng văn bản" cho các hoạt động của mình và bạn có thể định cấu hình nó thành các giá trị khác nhau cho từng hoạt động, từ "trả lại ngay và không chờ đợi bất cứ điều gì" đến "cho đến khi bạn xác nhận chuyển mạng thành công và sau đó quay lại "để" đợi cho đến khi nội dung được lên lịch chính xác để ghi đĩa trên máy từ xa trước khi bạn quay trở lại ". Rõ ràng, nếu bạn tạo máy khách dày cho Máy tính để bàn (như C ++) bằng trình điều khiển Mongo, bạn sẽ đặt mối quan tâm viết nhẹ nhất cho các hoạt động db về "mức độ quan trọng" tối thiểu (chẳng hạn như kiểm tra email mới) và các vấn đề khác về các vấn đề viết nghiêm ngặt hơn .

Trong khi tôi thấy sự hữu ích của việc không chặn Ajax, tôi đồng ý với bạn rằng điều đó xảy ra quá nhiều. Tại một thời điểm đã có ít nhất một trang web "mạng xã hội" nổi tiếng sẽ làm điều này để tải lên hình ảnh. Bạn đã chọn ảnh của mình để tải lên và sau đó bam, ngay lập tức nó sẽ cho bạn biết rằng nó đã được thực hiện, và sau đó chắc chắn vào ngày hôm sau khi bạn muốn thêm một số ảnh nữa (hoặc sử dụng vào đó bạn nghĩ bạn đã thêm), nó đã không bao giờ được tìm thấy. Sau đó, họ đã từ bỏ việc này và thực sự đã dành thời gian để chờ phản hồi (và đôi khi bạn thực sự sẽ nhận được thông báo như "không thể tải ảnh lên, thử lại sau").


+1 để xem mọi thứ theo cách của tôi :). Việc tải ảnh lên là một ví dụ tuyệt vời về việc nó thất bại.
Phản ứng

1
Tại sao tải lên chặn sẽ được ưa thích hơn? Trong Picasa (giao diện web), bạn có thể kéo ảnh trong, và trong khi họ tải lên ở chế độ nền, bạn có thể kéo ở, hoặc ảnh thẻ đã hoàn tất, vv Một chặn hoạt động tải lên sẽ làm cho rằng một UX khủng khiếp
BLSully
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.