强调客户端或服务器端处理的利弊

为什么我要编写一个具有大量服务器端处理功能的Web应用程序？

对我而言，在客户端编写程序是一个巨大的优势，因为它只需占用最少的处理即可将数据发送到客户端，从而尽可能地减轻了服务器负载。

除了在服务器端编写网络应用程序并将客户端仅作为视图外，我在编写Web应用程序方面几乎看不到什么。我为什么要这么做？我看到的唯一好处是，我可以使用自己想要的任何语言（http://www.paulgraham.com/avg.html）进行书写。

有两个主要问题。

1. 第一个很简单-您通常不知道客户端可以使用哪种资源。如果需要1.5GB的空间来处理某些内容，您真的可以将其推送到未知客户端平台上的未知客户端浏览器（IE，Safari，Opera，Firefox等）上吗？当您不知所措时，客户会欣赏他的系统困扰吗？

2. 第二个是更具建筑性的-您想将哪些图层暴露给外界？大多数人都同意公开数据层是非常冒险的。您的服务层如何？您真的要在那儿传递这种逻辑吗？如果这样做，是否还将入口点公开到数据层？如果您保留服务层服务器端，还剩下什么？UI，对不对？请参阅原因1，以了解其中有多少存储在服务器上以及客户机上有多少。

首先是安全。将所有逻辑推送给客户端，这对黑客和漏洞利用来说是公平的游戏。

任何具有任何感知价值的东西都不会持续5分钟，尤其是金钱价值，并且会被游戏，黑客攻击或利用并严重破坏系统。即使它几乎没有金钱价值，也有一群人会因为无聊而破解它，只是为了破坏您的系统。

客户端与服务器端

客户端处理符合更流行的REST标准以及MVC，而不是基于页面的方法和SOAP。这些趋势的出现以及对AJAX和Html-RIA的关注，客户端脚本的兴起和普及。但是，由于安全性和客户端功能的原因，客户端脚本具有特定的优势，因此不应用于所有方面。

注意事项：

移动

如果您的目标受众中有很大一部分将是移动用户，则应将大量的处理工作留给服务器。

跨浏览器一致性

Web标准已经走了很长一段路，这可能不是您所关心的问题，但是每个Web开发人员都知道IE 6、7和8（有时甚至是Safari）可以在客户端发挥作用-某些功能可能由于以下原因而无法运行安全性限制和其他由于未执行的标准。还需要注意的是，最终用户可以将浏览器配置为具有某些限制，甚至完全关闭客户端处理（无需JavaScript！）。如果100％的用户要求一致性（特别是在您做非常规操作时），则服务器端最为重要。

安全

您想要保护的任何数据操作都需要在服务器上完成。客户端上处理的任何数据都绝对可以进行操作。例如，如果您具有处理某些信息然后将其回传到系统中的javascript函数，那么即使您具有示例性的后端安全性，也要在回传结果之前非常容易地操纵结果

UI / UX

客户端处理留给用户界面并创建富Internet应用程序（RIA）。它用于创建动画，效果，用户交互，以及通过AJAX调用动态加载内容，而不是重新加载整个页面。

首先，这将是重复的工作。来自客户端的任何数据很可能将再次在服务器级别进行检查和处理。

服务器无法假定您的富客户机/鲁棒客户机发送了数据，因此，在发送任何数据时，服务器必须对其进行验证并进行处理。因此，将其放在那里是很有意义的。

但是，我相信可以在客户端级别完成一些逻辑，以获得更好的UI体验。

您是正确的，如果不完整或不正确，为什么要将数据发送到服务器。您可以轻松检查必填字段或格式正确的电话或电子邮件地址。我从不喜欢提交表单，然后等待5秒钟告诉我我忘记输入字段。当然，这种处理应在客户端上进行，并确保它是正确的，并使用客户端逻辑对用户做出快速响应。正如您所指出的那样，额外的副作用是您的服务器必须处理较少的不良数据请求。但是，服务器仍然还必须进行验证，因此您在欺骗逻辑。但是，您的用户会更快乐。

这里有一条细线。简单的验证逻辑可以，核心业务逻辑不能。

