Quanto sono sicure le richieste nascoste di AJAX per prestazioni fasulle?

Che cos'è una richiesta AJAX nascosta?

Ho notato un aumento dell'utilizzo delle richieste AJAX nascoste progettate per far sembrare che l'azione dell'utente si verifichi immediatamente. Farò riferimento a questo tipo di richiesta AJAX come non bloccante. È una richiesta AJAX fatta senza che l'utente sia consapevole del fatto che sta accadendo, viene eseguita in background e il suo funzionamento è silenzioso ( non vi è alcun dettaglio per indicare un completamento riuscito della chiamata AJAX ). L'obiettivo è far sembrare che l'operazione sia avvenuta immediatamente quando non è ancora terminata.

Ecco alcuni esempi di richiesta AJAX non bloccante;

• I clic dell'utente vengono eliminati in una raccolta di e-mail. Gli oggetti scompaiono immediatamente dalla loro casella di posta e possono continuare con altre operazioni. Nel frattempo, una richiesta AJAX sta elaborando la cancellazione degli elementi in background.
• L'utente compila un modulo per i nuovi record. Clic salva. Il nuovo elemento appare immediatamente nell'elenco. L'utente può continuare ad aggiungere nuovi record.

Per chiarire, ecco alcuni esempi di blocco della richiesta AJAX;

• I clic dell'utente vengono eliminati in una raccolta di e-mail. Viene visualizzato un cursore a clessidra. Viene effettuata la richiesta AJAX e quando risponde il cursore a clessidra viene disattivato. L'utente deve attendere un secondo per il completamento dell'operazione.
• L'utente compila un modulo per i nuovi record. Clic salva. Il modulo diventa grigio con l'animazione di un caricatore AJAX. Viene visualizzato un messaggio "I tuoi dati sono stati salvati" e il nuovo record viene visualizzato nell'elenco.

La differenza tra i due scenari precedenti è che una configurazione AJAX non bloccante non fornisce il feedback di una prestazione operativa e una configurazione AJAX bloccante.

Il rischio di richieste nascoste AJAX

Il rischio maggiore di questo stile di richiesta AJAX è che l'applicazione Web potrebbe trovarsi in uno stato completamente diverso quando la richiesta AJAX fallisce.

Ad esempio, un esempio non bloccante;

