前端格局——不同的架构

如果您正在准备 JavaScript 面试，请访问learnersbucket.com 。您将找到 DSA、系统设计和 JavaScript 问题。

Web 开发（前端）自诞生以来已经走过了漫长的道路。曾经有一段时间，静态网站的设计是使用表格布局，并围绕表格使用一些仅适用于桌面设备的样式。

但如今，Web 应用可以拥有复杂的用户界面，并支持跨设备。以 Web 应用形式构建的 SAAS 使我们能够按需播放电影和音乐、订购披萨、处理银行业务，甚至预订出租车，做越来越多的事情，让我们的生活更加轻松。

随着时间的推移，为了创建提供如此多功能、安全性、灵活性并且易于管理和可扩展的应用程序，组织尝试了多种架构。

作为开发人员、架构师或技术主管，当我们开始一个新项目时，我们需要决定要遵循哪种架构。有很多方案可供选择，但并非所有方案都适合每项工作。我们需要了解在此过程中将面临的挑战，以便为我们的项目做出正确的决策。

让我们探索一下当前可用于前端开发的架构。

服务器端应用程序或多页应用程序。

在服务器端渲染网站尚未成为 Web 应用的时候，它们就已经存在了。它们只能显示文本和图片，交互性非常有限。

这些网站是使用服务器端渲染构建的，这意味着 HTML 和所有数据都是在服务器上生成的，然后返回到浏览器，然后由浏览器渲染它。

当页面刷新或用户导航到其他页面时，服务器会发送新的 HTML。如果您的浏览器没有该页面的缓存版本，则每次都会重复此操作。

由于每次向服务器发出请求时，即使我们只希望进行微小的更改，服务器也会重新生成整个 HTML，这会降低网站的速度。

尽管网站的速度受许多因素的影响，例如您的互联网速度、服务器位置、尝试访问该网站的用户数量等。

对于小型网站来说，这些问题可以忽略不计，但对于拥有数千行代码和复杂逻辑的现代网站来说，处理时间会更长。想象一下，当你浏览网站时，你必须等待访问的每个网页。

但服务器端渲染的好处在于它对 SEO 非常有利。您的内容在您获取之前就已经存在，因此搜索引擎能够顺利地对其进行索引和抓取。

单页应用程序（客户端渲染）

目前，SPA 是最常用的实现方式。单页应用采用客户端渲染。浏览器从服务器加载初始页面，以及整个应用所需的脚本（框架、库、应用代码）和样式表。

当用户导航到其他页面时，不会触发页面刷新。页面的 URL 通过HTML5 History API进行更新。新页面所需的新数据（通常为 JSON 格式）由浏览器通过AJAX请求获取到服务器。然后，SPA 会通过 JavaScript 动态更新页面数据，而 JavaScript 在初始页面加载时就已经下载了这些数据。这种模式类似于原生移动应用的运作方式。

使用 SPA 有很多优点，例如整个应用程序代码在初始加载时只需下载一次，然后整个应用程序逻辑在整个用户会话期间都可用。

由于 SPA 仅处理客户端逻辑，因此可以独立开发它，并通过与持久层（后端或服务器端）交换数据来获取与 API 通信的数据。

客户端和服务端解耦，这意味着我们可以独立开发不同平台（例如移动设备、聊天机器人、智能手表）的新客户端，而无需修改服务端代码。客户端也可以使用新的技术栈进行开发。

由于我们不必一遍又一遍地重复获取相同的资源，因此我们只需发出更少的 HTTP 请求，而且有效负载大小更小，处理速度更快。

因为客户端和服务器端是分离的，这意味着它们的尺寸更小，下载、解释和处理的速度更快。

所有这些功能都增强了用户体验，并表达了我们与移动设备或桌面的本机应用程序交互时通常拥有的功能。

SPA 还允许我们决定如何在服务器和客户端之间划分应用程序逻辑。根据我们要解决的问题类型，我们可以采用“胖客户端”和“胖服务器”或“胖客户端”和“胖服务器”的架构。

主要使用“胖客户端”和“胖服务器”，因为通过将所有逻辑保存在服务器上，我们可以在多个客户端上使用这些逻辑，这样，如果我们在一个平台上更新逻辑，它将在每个客户端上可用。

这样做的坏处是，由于大多数资源都是在 Web 应用程序首次加载时获取的，因此这可能会严重影响应用程序在处理能力较弱和网络速度较慢的设备上初始加载的时间。

您的服务器还需要执行一个额外步骤，即配置所有请求路由到单个入口点，并允许客户端路由从那里接管。所有客户端路由均使用 HTML5 history API 进行内部管理。