1. 首先，您需要了解Web应用程序的体系结构，大多数（如果不是全部的话）都是3层的：

   a）客户端/演示文稿-HTML和Javascript，可能包含ActiveX / Flash / Java Applets / Silverlight。我将不遗余力地添加与后端服务器通信的本机移动应用程序。基本上，该层的作用是为系统用户提供一个与其交互的接口。

   b）业务逻辑-PHP / RoR / Java，用于收集，处理和存储来自客户端的数据，并处理客户端对数据的请求并将其发送回客户端

   c）后端数据存储-为系统信息提供持久存储

2. 因此，您要在所有层进行验证。为什么？

   a）客户端-确保用户输入正确的数据，必填字段等

   b）业务逻辑-过滤，清理和验证客户数据。运行更复杂的业务规则，以确保数据格式正确以进行存储。由于可能存在不同的客户端，因此在此重复在前端进行的一些验证，例如可以禁用Javascript的浏览器。例如，它也可以通过API接受来自不同来源的数据，因此都需要进行验证。

   c）后端数据存储-约束条件确保数据格式正确，可以存储和以后检索。

因此，您将精力集中在哪里，使用每一层来执行最适合它的验证，并为可以处理它的层保留更复杂的规则

很大的一部分是使您的处理接近数据。如果您拥有数百GB的数据，则显然不会将其发送给客户端。随着数据访问速度的提高，这已不再是一个问题，但是，如果您拥有大数据站点，则仍希望在将其交付之前对服务器进行尽可能多的过滤和缩小。

当您完全在客户端（例如，使用Javascript）创建行为时，SEO可能会成为问题。

在服务器端保留大量资源的Web解决方案更容易以搜索引擎可见的方式将特定内容发布在特定的URL（通常是RESTful）上。

这也意味着访问者可以为特定页面添加书签。您在Facebook上尝试过吗？

这些东西是可以解决的，但通常内置于在服务器上做很多事情的应用程序中（RAILS，WordPress等），而如果要使用REACT进行构建，则必须跳过障碍。

原因是稳定。

在服务器端，我可以选择稳定的组件。通常，这意味着我选择Java和一堆精心挑选的库，例如FreeMarker。不用说，除Java标准库以外的每个库都被视为一次性库，因此我通过自制包装器访问外部库。这意味着如果需要，我可以轻松地从一个库更改为另一个库。

每当我将Java更新到新版本时，它通常都可以正常工作，因为Java即使在主要版本更新中也是一个极其稳定的组件。而且，我拥有的每台服务器都运行相同的Java版本。并非每个客户端都运行相同的JavaScript实现。

在客户端，我无法选择稳定的组件。浏览器制造商会迫使我选择JavaScript，这是我特别不喜欢的语言，但我不得不使用它。（并且不要告诉我有关编译为JavaScript的语言的信息，它们太可怕了！）每个浏览器的JavaScript实现都不相同。这意味着要在所有受支持的浏览器版本上测试我的产品，真是太麻烦了。

我的解决方案？我在服务器端执行了尽可能多的处理，并且客户端只是一个轻量级包装器，以JSON和HTML片段的形式将数据发送到服务器并从服务器接收数据。避免使用XML；改用JSON。

我不做客户端模板；我将服务器上的内容呈现为HTML片段，然后使用.innerHTML属性将该属性分配给客户端上的各种占位符元素。这使技术栈尽可能简单，因为我不需要两个模板引擎（一个Java引擎和一个JavaScript引擎）。

缺点显然是光速延迟。在各大洲之间，半秒的延迟并不罕见。

不要认为这些天您的客户可能是智能手机。智能手机的电池寿命有限，因此，如果您要进行大量计算，最好将其卸载到服务器上。但是，简单的事情在客户端进行时可能更节能，因为这样可以避免无线电访问。但主要论点稳定性是可能意味着将甚至简单的计算卸载到服务器实际上也很有意义。

作为增补，正如在某些答案中已经看到的那样，您也可以获得安全性。如果应用程序逻辑完全在客户端，则可以例如为要从您的在线网上商店购买的任何商品设置价格。