Prós / contras entre enfatizar o processamento do lado do cliente ou do servidor

Por que eu gostaria de escrever um aplicativo Web com muito processamento do lado do servidor?

Para mim, escrever o programa no lado do cliente é uma enorme vantagem, pois leva o máximo de carga possível do servidor, porque ele só precisa enviar dados ao cliente com processamento mínimo.

Vejo muito pouco ao escrever aplicativos da Web, além de escrevê-los no lado do servidor e tratar o lado do cliente como apenas uma visualização . Por que eu iria querer fazer isso? A única vantagem que vejo é que posso escrever em qualquer idioma que eu quiser ( http://www.paulgraham.com/avg.html ).

Existem duas questões principais.

1. O primeiro é fácil - você geralmente não sabe que tipo de recursos estão disponíveis no lado do cliente. Se for necessário 1,5 GB para processar algo, você pode realmente enviá-lo para um navegador cliente desconhecido (IE, Safari, Opera, Firefox etc.) em uma plataforma cliente desconhecida? O cliente apreciará seu sistema de dogging quando você o sobrecarregar?

2. A segunda é mais arquitetônica - que camadas você deseja expor para o mundo exterior? A maioria concorda que é incrivelmente arriscado expor sua camada de dados. E a sua camada de serviço? Deseja realmente entregar essa lógica por aí? Se sim, você também está expondo os pontos de entrada para sua camada de dados? Se você mantiver a camada de serviço do lado do servidor, o que resta? A interface do usuário, certo? Consulte o motivo 1 para obter considerações sobre quanto disso vive no servidor e quanto no cliente.

Primeiro e mais importante é a segurança . Envie toda a sua lógica para o cliente e é um jogo justo para hackers e explorações.

Qualquer coisa com qualquer valor percebido não durará 5 minutos, especialmente o valor monetário, e será jogada, invadida ou explorada e quebrará bastante o sistema. Mesmo que tenha pouco ou nenhum valor monetário, há uma classe de pessoas que o invadirão apenas para interromper o sistema porque estão entediadas.

Lado do cliente versus lado do servidor

O processamento do lado do cliente está alinhado com os padrões REST mais populares, bem como com o MVC, em oposição às abordagens baseadas em página e SOAP. O surgimento dessas tendências e o foco no AJAX e no Html-RIA, scripts do lado do cliente, estão aumentando e são mais populares; no entanto, devido a preocupações de segurança e capacidade do cliente, o script do lado do cliente tem um nicho específico e não deve ser usado para tudo.

Considerações:

Móvel

Se um grande segmento do seu público-alvo for usuários móveis, o processamento pesado deve ser deixado para o servidor.

Consistência entre navegadores

Os padrões da Web percorreram um longo caminho e isso pode não ser uma grande preocupação, mas todo desenvolvedor da Web sabe que o IE 6,7 e 8 e às vezes o Safari podem agir de maneira engraçada no lado do cliente - certas funções podem não ser executadas devido a restrições de segurança e outros por causa de padrões não implementados. Também é importante observar que o usuário final pode configurar um navegador para ter certas restrições ou até desativar completamente o processamento no lado do cliente (sem javascript!). Se a consistência é um requisito para 100% dos usuários (e especialmente se você estiver fazendo algo não ortodoxo), o lado do servidor é mais importante.

Segurança

Qualquer manipulação de dados que você deseja proteger precisa ser feita no servidor. Todos os dados processados ​​no lado do cliente estão absolutamente abertos para manipulação. Por exemplo, se você tiver uma função javascript que processa algumas informações que são postadas de volta no sistema - seria muito fácil manipular o resultado imediatamente antes de ser postado de volta, mesmo se você tiver uma segurança de back-end exemplar

UI / UX

O processamento do cliente é deixado para a interface do usuário e para a criação de aplicativos avançados da Internet (RIAs). É usado para criar animações, efeitos, interações do usuário, bem como carregar conteúdo dinamicamente por meio de chamadas AJAX, em vez de recarregar uma página inteira.

Primeiramente, será uma duplicação de esforços. Provavelmente, todos os dados do cliente serão verificados e processados ​​no nível do servidor novamente.

O servidor não pode assumir que seu cliente rico / robusto enviou os dados; portanto, com qualquer coisa sendo enviada, o servidor deve validá-los e processá-los. Portanto, faz sentido colocá-lo lá.

No entanto, acredito que alguma lógica pode ser feita no nível do cliente para uma melhor experiência de interface do usuário.

Você está correto, por que enviar dados ao servidor se não estiver completo ou incorreto. É fácil verificar os campos obrigatórios ou os telefones ou endereços de email adequadamente formatados. Nunca gostei de enviar um formulário e, em seguida, aguarde 5 segundos para me dizer que esqueci de inserir um campo. Esse tipo de processamento, com certeza, faz no cliente e verifique se está correto e usando a lógica do lado do cliente para uma resposta rápida ao usuário. Como você apontou, um efeito colateral bônus seria que seu servidor teria que lidar com menos solicitações de dados ruins. MAS, o servidor ainda precisa validar também, então você está enganando a lógica. Mas seus usuários ficarão mais felizes.

Há uma linha tênue aqui. Lógica de validação simples OK, lógica de negócios principal não OK.

1. Antes de tudo, você precisa entender a arquitetura dos aplicativos Web, a maioria, se não todos, são de três camadas:

   a) Cliente / apresentação - HTML e Javascript, podem conter ActiveX / Flash / Java Applets / Silverlight. Vou sair em um membro e adicionar aplicativos móveis nativos que se comunicam com um servidor back-end. Basicamente, o papel dessa camada é fornecer uma interface para o usuário do sistema interagir com ela.

   b) Lógica comercial - PHP / RoR / Java onde os dados do cliente são coletados, processados ​​e armazenados e onde as solicitações de dados do cliente são processadas e enviadas de volta ao cliente

   c) Backend Data Store - fornece armazenamento persistente para as informações do sistema

