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

Question

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

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

Answer 1

上面的答案是正确的，但它没有解决一些实际问题。

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

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

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

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

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

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

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

Answer 2

最简单的方法是将状态放在 mvar 后面：

fooHandler :: MVar Int -> Snap ()
fooHandler mvar = do
    x <- liftIO $ modifyMVar mvar $ \y -> let y'=y+1 in (y',y')
    writeBS $ S.pack $ "Incremented counter to: " ++ show x

在站点初始化时初始化 mvar。希望这有帮助。

Answer 3

我找到了两个与会话相关的包：

• snap-auth (GitHub)
• mysnapsession

snap-auth 由 Snap Framework 团队制作，或者至少由其作者之一制作/贡献者（Ozgun Ataman）。它的目标是身份验证和会话管理。会话管理是使用 ByteString 到 ByteString 的映射来完成的，这意味着您只能存储已经序列化为 ByteString 的数据：

type Session = Map ByteString ByteString

另一方面，mysnapsession 允许您使用任意类型来建模你的会议。然而，Map 类型的会话有一些辅助函数。更多详细信息请参见此处。作者 Chris Smith 也是 Snap Framework 项目的成员。