Seberapa amankah AJAX tersembunyi meminta kinerja palsu?


48

Apa permintaan AJAX tersembunyi?

Saya perhatikan peningkatan penggunaan permintaan AJAX tersembunyi yang dirancang untuk membuat tindakan pengguna tampak terjadi segera. Saya akan merujuk jenis permintaan AJAX ini sebagai non-pemblokiran. Ini adalah permintaan AJAX yang dibuat tanpa pengguna sadari itu terjadi, itu dilakukan di latar belakang dan operasinya tidak bersuara ( tidak ada kata kerja yang menunjukkan penyelesaian panggilan AJAX yang berhasil ). Tujuannya adalah untuk membuat operasi tampak telah terjadi segera ketika itu benar-benar belum selesai.

Berikut adalah contoh permintaan AJAX yang tidak menghalangi;

  • Klik pengguna dihapus pada kumpulan email. Item menghilang segera dari kotak masuk mereka, dan mereka dapat melanjutkan dengan operasi lain. Sementara itu, permintaan AJAX sedang memproses penghapusan item di latar belakang.
  • Pengguna mengisi formulir untuk catatan baru. Klik simpan. Item baru segera muncul dalam daftar. Pengguna dapat terus menambahkan catatan baru.

Untuk memperjelas, berikut adalah contoh pemblokiran permintaan AJAX;

  • Klik pengguna dihapus pada kumpulan email. Kursor jam pasir muncul. Permintaan AJAX dibuat, dan ketika merespons kursor jam pasir dimatikan. Pengguna harus menunggu sebentar agar operasi selesai.
  • Pengguna mengisi formulir untuk catatan baru. Klik simpan. Bentuknya berubah abu-abu dengan loader AJAX yang bergerak. Sebuah pesan ditampilkan "Data Anda telah disimpan", dan catatan baru muncul dalam daftar.

Perbedaan antara kedua skenario di atas adalah bahwa pengaturan AJAX yang tidak memblokir tidak memberikan umpan balik dari kinerja yang beroperasi, dan pengaturan AJAX yang memblokir tidak.

Risiko Permintaan AJAX Tersembunyi

Risiko terbesar dari gaya permintaan AJAX ini adalah bahwa aplikasi web bisa dalam keadaan yang sama sekali berbeda ketika permintaan AJAX gagal.

Misalnya, contoh non-pemblokiran;

  • Pengguna memilih banyak email. Klik tombol hapus. Operasi tampaknya segera terjadi (item hilang begitu saja dari daftar). Pengguna kemudian mengklik tombol tulis dan mulai mengetik email baru. Pada saat inilah kode JavaScript menemukan permintaan AJAX gagal. Script dapat menampilkan pesan kesalahan, tetapi sebenarnya tidak ada gunanya saat ini.

Sebagai alternatif, contoh pemblokiran;

  • Pengguna memilih banyak email. Klik tombol hapus. Melihat satu jam kaca, tetapi operasi gagal. Mereka mendapatkan pesan kesalahan yang mengatakan "kesalahan. Blah blah blah". Mereka dikembalikan ke daftar email, dan mereka masih memiliki email yang ingin mereka hapus. Mereka dapat mencoba menghapusnya lagi.

Ada juga risiko teknis lainnya untuk melakukan permintaan AJAX yang tidak menghalangi. Pengguna dapat menutup browser, dapat menavigasi ke situs web lain dan mereka dapat menavigasi ke lokasi lain di web saat ini yang membuat konteks respons kesalahan apa pun menjadi tidak berarti.

Jadi mengapa ia menjadi begitu populer?

Facebook, Google, Microsoft, dll. Dll. Semua domain besar ini semakin menggunakan permintaan AJAX yang tidak menghalangi untuk membuat operasi tampak bahwa mereka dilakukan secara instan. Saya juga melihat peningkatan editor formulir yang tidak memiliki tombol simpan atau kirim . Segera setelah Anda meninggalkan bidang atau tekan enter. Nilai disimpan. Tidak ada profil Anda yang diperbarui pesan atau langkah penyimpanan.

Permintaan AJAX bukanlah suatu kepastian, dan seharusnya tidak diperlakukan sebagai berhasil sampai mereka selesai, tetapi begitu banyak aplikasi web utama beroperasi begitu saja.

Apakah situs web ini yang menggunakan panggilan AJAX non-pemblokiran untuk mensimulasikan aplikasi responsif mengambil risiko yang tidak perlu dengan biaya muncul dengan cepat?

Apakah ini pola desain yang harus kita semua ikuti agar tetap kompetitif?