2. Então, onde você faz a validação, em todas as camadas. Por quê?

   a) Lado do cliente - garanta que o usuário insira dados corretos, campos obrigatórios, etc.

   b) Lógica comercial - filtrar, higienizar e validar dados do cliente. Execute regras de negócios mais complexas para garantir que os dados estejam bem formados para armazenamento. Algumas das validações feitas no front end são repetidas aqui, devido ao fato de que podem haver clientes diferentes, por exemplo, nos navegadores, o Javascript pode ser desativado. Ele também pode aceitar dados de diferentes fontes por meio de APIs, por exemplo, para que tudo precise ser validado.

   c) Armazenamento de dados de back-end - as restrições garantem que os dados estejam bem formados para armazenamento e recuperação posterior.

Então, onde você concentra seus esforços de validação, use cada camada para realizar a validação que melhor lhe convém e deixe regras mais complexas para a camada que pode lidar com isso

Uma grande parte é manter seu processamento próximo aos seus dados. Se você possui centenas de GB de dados, obviamente não os enviará para um cliente. Com o aumento da velocidade de acesso a dados, isso se torna menos problemático, mas se você possui um site de Big Data, ainda deseja filtrar e restringir o servidor o máximo possível antes de enviá-lo.

Quando você cria seu comportamento completamente no lado do cliente (digamos, com Javascript), o SEO pode se tornar um problema.

As soluções da Web que mantêm muito no lado do servidor são mais capazes de manter o conteúdo específico publicado em uma URL específica (geralmente RESTful), de maneira visível aos mecanismos de pesquisa.

Isso também significa que um visitante pode marcar uma página específica. Você já tentou isso no Facebook?

Esse material pode ser resolvido, mas geralmente é embutido em aplicativos que fazem muito no servidor (RAILS, WordPress etc.), enquanto que, se você estiver construindo o REACT, terá que pular os bastidores.

O motivo é a estabilidade .

No lado do servidor, eu posso escolher componentes estáveis. Normalmente, isso significa que eu escolho Java e um monte de bibliotecas selecionadas com muito cuidado, como o FreeMarker. Desnecessário dizer que todas as bibliotecas, além das bibliotecas padrão do Java, são tratadas como descartáveis, então eu acesso as bibliotecas externas através de um invólucro feito por você. Isso significa que eu posso mudar facilmente de uma biblioteca para outra se o requisito surgir.

Sempre que atualizo o Java para uma nova versão, geralmente funciona bem porque o Java é um componente extremamente estável, mesmo nas principais atualizações de versão. E também, todos os servidores que eu tenho estão executando a mesma versão Java. Nem todo cliente está executando a mesma implementação JavaScript.

No lado do cliente, não posso escolher componentes estáveis. Os fabricantes de navegadores me forçarão a escolher JavaScript, uma linguagem que particularmente não gosto, mas que sou forçada a usar. (E não me fale sobre idiomas compilados em JavaScript, eles são horríveis!) A implementação de JavaScript em todos os navegadores é diferente. Isso significa que é um inferno total testar meu produto com todas as versões de navegadores compatíveis.

Minha solução? Eu executo o máximo de processamento possível no lado do servidor, e o lado do cliente é apenas um invólucro leve que envia dados ao servidor e recebe dados do servidor na forma de fragmentos JSON e HTML. Evite XML; use JSON em vez disso.

Eu não faço modelagem no lado do cliente; Renderizo o conteúdo no servidor em um fragmento HTML que atribuo usando o .innerHTMLatributo a vários elementos de espaço reservado no lado do cliente. Isso mantém a pilha de tecnologia o mais simples possível, porque não preciso de dois mecanismos de modelo (um Java e um JavaScript).

A desvantagem é obviamente a latência da velocidade da luz; meio segundo de latência não é incomum entre os continentes.

Considere que seus clientes hoje em dia podem ser smartphones. Os smartphones têm uma autonomia limitada da bateria; portanto, se você estiver fazendo cálculos pesados, é melhor transferi-los para seus servidores. No entanto, coisas simples podem ser mais eficientes em termos de energia quando feitas no lado do cliente, pois assim você pode evitar o acesso por rádio. Mas o argumento principal, estabilidade, pode significar que realmente faz sentido transferir até mesmo a computação simples para o servidor.

Como adendo, como já observado em algumas respostas, você também ganha segurança . Se a lógica do aplicativo estiver inteiramente do lado do cliente, alguém pode, por exemplo, definir um preço para qualquer coisa que comprar na sua loja virtual.