Quão seguros estão ocultos O AJAX solicita esse desempenho falso?

47

O que é um pedido AJAX oculto?

Eu notei um aumento no uso de solicitações AJAX ocultas criadas para fazer com que a ação de um usuário pareça acontecer imediatamente. Vou me referir a esse tipo de solicitação AJAX como não bloqueante. É um pedido AJAX feito sem que o usuário esteja ciente de que está acontecendo, ele é executado em segundo plano e sua operação é silenciosa ( não há nenhum verbose para indicar uma conclusão bem-sucedida da chamada AJAX ). O objetivo é fazer com que a operação pareça que aconteceu imediatamente quando realmente não terminou.

Aqui estão alguns exemplos de solicitações AJAX sem bloqueio;

  • O usuário clica em excluir em uma coleção de e-mails. Os itens desaparecem imediatamente da caixa de entrada e podem continuar com outras operações. Enquanto isso, uma solicitação AJAX está processando a exclusão dos itens em segundo plano.
  • O usuário preenche um formulário para novos registros. Clica em salvar. O novo item aparece na lista imediatamente. O usuário pode continuar adicionando novos registros.

Para esclarecer, aqui estão alguns exemplos de bloqueio de solicitações AJAX;

  • O usuário clica em excluir em uma coleção de e-mails. Um cursor de ampulheta aparece. A solicitação do AJAX é feita e, quando responde, o cursor da ampulheta é desativado. O usuário precisa aguardar um segundo para concluir a operação.
  • O usuário preenche um formulário para novos registros. Clica em salvar. A forma fica cinza com uma animação do carregador AJAX. Uma mensagem é exibida "Seus dados foram salvos" e o novo registro aparece na lista.

A diferença entre os dois cenários acima é que uma configuração AJAX sem bloqueio não fornece feedback de um desempenho operacional e uma configuração de AJAX de bloqueio.

O risco de solicitações ocultas de AJAX

O maior risco desse estilo de solicitação AJAX é que o aplicativo da Web pode estar em um estado completamente diferente quando a solicitação do AJAX falhar.

Por exemplo, um exemplo sem bloqueio;

  • O usuário seleciona vários emails. Clica no botão de exclusão. A operação parece acontecer imediatamente (os itens simplesmente desaparecem da lista). O usuário clica então no botão de composição e começa a digitar um novo email. É nesse momento que o código JavaScript descobre que a solicitação do AJAX falhou. O script pode mostrar uma mensagem de erro, mas realmente não faz sentido no momento.

Como alternativa, um exemplo de bloqueio;

  • O usuário seleciona vários emails. Clica no botão de exclusão. Vê uma ampulheta, mas a operação falha. Eles recebem uma mensagem de erro dizendo "error. Blah blah blah". Eles retornam à lista de e-mails e ainda têm os e-mails que desejam excluir selecionados. Eles poderiam tentar excluí-los novamente.

Existem também outros riscos técnicos para executar solicitações AJAX sem bloqueio. O usuário pode fechar o navegador, navegar para outro site e navegar para outro local na Web atual que torne o contexto de qualquer resposta de erro sem sentido.

Então, por que está se tornando tão popular?

Facebook, Google, Microsoft, etc .. etc. todos esses grandes domínios estão usando cada vez mais pedidos não-bloqueantes de AJAX para fazer com que as operações apareçam que são realizadas instantaneamente. Eu também vi um aumento nos editores de formulários que não têm salvar ou enviar o botão. Assim que você sair de um campo ou pressione enter. O valor é salvo. Não há nenhuma mensagem seu perfil atualizado ou etapa de salvamento.

As solicitações de AJAX não são uma certeza e não devem ser tratadas como bem-sucedidas até que sejam concluídas, mas muitas das principais aplicações da Web estão funcionando exatamente assim.

Esses sites usam chamadas AJAX sem bloqueio para simular aplicativos responsivos, assumindo um risco desnecessário ao custo de aparecer rapidamente?

Este é um padrão de design que todos devemos seguir para nos mantermos competitivos?

    
por cgTag 31.01.2013 / 16:36
fonte

6 respostas

62

Não é tanto o desempenho "falso" quanto a capacidade de resposta real. Existem várias razões pelas quais é popular:

  • Conexões com a Internet são bastante confiáveis hoje em dia. O risco de uma solicitação do AJAX falhar é muito baixo.
  • As operações que estão sendo executadas não são realmente críticas para a segurança. Se seus e-mails não forem excluídos no servidor, o pior que acontece é que você precisa excluí-los na próxima vez que acessar a página.
  • Você pode criar sua página para desfazer a ação se a solicitação falhar, mas você não precisa ser tão sutil porque isso significa que sua conexão com o servidor está quebrada. É mais fácil dizer "Conexão perdida. Não é possível salvar as alterações recentes. Tente novamente mais tarde".
  • Você pode criar sua página para permitir apenas uma solicitação AJAX pendente, para que seu estado não fique muito fora de sincronia do servidor.
  • O navegador avisa se você tentar fechar ou sair de uma página enquanto uma solicitação AJAX está pendente.

    
por 31.01.2013 / 17:06
fonte
32

Supondo que algo funcionará e exibindo um erro caso ele falhe no lado remoto é muito mais fácil de usar do que bloquear o usuário de fazer qualquer outra coisa até que haja uma resposta do servidor.