20
Ini dibenarkan oleh kenyataan bahwa operasi yang sukses jauh lebih mungkin, oleh karena itu lambat hanya untuk menghindari kasus umpan balik yang terlalu optimistis yang jarang terjadi merupakan pertukaran yang buruk. Ditransposisikan ke hubungan pribadi, apakah Anda lebih suka berinteraksi dengan orang yang tenang, cerah atau orang yang dengan tegas berasumsi bahwa segala sesuatu yang salah akan salah dan bertindak sesuai?
Kilian Foth

1
Bagi saya, apa yang saya perjuangkan, adalah bahwa aplikasi desktop memiliki operasi dan kesalahan segera terjadi. Sedangkan, dengan aplikasi web operasi terjadi segera, tetapi kesalahannya tertunda. Namun, situs beroperasi dengan desain aplikasi desktop.
Reactgular

7
Pernahkah Anda mempertimbangkan apa yang terjadi ketika aplikasi desktop Anda menulis ke disk, sebenarnya masuk ke buffer OS, dan disk gagal sebelum dapat ditulis ke platter? Atau, dalam hal ini, disk gagal setelah byte ditulis ke platter. Dalam kedua kasus, pengguna berpikir bahwa sesuatu telah terjadi padahal sebenarnya tidak.
kdgregory

2
@KilianFoth Saya lebih suka orang yang menganggap semuanya bisa salah, jika orang yang "cerah" akan meninju Anda dan mencuri dompet Anda pada tanda pertama masalah. Jadi itu tergantung pada skala reaksi halaman tentang kegagalan.
Izkata

1
@ButtleButkus Saya pikir pesan-pesan penyimpanan itu baru. Mereka tidak ada di sana ketika saya mengajukan pertanyaan. Saya perhatikan google menambahkan lebih banyak umpan balik akhir-akhir ini yang melakukan hal-hal di latar belakang.
Reactgular

Jawaban:


62

Ini bukan kinerja "palsu" yang terlalu responsif. Ada beberapa alasan mengapa itu populer:

  • Koneksi internet saat ini cukup dapat diandalkan. Risiko kegagalan permintaan AJAX sangat rendah.
  • Operasi yang dilakukan tidak terlalu kritis terhadap keselamatan. Jika email Anda tidak terhapus di server, hal terburuk yang terjadi adalah Anda harus menghapusnya lagi saat berikutnya Anda mengunjungi halaman tersebut.
  • Anda dapat mendesain halaman Anda untuk membatalkan tindakan jika permintaan gagal, tetapi Anda tidak benar-benar harus halus karena itu berarti koneksi Anda ke server terputus. Lebih mudah untuk mengatakan "Koneksi terputus. Tidak dapat menyimpan perubahan terbaru. Coba lagi nanti."
  • Anda dapat mendesain halaman Anda untuk hanya membolehkan satu permintaan AJAX yang tertunda, sehingga keadaan Anda tidak akan terlalu tidak sinkron dari server.
  • Browser memperingatkan Anda jika Anda mencoba untuk menutup atau menavigasi dari halaman saat permintaan AJAX tertunda.

AJAX menunggu peringatan


8
Poin terakhir itu, apakah semua browser melakukannya secara default?
Svish

Saya tidak tahu Saya hanya mengujinya di IE9 dan chrome terbaru.
Karl Bielefeldt

3
Anda jelas tidak mengenal Internet Australia, belum lagi tempat-tempat miskin, berkembang, dan terpencil, bahkan yang bergerak dengan kendaraan yang bergerak ...
hippietrail

2
@ Hippietrail Ya, Anda tidak bisa membuat semua orang bahagia sepanjang waktu.
KOVIKO

1
Ketika pengguna mengirim permintaan, dia tidak selalu meminta halaman baru. Saya pikir aplikasi AJAX yang dirancang dengan baik dapat membuatnya lebih menyenangkan, membuat pengguna tahu apa yang terjadi lebih efisien daripada dengan memuat ulang.
Frederik.L

32

Mengasumsikan sesuatu akan berfungsi dan menampilkan kesalahan jika gagal di sisi jauh lebih ramah pengguna daripada memblokir pengguna dari melakukan hal lain sampai ada respons dari server.

Klien email sebenarnya adalah contoh yang bagus untuk ini: Ketika saya memiliki daftar dengan 5 email dan yang teratas dipilih, saya berharap bahwa ketika menekan DELtiga kali tiga email pertama dihapus. Dengan "nonblocking AJAX" ini berfungsi dengan baik - setiap kali saya menekan tombol, email yang dipilih segera dihapus. Jika terjadi kesalahan, ditampilkan dan email yang tidak terhapus dengan benar ditampilkan lagi ATAU halaman dimuat ulang untuk menghilangkan keadaan lokal yang tidak konsisten.

