Some Suggestions

[CMCDragonkai]

Cool project, do you know of Netflix's Hystrix and Facebook's Haxl?

Some patterns that are useful (some that I've used before):

• Request Coalescing (similar to batching, but instead of just batching all requests as a multi-request, it eliminates redundant requests, this was used in the case each request is asking for the same thing, then only send 1 request for all the multi-requests, and copy the response to each requester, instead of a time window, I did this with locks, because I needed low latency responses)
• Circuit Pattern (as seen in: https://github.com/jlouis/fuse)
• Workflow Monad (https://hackage.haskell.org/package/Workflow) - Useful for dropped connections and resumable connections/downloads (see http://oboejs.com/why)
• Idempotence Monad (as seen in Stripe and https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/popl38-ramalingam.pdf) - this would enhance the retry pattern
• All the stuff TCP did: ARQ, Forward Error Correction (useful for high bandwidth - high latency/low reliability connections or connections with only a forward link and no return link), Checksumming (I saw you mentioned that HTTP isn't the only thing you're focused on)
• Dealing with Streams and not just Request Response, and handling exceptions (one may want to use on top of something like conduit (distributed conduits))

Also I'm thinking about how this would integrate with RPC frameworks like Cap'n Proto and promise pipelining feature.

[seanparsons]

@CMCDragonkai Thanks for the feedback!

I wrote this in part originally because I found Haxl to be complicated to even get started with and wanted something more akin to the way Finagle from Twitter works.

[seanparsons]

@CMCDragonkai To your points though:

• That's an interesting idea to use locks, it's entirely possible that we could introduce that as an alternative via the configuration. The batching came about because of an observation I made on the service I was working on that we were making a lot of individual or small batch responses simultaneously, which seemed terribly inefficient.
• Like this? https://github.com/seanparsons/glue/blob/master/glue-core/src/Glue/CircuitBreaker.hs
• Interesting, in the use cases I was focused on at the time I was dealing with request/response pains which shaped the purpose somewhat. Streaming (which you get to in your later point) just isn't (currently) part of the library but like all good open source projects I'm happy to accept pull requests!
• I'd need to sit down and read the paper for that one, as like most papers it's less than "Can I understand the basics in 30 seconds friendly".
• These might fall on the wrong side of the 80:20 rule for this project at least.
• Streams would be nice, just need to come up with a nice model for where and how glue fits, just because most streaming libraries end up controlling most of the flow. Like with conduit, glue fits inside somewhere that is making repeated requests rather than outside conduit.