haskell - 如何使用 Snap Framework 维护服务器端状态？

Question

服务器端 session 还不是 Snap 框架的一部分。有没有办法添加某种服务器端状态？

假设我想为每个 HTTP 请求增加一个计数器。我该怎么做？

Answer 1

上述答案就其本身而言是正确的，但它没有解决一些实际问题。

首先是服务器重新启动。如果您的存储不仅仅是缓存，那么它需要在服务器重新启动后保持持久性。

第二是代码重新加载。 Snap 的 future 版本，从 0.3 开始(可能在 12 月初)将在开发使用中动态重新加载代码。就开发速度而言，这是一个巨大优势，但它使服务器本地状态成为一项有趣的智力练习。如果程序员更改了服务器本地状态的类型/初始化/任何内容，则需要重新初始化。那里存在一些巨大的工程挑战。

当我为 0.3 编写动态重新加载代码时，我为这个问题苦苦挣扎了一段时间。然后我又看了看其他平台。 PHP？将所有内容存储在外部(数据库、内存缓存等)。内存中根本没有交叉请求存储。 Ruby on Rails？一样。

结合第一期中固有的挑战，我得出的结论是，除了可能的缓存优化之外，服务器应该是无状态的。将持久性问题留给为其设计的库/外部流程。

因此，我设计了生产和开发加载器使用的通用接口(interface)(一个使用静态加载，另一个使用动态加载)来实现 3 个函数:一个初始化函数、一个清理函数和一个使用由初始化函数。在生产模式下，编译为在服务器启动时调用初始化，并在服务器关闭时调用清理。在开发模式下，它编译为:对于每个请求，动态加载所有 3 个请求，然后运行 ​​init、handler、cleanup。显然，没有任何状态能够在这种方式的交叉请求中生存。

然后我的答案变成:通过某种具有内置持久性的机制进行交叉请求存储，并让服务器状态只是其接口(interface)。如果您想在进程内工作，请使用 happstack-state 或 sqlite 之类的东西；如果您想在本地进程之外工作，请使用数据库或其他外部存储。

作为补充说明，由于添加了 MonadSnap 接口(interface)，管理“全局”资源(例如连接池等)在 Snap 0.3 中也变得更加容易。