Jadi dalam kasus yang paling umum - itu adalah kesuksesan - itu meningkatkan kegunaan. Dalam kasus yang jarang terjadi - kegagalan - kegunaan didegradasi (elemen yang dihapus muncul lagi atau aplikasi "restart") tetapi ketika membuat aplikasi Anda biasanya ingin memiliki kegunaan terbaik untuk kasus-kasus umum, bukan dalam hal kesalahan.


1
+1 ini tepat di jantung masalahnya. Ada begitu banyak keamanan yang diterapkan orang standar hari ini sehingga dalam skenario terburuk Anda masih tidak mengambil risiko kesalahan pengguna yang sebenarnya: bayangkan klien email gagal dihapus, sekarang keadaan lokal buruk, dan mereka mencoba menghapus email 4 yang tidak selaras dengan server, sebagian besar pengembang back-end akan memiliki tangkapan keamanan di sana untuk memastikan Anda hanya menghapus apa yang benar-benar diinginkan pengguna dan karenanya ketidaksejajaran ini tidak akan menyebabkan penghapusan yang salah (mungkin gagal karena kesalahan tetapi tidak akan menghapus) .
Jimmy Hoffa

@JimmyHoffa Anda akan menggunakan id email unik dalam permintaan penghapusan. Akan sangat buruk untuk mengirim permintaan penghapusan berdasarkan urutan tampilan surel dari surel di kotak masuk Anda.
Buttle Butkus

14

Para pengguna tidak peduli dengan apa yang dilakukan perangkat lunak Anda di belakang layar: mereka ingin tindakan mereka memiliki dampak yang terlihat, dan dapat bekerja sesuai kecepatan mereka.

Jika suatu tindakan berhasil di sisi klien - seperti menghapus email - itu tugas Anda untuk membuatnya berhasil di sisi server juga. Mengapa penghapusan gagal? Jika itu disebabkan oleh beberapa jenis pembatasan (misalnya, Anda tidak dapat menghapus email yang telah diarsipkan), pengguna harus mengetahui hal itu sebelum tindakannya gagal.

Jika kesalahan disebabkan oleh sesuatu yang lebih parah (misalkan terjadi kerusakan basis data), Anda harus memiliki cara untuk menyimpan operasi dan mencoba kembali ketika sistem menyala lagi.

Contoh pengelolaan yang baik adalah cara Facebook menangani obrolan. Tidak ada cara untuk menghentikan pengguna dari memutuskan tiba-tiba, yang berarti mereka tidak akan dapat membaca pesan yang Anda kirim sebelum mereka pergi. Alih-alih menampilkan kesalahan, sistem menyimpan semua pesan itu dan membuatnya tersedia bagi pengguna ketika ia kembali. Tidak ada data yang hilang.


2
+1. Contoh obrolan yang luar biasa. Sebagian besar pengguna mengharapkan pesan mereka segera tersedia untuk semua orang, dan karena pesan seperti itu jarang gagal, pengguna diberi ilusi bahwa itulah masalahnya.
Neil

1
@Niphra, "Mengapa penghapusan gagal?" Jaringan dapat gagal karena berbagai alasan, yang tidak ada hubungannya dengan aplikasi Anda. Tidak ada yang bisa Anda lakukan untuk menghentikannya.
Pacerier

5

Anda dapat berkompromi antara dua opsi. Misalnya, jika pengguna menghapus email, Anda bisa menandainya merah atau abu-abu sampai Anda mendapatkan konfirmasi kembali dari server, dan hanya kemudian menghapusnya dari daftar. Pengguna masih dapat melakukan hal-hal lain saat satu tindakan tertunda, sehingga tidak memblokir, tetapi masih menyisakan sedikit pengingat bagi pengguna bahwa tindakan mereka belum dilakukan.

Amazon AWS mengambil pendekatan ini: ketika Anda menghentikan / memulai sebuah instance, kotak centang yang memungkinkan Anda untuk memilihnya berubah menjadi pemintal (sehingga Anda tidak dapat melakukan apa pun untuk itu selama beberapa detik), tetapi ini tidak menghalangi Anda dari berinteraksi dengan contoh lain.


Saran Anda mirip dengan bagaimana gmail menampilkan "Menyimpan ..." saat XHR berjalan, dan "Disimpan" setelah selesai. Jika selalu mengatakan "Disimpan," siapa yang akan percaya?
Buttle Butkus

3

Saya pikir, ini datang bersama dengan semakin banyak situs web yang mencoba berperilaku seperti Aplikasi dan melakukan lebih banyak pemrosesan di browser (seperti memvalidasi data formulir) daripada situs yang lebih tradisional. Saya tidak melihat terlalu banyak masalah selama kode Anda dapat diandalkan dan Anda dapat mengharapkannya berhasil dalam kondisi normal.

