Haskell Servant - serveWithContext 的目的是什么？它做了哪些 ReaderT 做不到的事情？

Question

我试图了解 Servant 的 serveWithContext 函数的用途。文档指出它不是 ReaderT Monad 的替代品，但我不确定它试图解决 ReaderT 尚未解决的问题。

例如，这是来自 servant-auth GitHub 页面上的示例:

unprotected :: CookieSettings -> JWTSettings -> Server Unprotected
unprotected cs jwts = checkCreds cs jwts :<|> serveDirectory "example/static"

server :: CookieSettings -> JWTSettings -> Server (API auths)
server cs jwts = protected :<|> unprotected cs jwts

let jwtCfg = defaultJWTSettings myKey
      cfg = defaultCookieSettings :. jwtCfg :. EmptyContext
      api = Proxy :: Proxy (API '[JWT])
  _ <- forkIO $ run 7249 $ serveWithContext api cfg (server defaultCookieSettings jwtCfg)

似乎 serveWithContext 被用来将 Cookie 和 JWT 设置传递给处理程序，但我不明白为什么这不能通过 ReaderT 完成。此外，serveWithContext 似乎分两次传递这些值:一次作为绑定(bind)到 cfg 的 Context 对象，另一次作为函数调用中的参数 server defaultCookieSettings jwtCfg。

如果有人能为我揭开 Servant 的上下文类型的神秘面纱，我将不胜感激。

Answer 1

Servant 的机制似乎没有对您选择在其中定义处理程序的底层 monad 做出假设。这意味着它不能强制您选择任何特定的 monad(例如 ReaderT)来响应路由中存在的某些组合器，并且它不会对您选择的 monad 做出“ react ”为了启用某些行为。

对于servant-auth，我们需要提供一些extra information告知如何处理 cookie 等。

Context 系统是如何收集 route 的位置参数中的额外信息的？ , hoistServerWithContext和 serveWithContext ，同时仍然让你选择你想要的任何 monad。参数的确切类型取决于 API 中存在的路由组合器。

servant tutorial有一些关于 Context 的段落:

When someone makes a request to our "private" API, we’re going to needto provide to servant the logic for validating usernames andpasswords. [...] Servant 0.5 introduced Context to handle this. [...]the idea is simple: provide some data to the serve function, and thatdata is propagated to the functions that handle each combinator.

至于

Furthermore, serveWithContext appears to be passing these values intwice

我不确定，但我怀疑 checkCreds 将 cs 和 jwts 作为参数只是作为验证方式的示例如果纯粹在处理程序中完成，则在没有 Servant 本身帮助的情况下执行。相反，protected 端点已经接收到身份验证的结果作为参数；它不必自己执行。

在真实世界的应用程序中，server 不会接受这些参数，它们只会在 Context 中传递。