Consider supporting Node as a backend

[leostera]

Right now this module is fairly coupled to http/af and lwt and it's thanks to them that it's so damn fast.

It might be of great value to be able to swap out both the Transport layer protocol implementation, and the IO library.

Filing this so I don't forget.

[avsm]

fwiw, now that httpaf has mirageos support, I'm pretty happy to have this coupled with it as it is right now...

[leostera]

Thanks for chiming in @avsm — after some late-night refactoring a few days ago I actually decoupled the core API from the IO layer (Lwt), so this issue sort of stays for me not to forget to check if http/af is compilable with BuckleScript.

If it isn't, that means that we can't use HttpKit with a node backend. I'd like it very much to support a node backend, so we can gradually go from OCaml/Reason+Node to OCaml/Reason Native.

It if is, then the current version should be enough since it's already decoupled from Lwt and would only require a package to connect it to the Node runtime (bindings to lower level socket APIs, etc).

Any thoughts?

[leostera]

Some thoughts: currently the Request interface should be easy enough to fulfill by using for io type Promise.t (or any alternative like Repromise.t) and the send function with an external to fetch.

I recognize that the name feels the opposite, but in the context of creating a request we are not fetching it, we send it. We sort of fetch responses.

When it comes to the server side, binding to the http and https modules from node’s stdlib seems like the right thing to do. Not sure how the TLS story happens around there, but I suspect that if the primitives exist they should be straightforward to bind to. If they don’t, then we can pick an npm package to fill this in.

[lessp]

This may be relevant @Ostera:

https://github.com/aantron/luv