Anda mengatakan "Ini saat ini bahwa kode JavaScript menemukan permintaan AJAX gagal. Skrip dapat menampilkan pesan kesalahan, tetapi saat ini benar-benar tidak ada gunanya."

Mengapa itu tidak ada gunanya? Anda dapat kembali ke daftar EMail dan melakukan penghapusan lagi. Kenapa harus menunggu saja? Sebenarnya tidak ada banyak "risiko" dan mereka tidak "tampak" cepat, mereka sebenarnya bekerja lebih cepat. Jadi kalau aktivitasnya tidak "kritis" kenapa harus lambat?


1
Mungkin pointless bukanlah kata yang tepat, tetapi yang saya maksud adalah bahwa pesan kesalahan tidak memiliki konteks relatif, karena pengguna sekarang melakukan sesuatu yang sama sekali berbeda. Saya coba katakan, apakah itu untuk pengguna web yang bodoh, mereka pikir emailnya berhasil dihapus. Jadi mengapa sekarang, nanti, mereka mendapatkan pesan kesalahan karena sesuatu yang mereka "lihat" dihapus. Bagi kami programmer, kami mengerti, tetapi untuk kakek yang menggunakan gmail mereka tidak akan mengerti.
Reactgular

Kebanyakan orang lebih suka menggunakan aplikasi di mana hal-hal terjadi segera, sistem responsif dan ada kemungkinan 1 dalam 10.000 UI dapat memperbarui dengan cara yang aneh pada kesalahan daripada aplikasi yang membeku selama satu detik setiap kali mereka mengubah nilai.
Gort the Robot

1

2c saya adalah: ada situasi di mana lebih baik untuk memiliki, seperti yang Anda katakan, "non-blocking" operasi Ajax dan lain-lain di mana itu adalah pilihan desain yang buruk. Contoh: memilih video YouTube. Anda tidak benar-benar ingin bagian halaman diblokir saat Anda mengklik pada sedikit mulai di sana. Lebih baik gagal secara diam-diam. Bahkan pesan konfirmasi akan dibunuh berlebihan. Namun contoh Anda dengan penghapusan email, saya akan memenuhi syarat sebagai wajib untuk memblokir permintaan tipe Ajax.

Mongo DB melakukan sesuatu seperti itu (dan ini dapat dianggap sebagai contoh aplikasi Desktop). Mereka memiliki berbagai "Tulis Masalah" untuk operasi mereka, dan Anda dapat mengonfigurasinya ke nilai yang berbeda untuk setiap operasi, mulai dari "segera kembali dan jangan menunggu apa pun" hingga "diblok sampai Anda telah mengkonfirmasi transfer jaringan yang berhasil dan lalu kembali "ke" tunggu hingga konten dijadwalkan dengan benar untuk penulisan disk pada mesin jarak jauh sebelum Anda kembali ". Jelas, jika Anda membuat klien tebal Desktop (seperti C ++) menggunakan driver Mongo, Anda akan mengatur masalah penulisan paling ringan untuk operasi db dari "kekritisan" minimal (seperti memeriksa email baru), dan yang lainnya pada masalah penulisan yang lebih ketat .

Sementara saya melihat manfaat Ajax yang tidak menghalangi, saya setuju dengan Anda bahwa itu terjadi terlalu banyak. Pada suatu titik ada setidaknya satu situs "jejaring sosial" terkenal yang akan melakukan ini untuk mengunggah foto. Anda telah memilih foto Anda untuk diunggah dan kemudian di-bam, segera itu akan memberi tahu Anda bahwa itu selesai, dan kemudian cukup yakin pada hari berikutnya ketika Anda ingin menambahkan beberapa foto lagi (atau menggunakan yang menurut Anda sudah Anda tambahkan), itu tidak pernah ditemukan. Kemudian mereka menyerah pada hal ini, dan benar-benar meluangkan waktu untuk menunggu tanggapan (dan Anda memang terkadang mendapatkan pesan seperti "gagal mengunggah foto, coba nanti").


+1 untuk melihat semuanya dengan cara saya :). Pengunggahan foto adalah contoh yang bagus jika gagal.
Reactgular

1
Mengapa mengunggah pemblokiran lebih disukai? Di Picasa (antarmuka web), Anda dapat menyeret foto ke dalam, dan saat mereka mengunggah di latar belakang, Anda dapat menarik lebih banyak, atau menandai foto yang sudah selesai, dll. Operasi pemblokiran pemblokiran akan membuat UX yang mengerikan
BLSully
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.