由于 SPA 中的页面是在运行时动态生成的，因此使用 SPA 的另一个缺点与搜索引擎优化 (SEO) 有关。当爬虫尝试索引你的网站时，除非我们准备其他方法来获取 SPA 提供的内容，否则很难索引所有的内容。

使用 SPA 的另一个缺点在于组织层面。当 SPA 是一个大型应用程序，由多个使用相同代码库的联合团队开发和维护时，最终可能会出现各种方法和决策，让团队成员感到困惑。

同构应用（混合方法）

通过以上两种方法，我们了解到服务器端渲染可用于解决 SEO 相关问题，而客户端渲染可用于性能优化。如果我们能将两者结合使用，并取其长处，创建速度更快且 SEO 优化良好的 Web 应用程序，那该有多好啊。

同构或通用应用程序是服务器和客户端之间的代码共享并且可以在两种上下文中运行的 Web 应用程序。

这些 Web 应用程序在服务器和客户端之间共享代码。当您第一次访问 Web 应用程序时，该应用程序将使用 Nodejs 的服务器端渲染技术在服务器端呈现，然后将其发送到浏览器并显示给用户，此后，每当用户浏览 Web 应用程序时，页面都会使用 SPA 技术在客户端使用 JavaScript 呈现。通过使用 API 并从中获取数据来更新内容。

这种方法的复杂性主要在于状态管理。解决这个问题的一种方法是在服务器端创建并保存状态，然后将此状态提供给浏览器。浏览器使用此状态来引导 SPA，否则用户必须等待服务器端页面渲染完成，并在浏览器中等待完整的重新渲染过程。

为了充分利用这种方法，我们可以使用创建页面骨架所需的最少内容来呈现页面，例如内联 CSS 和少量 HTML 内容以及最少的 JavaScript，以便浏览器可以非常快速地加载它，然后根据客户端的要求使用 JavaScript 更新内容。

通过这些，我们也可以解决路由问题。您可以直接在服务器端渲染完整的页面，也可以使用混合渲染方法。首先使用服务器端渲染初始视图，然后加载 SPA，服务器将执行宏路由，为不同的 SPA 提供服务，每个 SPA 都有自己的路由系统，用于在视图之间导航。

如果 Web 应用被大量用户访问，同构应用程序可能会面临可扩展性问题。由于页面是在服务器端渲染的，因此设置合适的缓存可以解决这个问题。

微前端架构

微前端是一种相当新兴的架构，其灵感来自后端开发的微服务架构。

当多个团队参与单个应用程序的开发时，管理代码库和应用程序本身会变得困难，因为多个人会接触同一个代码库。

这种方法倾向于通过根据需求将应用程序拆分成不同的部分来解决这个问题，每个部分都可以独立开发，最终作为单个应用程序发布。其主要思想是将单体代码库分解成更小的部分，以便将工作分散到各个团队（无论是集中部署还是分布式部署）之间。

构建微前端应用有多种方法。某些架构决策必须提前制定，因为它们将为未来的决策铺平道路。这些决策主要涵盖四个关键领域。

• 定义不同的微前端。
• 组成微前端。
• 路由微前端。
• 微前端之间的通信。

您可以为同一个视图决定多个微前端，或者每个视图有一个微前端，基于此我们可以拆分应用程序。

应用程序可以水平或垂直分割。

在水平拆分中，我们将页面视图拆分成多个微前端，并由不同的团队负责开发这些视图。这种方法提供了极大的灵活性，因为某些微前端可以在不同的视图之间复用，但也需要更严格的规范和治理，以确保最终不会出现大量的微前端。

在垂直拆分中，我们将页面或模块完全拆分。例如，不同的团队将负责开发不同的模块，例如身份验证、流媒体服务、搜索等。

JAMSTack

如今，另一种新的前端架构正在获得成功，它被称为 JAMStack（JavaScript、API、Markup）。

作为一种现代架构，JAMSTack 有助于使用 JavaScript/API 和预渲染标记创建快速、安全的站点和动态 API，无需 Web 服务器即可提供服务。

实际上，最终输出是由 HTML、CSS 和 JavaScript 组成的静态作品，基本上是前端开发的三位一体，可以直接使用 CDN 提供服务，因为它不需要任何服务器端技术即可运行。提供 JAMStack 应用程序最简单的方法是使用Github 页面来托管最终结果。

这些架构的主要优势是性能更好、基础设施和维护更便宜（因为它们可以直接由 CDN 提供服务）、可扩展性更强（因为提供静态文件）、安全性更高（因为攻击面减少）以及易于与无头 CMS 集成。

对于我们必须创建的许多网站来说，JAMStack 是一个很好的伴侣，尤其是考虑到无摩擦的开发人员体验。