Discussion / feature-request: allow using a monad other than Aff with HTTPure.serve

[Dretch]

I have just converted my app to use monad-logger and as a result I have replaced Aff a with LoggerT Aff a in many places in the codebase.

HTTPure.serve is a bit awkward here because it requires that the request handling function return Aff a. This means that the LoggerT Aff a to Aff a transformation has to be done inside the request handling function by using runLoggerT. It might be neater if serve could work with any monads that implement MonadAff - then the logging context could be automatically passed through from the caller.

Is this a good idea?

[cprussin]

Yeah, I've actually been thinking about that quite a bit recently. I think the best approach here would be to replace all the Aff references in httpure with a forall a. MonadAff a. I just haven't really prioritized the change yet for the following reasons:

1. It's not entirely trivial in HTTPure, would require some not-insignificant amount of work to refactor everything, including a lot of lifting for use cases that don't involve mtl stacks (or exposing both a transformer and non-transformer API, like how you can use either State or StateT).

2. In my apps, I find I generally end up using two mtl stacks, one for the server and one for each request that contains a state that includes all the information from the server state, plus request-specific state (I also often use a request-specific logger that automatically tags each message with certain details, such as a UUID minted per-request). So I prototyped this change to httpure and I didn't end up getting too much out of it anyways, because I still had to run my mtl stacks per-request anyways.

3. It's fairly easy (and arguably clearer) to work around in app code:

main :: Effect Unit
main = runReaderT (runLoggerT bootServer serverLogger) $ serverEnv

bootServer
  :: forall m
   . MonadAsk ServerEnv m
  => MonadLogger m
  => MonadEffect m
  => m Unit
bootServer = void do
  serverOptions' <- serverOptions
  router' <- router
  logStart' <- logStart serverOptions'.port
  liftEffect $ serve' serverOptions' router' logStart'

serverOptions :: forall m. MonadAsk ServerEnv m => m ListenOptions
serverOptions =
  asks _.port <#>
    { hostname: "0.0.0.0"
    , port: _
    , backlog: Nothing
    }

router :: forall m. MonadAsk ServerEnv m => m (Request -> ResponseM)
router =
  ask <#> \env request ->
    let
      response = routeRequest request
      logger = requestLogger request
    in
      requestEnv env request >>= runReaderT (runLoggerT response logger)

routeRequest :: forall m. MonadAff m => Request -> m Response
routeRequest = const $ liftAff $ notFound

logStart :: forall m. Monad m => Int -> m (Effect Unit)
logStart port =
  let
    message = info (intTag "Port" port) "Server up"
  in
    pure $ runLoggerT message serverLogger

In any case, I'm absolutely not opposed to it, I just haven't implemented it myself yet.

[cprussin]

As an aside, even if we decide that we don't want to change HTTPure's API after all, I would at the very least really like to polish up the code above and drop it into an example to guide folks for how to use httpure with mtl stacks, and especially how to use a per-request mtl stack.

[Dretch]

Thanks @cprussin, that is helpful.

In my case, I want to use the same logger everywhere, so I ended up with something like this:

start :: LoggerT Aff Unit
start = do
  logger <- wrap pure
  liftEffect $ void $ HTTPure.serve
    port
    (router >>> flip runLoggerT logger)
    (launchAff_ $ runLoggerT logStart logger)
  where
    router _ =  liftAff HTTPure.notFound -- actually does more stuff than this

    logStart = info (intTag "port" port) "Started HTTP server"

    port = 8080

[cprussin]

@Dretch just wondering, after some time has passed, do you have an opinion on if this should be an API change in HTTPure vs just a pattern that's documented somewhere?

[Dretch]

Hi @cprussin, I wish I could give you some insights, but I have barely touched any code using HTTPure since I made this issue, so I have not developed any opinions. Sorry!