Um cliente de e-mail é um exemplo ótimo para isso: Quando eu tenho uma lista com 5 e-mails e a parte superior é selecionada, espero que acesse DEL três vezes os três primeiros emails são excluídos. Com "AJAX sem bloqueio", isso funciona bem - toda vez que clico na tecla, o e-mail selecionado é removido imediatamente. Se algo der errado, um erro será exibido e os e-mails não excluídos adequadamente serão mostrados novamente OU a página será recarregada para se livrar do estado local inconsistente.

Portanto, no caso mais comum - isso é sucesso - melhora a usabilidade. No caso raro - falha - a usabilidade é degradada (o elemento excluído é exibido novamente ou o aplicativo é "reiniciado"), mas ao criar um aplicativo geralmente é necessário ter a melhor usabilidade para casos comuns, não em caso de erros.

    
por 31.01.2013 / 16:53
fonte
14

Os usuários não se importam com o que seu software está fazendo nos bastidores: eles querem que suas ações tenham um impacto visível e que possam trabalhar em seu ritmo.

Se uma ação for bem-sucedida no lado do cliente, como excluir e-mails, o seu trabalho também será bem-sucedido no lado do servidor. Por que a exclusão falhou? Se for devido a algum tipo de limitação (por exemplo, você não pode remover um email que tenha sido arquivado), o usuário deve estar ciente de que antes sua ação falhou.

Se o erro for causado por algo mais grave (digamos, uma falha no banco de dados), você deve ter uma maneira de salvar a operação e tentar novamente quando o sistema estiver ativo novamente.

Um bom exemplo de como gerenciar isso é o modo como o Facebook lida com o bate-papo. Não há como impedir que um usuário se desconecte de repente, o que significa que não conseguirá ler as mensagens que você enviou antes de saírem. Em vez de exibir um erro, o sistema salva todas as mensagens e as disponibiliza para o usuário quando ele volta. Nenhum dado é perdido.

    
por 31.01.2013 / 17:15
fonte
5

Você pode comprometer entre as duas opções. Por exemplo, se o usuário excluir um email, você poderá marcá-lo em vermelho ou em cinza até receber uma confirmação do servidor e removê-lo da lista. O usuário ainda pode fazer outras coisas enquanto uma ação está pendente, por isso não está bloqueando, mas ainda deixa um pequeno lembrete para o usuário de que suas ações ainda não foram confirmadas.

O Amazon AWS adota essa abordagem: quando você para / inicia uma instância, a caixa de seleção que permite a seleção se transforma em um controle giratório (assim você não pode fazer nada por alguns segundos), mas isso não impedir que você interaja com outras instâncias.

    
por 01.02.2013 / 00:43
fonte
3

Acho que isso vem junto com mais e mais sites que tentam se comportar como aplicativos e fazem mais processamento no navegador (como validar dados de formulários) do que os sites mais tradicionais. Eu não vejo muito problema nisso desde que seu código seja confiável e você pode esperar que ele tenha sucesso sob condições normais.

Você diz "É neste momento que o código JavaScript descobre que a solicitação do AJAX falhou. O script pode mostrar uma mensagem de erro, mas, na verdade, isso é inútil".

Por que deveria ser inútil? Você pode voltar na lista de e-mails e fazer a exclusão novamente. Por que esperar em vez disso? Na verdade, não há muito "risco" e eles não "parecem" rápidos, eles trabalham mais rápido. Então, se a atividade não é "crítica", por que ser lento?

    
por 31.01.2013 / 16:45
fonte
1

Meu 2c é: há situações em que é melhor ter, como você diz, operações Ajax "não-bloqueadoras" e outras onde a escolha é ruim. Exemplo: votar em um vídeo do YouTube. Você não quer que nenhuma parte da página seja bloqueada enquanto você clica no pequeno começo. É melhor falhar silenciosamente. Mesmo uma mensagem de confirmação seria over-kill. No entanto, seu exemplo com exclusão de e-mail eu qualificaria como obrigatório para solicitação de Ajax do tipo de bloqueio.

O Mongo DB faz algo assim (e isso pode ser considerado como um exemplo de aplicativo Desktop). Eles têm várias "Write Concerns" para suas operações, e você pode configurá-lo para valores diferentes para cada operação, desde "retornar imediatamente e não esperar por nada" para "bloquear" até receber confirmação de transferência de rede e em seguida, retorne "para" esperar até que o conteúdo seja agendado adequadamente para gravação em disco na máquina remota antes do seu retorno ". Obviamente, se você criar um cliente thick do Desktop (como C ++) usando o driver Mongo, definiria a preocupação de gravação mais leve para operações de banco de dados de "criticalidade" mínimas (como a verificação de novos emails) e outras questões mais restritas. .

Embora eu veja a utilidade do Ajax sem bloqueio, eu concordo com você que isso está acontecendo demais. Em um ponto, havia pelo menos um famoso site de "redes sociais" que faria isso para o upload de fotos. Você escolheu sua foto para fazer o upload e, em seguida, bam, imediatamente diria que está pronto, e então, no dia seguinte, quando você quiser adicionar mais algumas fotos (ou usar as que você acha que já adicionou), nunca foi encontrado. Mais tarde, eles desistiram disso e, na verdade, tiveram tempo para aguardar a resposta (e, de fato, você às vezes recebia mensagens como "falha ao fazer o upload da foto, tente mais tarde").

    
por 31.01.2013 / 17:53
fonte