构建SSR/HDA应用的10个技巧

Carson Gross

使用传统的服务器端渲染(SSR)构建Web应用,或者换种说法,构建超媒体驱动应用(HDA),与使用React等单页面应用框架构建Web应用相比,需要思维方式的转变。

如果你带着SPA开发的思维模式来尝试这种开发方式,你很可能会感到沮丧,并错过这种架构选择的许多优势。

以下是10个技巧,帮助你顺利实现思维转变,充分利用这种方法的优势,同时尽量减少其弱点:

技巧1:最大化服务器端优势

超媒体驱动方法的一大优势是,在构建Web应用时,它使服务器端环境变得更加重要。你的后端不仅仅是生成JSON,而是成为Web应用用户体验的组成部分。

因此,深入了解服务器端可用的功能很有意义。许多较旧的Web框架在生成HTML方面有非常深入的功能。像服务器端缓存这样的功能可以决定Web应用是极其流畅还是用户体验迟钝。

花时间学习所有可用的工具。

一个好的经验法则是,你的应用中的响应时间应控制在100毫秒以内,成熟的服务器端框架有工具可以帮助实现这一点。

技巧2:在服务器端组织应用

服务器端环境通常有非常成熟的机制来正确组织代码。模型/视图/控制器模式在大多数环境中都得到了很好的发展,模块、包等工具为组织代码提供了很好的方式。

虽然SPA的用户界面通常通过组件组织,但超媒体驱动应用通常通过模板包含组织,服务器端模板根据应用的HTML渲染需求进行拆分,然后根据需要相互包含。这通常会导致比基于组件的应用更少但更大的文件。

另一种值得关注的技术是模板片段,它允许你只渲染模板文件的一部分。这可以进一步减少服务器端应用所需的模板文件数量。

技巧3:专业化API端点

JSON API不同,为超媒体驱动应用生成的超媒体API应该包含专门针对应用UI需求的端点。

因为超媒体API不是为通用客户端设计的,你可以抛开保持其通用性的压力,专门为你的应用生成所需的内容。
你的端点应该针对应用的特定UI/UX需求进行优化,而不是为领域模型提供通用数据访问模型。

技巧4:积极重构API端点

一个相关的技巧是,当你有一个基于超媒体的API时,你可以以在基于JSON API的SPA中不鼓励的方式积极重构你的API。因为超媒体应用使用超媒体作为应用状态的引擎,你能够并且实际上被鼓励随着应用的发展和用例的变化改变API的结构。

超媒体方法的一个巨大优势是,你可以完全重新设计API以适应新的需求,而不需要版本化API甚至不需要文档。

技巧5:利用对数据存储的直接访问

当应用使用SPA方法构建时,数据存储通常位于JSON API之后。这种间接性通常阻止前端开发者充分利用数据存储中的工具。GraphQL可以帮助解决这个问题,但带来了许多开发者似乎没有很好理解的安全问题

另一方面,当你在服务器端生成HTML时,创建HTML的开发者可以完全访问数据存储,并利用例如SQL存储中的连接聚合函数

这为生成HTML的开发者提供了更多的表达能力。因为你的超媒体API可以围绕UI需求构建,你可以调整每个端点,使其尽可能少地访问数据存储。

一个好的经验法则是,每个请求应尽量控制在三次或更少的数据存储访问。

技巧6:避免模态窗口

模态窗口在许多Web应用中变得流行,几乎成为标准。

不幸的是,模态窗口与Web的许多基础设施不兼容,并引入了客户端状态,这可能难以(尽管并非不可能)与基于超媒体的方法干净地集成。

考虑使用替代方案,如内联编辑,而不是模态窗口。

技巧7:接受"足够好"的用户体验

许多SPA开发者在接触HDA方法时面临的一个问题是,他们看着当前的SPA应用,想象用超媒体完全实现它。虽然htmx和其他超媒体导向的库显著缩小了基于超媒体的应用与SPA之间的交互性差距,但这种差距仍然存在。

正如Roy Fielding所说的关于Web的RESTful网络架构:

权衡在于,统一接口降低了效率,因为信息是以标准化形式传输的,而不是针对应用需求的特定形式。

接受特定用户体验的稍微不那么高效和交互的解决方案,可以在构建Web应用时为你节省大量的复杂性

不要让完美成为优秀的敌人。

技巧8:必要时创建"交互性孤岛"

在你的Web应用中的某个时候,可能会出现超媒体方法本身无法满足需求的情况。

一个很好的例子是重新排序项目列表。这可以通过点击上下箭头或在项目旁边添加顺序号下拉菜单来实现(我惭愧地承认我构建过这两种方式!)。

但这种体验与人们习惯的拖拽相比差远了。

在这种情况下,完全可以采用前端密集型的方法作为"交互性孤岛"。

考虑SortableJS示例。这里有一个复杂的交互区域,允许拖拽,并通过事件与htmx和更广泛的超媒体驱动应用集成。

这是在HDA中封装更丰富用户体验的绝佳方式。

技巧9:不要害怕使用脚本!

脚本是Web架构的明确部分,采用超媒体方法的开发者不应害怕使用它。当然,脚本和脚本之间是有区别的。

尽可能使用超媒体友好的脚本方法,保留超媒体交换作为与服务器通信系统状态变化的主要机制。

内联式脚本,如alpine.jshyperscript所支持的,也值得探索,因为它将你的脚本重新聚焦于超媒体(HTML)本身,并对你可以编写的代码量施加了美学约束。

技巧10:保持务实

最后,不要教条地使用超媒体。归根结底,它只是另一种技术,有其自身的优势和劣势。如果应用的某个部分或整个应用需要比超媒体能提供的更交互的内容,那么就选择能够满足需求的技术。

只需熟悉超媒体能做什么,这样你就可以作为知情开发者做出决定。

结论

希望这些技巧能帮助你更有效、更顺利地采用超媒体和服务器端渲染作为一种工具。它不是完美的客户端-服务器架构,涉及明确的权衡,但对于许多Web应用来说(比今天大多数Web开发者想象的要多得多),它非常有效,并在这些情况下提供了更简单的整体开发体验。

</>