我将创建一个全新的网站并从头开始编写所有内容，主要是在前端部分。我只是想知道是否有任何资源可用于构建可扩展的前端架构，因为我以前从未有过这种经验。任何建议、想法或书籍推荐将不胜感激！
问问题
1502 次
1 回答
2
很难回答你的问题，因为我们不确定它的每一个部分。据我所知，没有“可扩展前端架构”这样的定义。可扩展性和前端都是非常广泛的主题，所以我只能猜测......
我假设在您的术语中，前端意味着单页 javascript 应用程序，而可扩展部分意味着功能可伸缩性（而不是通常在服务器端上下文中使用的负载可伸缩性）。有了这些限制，我认为 REST 架构是我所知道的最佳匹配。
通过 REST 架构，有 REST 服务和 REST 客户端。两者都是应用程序。您可以在浏览器中将 REST 客户端作为前端应用程序运行，也可以在服务器上将 REST 服务作为后端应用程序运行。REST 是为 HTTP 1.1 协议设计的，所以正如您所见，它可以很容易地适应 HTTP 客户端和服务器的通常上下文。
常规 Web 服务仅向其客户端提供数据（例如 JSON 格式），并且客户端应该知道如何处理它。所以客户端必须包含业务逻辑的片段。该服务还包含业务逻辑，因为它是检查请求有效性的唯一安全环境，并且因为只有它才能访问公共持久存储（数据库）。所以在这种情况下，服务和客户端都包含相同的代码片段，因此，Web 应用程序的代码不是 DRY。我想你已经知道非 DRY 代码很难维护……通过 REST 架构，服务不仅向客户端发送数据，还向客户端发送抽象控制器（链接和表单）的表示。这可以通过发送任何超媒体格式来完成。如果您考虑 HTTP 通信也是如此，它以 HTML 格式发送控制器和数据表示。我们可以使用 HTML 作为消息格式，但不建议这样做，因为解析它既困难又慢，而且没有任何建议如何以 HTML 格式序列化数据。XML 和 JSON 不同，它们是为数据序列化而设计的，但是它们缺少控制器描述。目前有许多基于 XML 和 JSON 的新生超媒体格式，它们能够做到：ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、siren (JSON)、collection+JSON 等... 但他们缺乏控制器描述。目前有许多基于 XML 和 JSON 的新生超媒体格式，它们都能够做到：ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、siren (JSON)、collection+JSON 等... 但他们缺乏控制器描述。目前有许多基于 XML 和 JSON 的新生超媒体格式，它们能够做到：ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、siren (JSON)、collection+JSON 等...
因此，您的 REST 客户端以超媒体格式从 REST 服务获取数据和控制器表示。例如，通过个人资料页面，您可以获得姓名、出生日期等......作为数据和编辑表单、删除链接等......作为控制器。目前很少有标准/建议如何描述控制器。您可以学习我提到的媒体类型或制作自己的媒体类型。这并不难......重要的是，REST 客户端在获得它们之前不应该知道任何关于确切控制器的信息。它只能知道如何显示从服务中获取的控制器。例如，通过注册表单，它不应该知道方法的 url、输入字段的名称等……但它必须知道如何显示当前超媒体格式中描述的注册表单。浏览器也一样，他们将表单作为 HTML FORM 元素获取，并很好地显示它们，尽管事实上他们对将填写的表单发送回服务器时会发生什么一无所知。所以浏览器对它们正在显示的 Web 应用程序的业务逻辑一无所知。REST 客户端对 REST 服务做同样的事情，他们对 REST 服务的业务逻辑一无所知，他们只知道如何显示 REST 服务发回的超媒体，以及如何向服务发送请求。我认为这是一种易于理解的方法……由于这种设计方法，REST 客户端和 REST 服务是松散耦合、容错且易于维护的。例如，如果您向 REST 服务添加新功能（例如新链接），它通常不会影响您的 REST 客户端，因为它们已经准备好处理链接。
我认为理解 REST 架构的理论很容易，但是诀窍要困难得多。人们经常将他们的常规 Web 服务称为 REST 服务，这引起了很多混乱，因为 REST 架构现在是一种炒作。每个人都想做，但做对的却寥寥无几……
于 2014-02-25T00:44:58.387 回答