hyperlith：全栈式超媒体单体框架

hyperlith：全栈式超媒体单体框架

hyperlith Hyperlith: the hypermedia based monolith 项目地址: https://gitcode.com/gh_mirrors/hy/hyperlith

项目介绍

hyperlith 是一个基于 Datastar 的全栈框架，主要面向个人使用。然而，开发者认为其中的一些想法值得分享，因此开放了源代码。hyperlith 仅仅使用了 Datastar 的一部分功能。如果你需要一个生产就绪的全功能 Datastar Clojure SDK，建议使用官方 SDK。

hyperlith 的 API 可能随时更改，因此使用时需要自行承担风险。

项目技术分析

hyperlith 的设计理念是构建一个具有以下特点的全栈框架：

• ** Opinionated（有主见的）**：hyperlith 并不试图成为一个通用解决方案。
• Server driven（服务器驱动）：从第一天起就支持推送式的多玩家和流更新。
• Production REPL first（首选生产 REPL）：运行中的系统应易于自省、修改和修补。
• Minimal dependencies（最小依赖）：确保项目长期稳定和安全的运行。
• Operationally Simple（操作简单）：处理所有操作任务在进程内完成。
• Sovereign（独立自主）：可以部署在任何 VPS 提供商上。

项目技术应用场景

hyperlith 适用于以下场景：

• 需要全栈式解决方案的开发者。
• 希望通过服务器推送更新和流式传输来构建应用的团队。
• 需要简单、易于维护和扩展的框架的初创公司。

项目特点

以下是 hyperlith 的一些主要特点：

单一渲染函数

hyperlith 通过为每个页面提供一个单一的渲染函数，简化了应用的状态管理和视图更新。这种方式允许开发者通过 view = f(state) 来思考应用，使得状态变化时能够推送最新的视图，而不需要处理错过的、断开连接和重新连接的事件。

数据库变更即重渲染

hyperlith 在数据库变更时立即重新渲染页面，避免了事件的不均匀性和数据丢失的问题。即使在高负载下，这种方法也比非均匀事件系统更高效。

无差异

hyperlith 的设计遵循 CQRS（命令查询责任分离）原则，确保所有的视图更新都通过数据库进行，从而避免了连接状态的持久化和维护。

缓存与批处理

hyperlith 实现了工作共享（缓存），在多个用户共享同一视图时，可以减少重复的工作负载。同时，它还支持批处理，提高吞吐量，但需要注意事务的原子性问题。

快速响应

通过使用 data-on-pointerdown/mouse 而不是 data-on-click，hyperlith 能够即使在网络延迟较高的情况下也能提供更快的响应。

其他激进选择

• No CORS：通过在相同源上托管所有资源来避免 CORS，减少服务器往返次数，降低延迟。
• 基于 Cookie 的会话管理：使用不可预测的随机 UID 来管理会话。
• CSRF 保护：采用双提交 Cookie 模式来防止跨站请求伪造。
• 初始页面的渲染策略：通过渲染初始壳页面并在页面连接到更新端点时填充内容，减少了服务器的工作负载。

hyperlith 还提供了一些其他的选择，如简单的路由映射、建议使用 HTTP2/3 与 SSE 配合的 reverse proxy，以及最小化中间件和依赖。

hyperlith 是一个专为简化全栈开发而设计的框架，通过服务器驱动的推送更新和流式传输，为开发者提供了一种新的构建应用的方式。它的特点和设计理念使其成为一个值得探索和尝试的开源项目。

hyperlith Hyperlith: the hypermedia based monolith 项目地址: https://gitcode.com/gh_mirrors/hy/hyperlith