dmjio/hackernews — pull request #7 by zudov (2014-10-16 03:30:51+00:00)
Title: Wreq backend

I've reemplimented the backend code with wreq. For simplicity I removed everything what was there before, but I want to discuss the implementation of multiple backends if you think that it's necessary.

The biggest advantage which the wreq implimentation gives is the simplicity of sharing the connection. Connections are managed by manager which can be safely shared between concurrent threads (see examples), so the server applications can create a manager on startup and then use it for the whole application runtime (yesod users usually already have a manager for some other needs, and they can use it here).

The disadvantage is that wreq has heavy dependency, `lens`. However this can be overcomed by using `http-client` (a refactored fork of http-conduit) which `wreq` is based on. Wreq is kind of high level interface to `http-client`, with some additional features. That idea just striked me, and it seems great because depending on something as huge as `lens` for no big reason is not very good.

I haven't yet think about a go way to support multiple backends, current `wreq` implimentation is done in a way that would be ideal if wreq was the only backend, so that you can take a look.

By the way, now API has functions like `get*` and `get*With`. The second one takes `Options` (with manager inside) as an argument, first one uses default options and therefore creates a new manager on request. I consider removing those that use default options, as it's smart to use them only in case if one request is done over application life, or the requests are done with a big time interval; such usecases are very rare, so there is no need for distinct shortcuts. At the same time it would discourage the wrong usage of API when the manager is created on each request.