Qual a segurança das solicitações ocultas do AJAX com desempenho falso?

O que é uma solicitação AJAX oculta?

Percebi um aumento no uso de solicitações ocultas de AJAX, projetadas 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 sem bloqueio. É uma solicitação AJAX feita sem que o usuário esteja ciente de que está acontecendo, é executada em segundo plano e sua operação é silenciosa ( não há detalhes 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 exemplos de solicitação AJAX sem bloqueio;

• O usuário clica em excluir em uma coleção de emails. 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. Cliques salvar. O novo item aparece na lista imediatamente. O usuário pode continuar adicionando novos registros.

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

• O usuário clica em excluir em uma coleção de emails. Um cursor de ampulheta é exibido. A solicitação AJAX é feita e, quando responde, o cursor da ampulheta é desativado. O usuário precisa esperar um segundo para que a operação seja concluída.
• O usuário preenche um formulário para novos registros. Cliques salvar. O formulário fica cinza com um carregador AJAX animado. 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 do desempenho operacional e uma configuração AJAX bloqueada.

O risco de solicitações ocultas de AJAX

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

Por exemplo, um exemplo sem bloqueio;

• O usuário seleciona vários e-mails. Clica no botão excluir. A operação parece ocorrer imediatamente (os itens desaparecem da lista). O usuário clica 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 AJAX falhou. O script pode mostrar uma mensagem de erro, mas é realmente inútil no momento.

Como alternativa, um exemplo de bloqueio;

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

Há 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 sem sentido o contexto de qualquer resposta a erro.

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

Facebook, Google, Microsoft, etc. etc .. todos esses grandes domínios estão cada vez mais usando solicitações AJAX sem bloqueio para fazer com que as operações pareçam ser executadas instantaneamente. Também vi um aumento nos editores de formulários que não têm botão de salvar ou enviar . Assim que você deixar um campo ou pressione enter. O valor é salvo. Não há mensagem de seu perfil atualizada ou etapa de salvamento.

As solicitações AJAX não são uma certeza e não devem ser tratadas como bem-sucedidas até que sejam concluídas, mas muitos aplicativos principais da web estão operando assim.

Esses sites que usam chamadas AJAX sem bloqueio para simular aplicativos responsivos assumem um risco desnecessário com o custo de aparecer rapidamente?

Esse é um padrão de design que todos nós devemos seguir para permanecermos competitivos?

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

• Atualmente, as conexões com a Internet são razoavelmente confiáveis. O risco de uma solicitação AJAX falhar é muito baixo.
• As operações que estão sendo executadas não são realmente críticas à segurança. Se seus e-mails não forem excluídos no servidor, o pior é que você precisará excluí-los novamente na próxima vez que chegar à página.
• Você pode criar sua página para desfazer a ação se a solicitação falhar, mas não precisa ser tão sutil porque isso significa que sua conexão com o servidor está interrompida. É 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 sincronizado com o servidor.
• O navegador avisa se você tentar fechar ou navegar para fora de uma página enquanto uma solicitação AJAX estiver pendente.

Assumir que algo funcione e exibir um erro, caso falhe no lado remoto, é muito mais fácil do que impedir o usuário de fazer qualquer outra coisa até que haja uma resposta do servidor.

Um cliente de e-mail é realmente um ótimo exemplo disso: quando tenho uma lista com 5 e-mails e o principal é selecionado, espero que ao acessar DELtrês vezes os três primeiros sejam excluídos. Com "AJAX nonblocking", isso funciona bem - toda vez que eu pressiono a tecla, o email selecionado é removido imediatamente. Se algo der errado, um erro será mostrado e os emails não excluídos corretamente serão mostrados novamente OU a página será recarregada para se livrar do estado local inconsistente.

Portanto, no caso mais comum - que é sucesso -, melhora a usabilidade. No raro caso - falha - a usabilidade é prejudicada (o elemento excluído aparece novamente ou o aplicativo é "reiniciado"), mas ao criar um aplicativo, geralmente você deseja ter a melhor usabilidade para casos comuns, não para erros.

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

Se uma ação foi bem-sucedida no lado do cliente - como a exclusão de e-mails -, é seu trabalho torná-la bem-sucedida 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 foi arquivado), o usuário deve ser informado disso antes que sua ação falhe.

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

Um bom exemplo de como gerenciar isso é a maneira como o Facebook lida com o bate-papo. Não há como impedir que um usuário se desconecte repentinamente, o que significa que ele não poderá ler as mensagens enviadas antes de sair. Em vez de exibir um erro, o sistema salva todas essas mensagens e as disponibiliza ao usuário quando ele voltar. Nenhum dado é perdido.

Você pode se comprometer entre as duas opções. Por exemplo, se o usuário excluir um email, você poderá marcá-lo em vermelho ou cinza até receber uma confirmação de volta do servidor e, em seguida, 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 selecioná-la se transforma em giratória (para que você não possa fazer nada por alguns segundos), mas isso não impede você de interagindo com outras instâncias.

Eu acho que isso vem junto com mais e mais sites que tentam se comportar como aplicativos e executam mais processamento no navegador (como validar dados do formulário) do que os sites mais tradicionais. Não vejo muitos problemas, desde que seu código seja confiável e você possa esperar que ele seja bem-sucedido em condições normais.

Você diz: "É nesse momento que o código JavaScript descobre que a solicitação AJAX falhou. O script pode mostrar uma mensagem de erro, mas é realmente inútil no momento".

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

Meu 2c é: há situações em que é melhor ter, como você diz, "operações sem bloqueio" do Ajax e outras em que é uma má escolha de design. Exemplo: votando em um vídeo do YouTube. Você realmente não deseja que nenhuma parte da página seja bloqueada enquanto clica nos pequenos começos lá. É melhor falhar silenciosamente. Até uma mensagem de confirmação seria exagerada. No entanto, seu exemplo com exclusão de e-mail seria qualificado como obrigatório para a solicitação do tipo Ajax de bloqueio.

O Mongo DB faz algo assim (e isso pode ser considerado como um exemplo de aplicativo da área de trabalho). Eles têm vários "Preocupações de gravação" para suas operações, e você pode configurá-lo com valores diferentes para cada operação, variando entre "retornar imediatamente e não esperar por nada" para "bloquear até confirmar a transferência e o êxito da transferência de rede". em seguida, retorne "para" aguarde até que o conteúdo esteja devidamente programado para gravação em disco na máquina remota antes do seu retorno ". Obviamente, se você criar um cliente espesso para a área de trabalho (como C ++) usando o driver Mongo, definiria a preocupação de gravação mais leve para operações de banco de dados com um mínimo de "criticidade" (como verificar novos emails) e outras sobre preocupações de gravação mais estritas .

Enquanto vejo a utilidade do Ajax sem bloqueio, concordo com você que isso está acontecendo demais. A certa altura, havia pelo menos um site famoso de "rede social" que faria isso para o upload de fotos. Você escolheu sua foto para fazer o upload e, em seguida, bam, imediatamente lhe diria que está pronta e, 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, demoraram um pouco a esperar pela resposta (e você às vezes recebia mensagens como "falha ao enviar a foto, tente mais tarde").