• L'utente seleziona un gruppo di e-mail. Fai clic sul pulsante Elimina. L'operazione sembra avvenire immediatamente (gli elementi scompaiono dall'elenco). L'utente quindi fa clic sul pulsante Scrivi e inizia a digitare una nuova e-mail. È in questo momento che il codice JavaScript rileva la richiesta AJAX non riuscita. Lo script potrebbe mostrare un messaggio di errore, ma al momento è davvero inutile.

In alternativa, un esempio di blocco;

• L'utente seleziona un gruppo di e-mail. Fai clic sul pulsante Elimina. Vede una clessidra, ma l'operazione non riesce. Ricevono un messaggio di errore che dice "errore. Blah blah blah". Vengono restituiti all'elenco di e-mail e hanno ancora le e-mail che volevano eliminare selezionate. Potrebbero tentare di eliminarli di nuovo.

Esistono anche altri rischi tecnici per l'esecuzione di richieste AJAX non bloccanti. L'utente potrebbe chiudere il browser, navigare su un altro sito Web e accedere a un'altra posizione nel Web corrente che rende insignificante il contesto di qualsiasi risposta di errore.

Allora perché sta diventando così popolare?

Facebook, Google, Microsoft, ecc. Ecc. Tutti questi grandi domini utilizzano sempre più richieste AJAX non bloccanti per far sembrare che le operazioni vengano eseguite all'istante. Ho anche visto un aumento degli editor di moduli che non hanno pulsanti di salvataggio o invio . Non appena lasci un campo o premi invio. Il valore è salvato Non è presente il tuo profilo è stato aggiornato il messaggio o il passaggio di salvataggio.

Le richieste AJAX non sono una certezza e non dovrebbero essere trattate come riuscite fino a quando non sono state completate, ma così tante applicazioni Web importanti funzionano in questo modo.

Questi siti Web che utilizzano chiamate AJAX non bloccanti per simulare applicazioni reattive corrono un rischio non necessario a costo di apparire velocemente?

È questo un modello progettuale che tutti dovremmo seguire per rimanere competitivi?

Non è tanto una prestazione "falsa" quanto una reattività reale. Ci sono una serie di motivi per cui è popolare:

• Le connessioni Internet sono abbastanza affidabili al giorno d'oggi. Il rischio di fallimento di una richiesta AJAX è molto basso.
• Le operazioni eseguite non sono realmente critiche per la sicurezza. Se le tue e-mail non vengono eliminate sul server, la cosa peggiore è che devi eliminarle di nuovo la prossima volta che verrai sulla pagina.
• Puoi progettare la tua pagina per annullare l'azione se la richiesta fallisce, ma non devi essere così sottile perché significa che la tua connessione al server è interrotta. È più facile dire "Connessione persa. Impossibile salvare le modifiche recenti. Riprovare più tardi."
• Puoi progettare la tua pagina in modo da consentire solo una richiesta AJAX in sospeso, in modo che il tuo stato non venga fuori sincronizzato dal server.
• Il browser ti avvisa se provi a chiudere o ad allontanarti da una pagina mentre è in sospeso una richiesta AJAX.

Supponendo che qualcosa funzionerà e che visualizzi un errore nel caso in cui si verifichi un errore sul lato remoto è molto più user-friendly che impedire all'utente di fare qualsiasi altra cosa fino a quando non c'è una risposta dal server.

Un client di posta elettronica è in realtà un ottimo esempio per questo: quando ho un elenco con 5 e-mail e viene selezionata la prima, mi aspetto che quando si colpisce DELtre volte le prime tre e-mail vengono eliminate. Con "AJAX non bloccante" funziona perfettamente: ogni volta che premo il tasto l'e-mail selezionata viene rimossa immediatamente. Se qualcosa va storto, viene visualizzato un errore e vengono nuovamente visualizzate le e-mail non correttamente cancellate OPPURE la pagina viene ricaricata per eliminare lo stato locale incoerente.

Quindi, nel caso più comune - questo è successo - migliora l'usabilità. Nel raro caso - fallimento - l'usabilità è degradata (l'elemento cancellato appare di nuovo o l'applicazione viene "riavviata") ma quando si crea un'applicazione di solito si desidera avere la migliore usabilità per casi comuni, non in caso di errori.

Agli utenti non importa cosa sta facendo il tuo software dietro le quinte: vogliono che le loro azioni abbiano un impatto visibile e siano in grado di lavorare al loro ritmo.

Se un'azione ha avuto esito positivo sul lato client, ad esempio l'eliminazione di e-mail, è compito tuo riuscire anche sul lato server. Perché la cancellazione non è riuscita? Se è a causa di un qualche tipo di limitazione (ad esempio, non è possibile rimuovere un messaggio di posta elettronica che è stato archiviato), l'utente dovrebbe esserne informato prima che la sua azione fallisse.

Se l'errore è causato da qualcosa di più grave (diciamo un arresto anomalo del database), dovresti avere un modo per salvare l'operazione e riprovare quando il sistema è di nuovo attivo.

Un buon esempio di gestione di questo è il modo in cui Facebook gestisce la chat. Non c'è modo di impedire a un utente di disconnettersi improvvisamente, il che significa che non saranno in grado di leggere i messaggi inviati prima di partire. Invece di visualizzare un errore, il sistema salva tutti quei messaggi e li rende disponibili all'utente al suo ritorno. Nessun dato è perso.

Puoi scendere a compromessi tra le due opzioni. Ad esempio, se l'utente elimina un messaggio di posta elettronica, è possibile contrassegnarlo in rosso o grigio fino a quando non si ottiene una conferma dal server e solo successivamente rimuoverlo dall'elenco. L'utente può ancora fare altre cose mentre è in corso un'azione, quindi non si blocca, ma lascia comunque un piccolo promemoria per l'utente che le sue azioni non sono ancora state commesse.

Amazon AWS adotta questo approccio: quando interrompi / avvii un'istanza, la casella di controllo che ti consente di selezionarla si trasforma in uno spinner (quindi non puoi farci nulla per alcuni secondi), ma questo non ti impedisce di interagendo con altre istanze.

Penso che questo si unisca a un numero sempre maggiore di siti Web che provano a comportarsi come Applicazioni e fanno più elaborazioni nel browser (come la convalida dei dati dei moduli) rispetto ai siti più tradizionali. Non vedo troppi problemi in quanto il tuo codice è affidabile e puoi aspettarti che abbia successo in condizioni normali.

Dici "È in questo momento che il codice JavaScript scopre che la richiesta AJAX non è riuscita. Lo script potrebbe mostrare un messaggio di errore, ma al momento non ha senso."

Perché dovrebbe essere inutile? È possibile tornare indietro nell'elenco di e-mail ed eseguire nuovamente l'eliminazione. Perché aspettare invece? In realtà non esiste un "rischio" e non "sembrano" essere veloci, in realtà funzionano più velocemente. Quindi se l'attività non è "critica", perché essere lento?

Il mio 2c è: ci sono situazioni in cui è meglio avere, come dici tu, operazioni Ajax "non bloccanti" e altre in cui è una cattiva scelta progettuale. Esempio: votazione di un video di YouTube. Non vuoi davvero che nessuna parte della pagina venga bloccata mentre fai clic sul piccolo inizia lì. È meglio fallire silenziosamente. Anche un messaggio di conferma verrebbe ucciso. Tuttavia, il tuo esempio con l'eliminazione dell'email mi qualificherebbe come obbligatorio per la richiesta Ajax di tipo bloccante.

Mongo DB fa qualcosa del genere (e questo potrebbe essere considerato come un esempio di applicazione desktop). Hanno varie "preoccupazioni di scrittura" per le loro operazioni e puoi configurarlo su valori diversi per ogni operazione, che vanno da "torna subito e non aspettare nulla" a "bloccare fino a quando non avrai la conferma del corretto trasferimento di rete e quindi ritorna "a" attendi che il contenuto sia correttamente programmato per la scrittura su disco sul computer remoto prima del tuo ritorno ". Ovviamente, se crei un client spesso desktop (come in C ++) usando il driver Mongo, imposteresti la più leggera preoccupazione di scrittura per operazioni db di minima "criticità" (come il controllo di nuove e-mail), e altre su preoccupazioni di scrittura più rigide .

Mentre vedo l'utilità di Ajax non bloccante, sono d'accordo con te sul fatto che sta accadendo troppo. Ad un certo punto c'era almeno un famoso sito di "social network" che lo avrebbe fatto per il caricamento di foto. Hai scelto la tua foto da caricare e poi bam, subito ti direbbe che è stato fatto, e quindi abbastanza sicuro il giorno successivo quando volevi aggiungere qualche altra foto (o usarla su quello che pensavi di aver già aggiunto), non è mai stato trovato. Più tardi hanno rinunciato a questo, e in realtà si sono presi il tempo di aspettare la risposta (e in effetti a volte si ricevevano messaggi come "impossibile caricare foto, provare più tardi").