Request's Architecture

[seanstrom]

Hey can some one give me a high level breakdown of request's architecture? I basically want to get some point of views of how this software is perceived and how it actually works. @mikeal

[Freyert]

Yeah doing a total rewrite would be a pain, and refactoring also a pain. As it stands now, the ideas I'm throwing out are probably better off for user land (Which you also see with express). Rewriting basic redirect logic is a fairly simple task and it's pretty easy to do what I'm talking about on your own.

It makes me curious though about what the original intent of this project was? What problem is it solving? If I like breaking off different pieces of logic like I am, should I just call it quits and start using the plain old http module or am I getting something from request? (Not to be contentious, I really do love the work that's been put into request, but I'm just curious to know if I'm not using it to it's full potential.)

[simov]

Yep, the API you are proposing should be implemented as a request wrapper. Good example is Purest which only configures request through its API, it doesn't handle anything HTTP specific directly.

As for request, its purpose is to implement some of the common features that you expect an HTTP client to have. The core HTTP module mainly parses the raw HTTP messages and handles the TCP sockets for you, through its Agent class. Well that's probably overly simplified but it's definitely not a full featured HTTP client, like a browser for example.

Some of the features currently in core were first implemented in request, like the forever-agent, also at that time there were no Streams2 and common Duplex stream interface.

Here is what I'm currently outlining as requirements for my own experiment:

• the client can be used seamlessly like the bare core HTTP module
• each feature should be enabled by option, there is no defaults except the ones you get from core
• each option enables default implementation, you can plug in your own via function
• each default implementation is a separate module set as dependency in the consumer project

I think that's it for now. Oh and btw the redirect logic with all of the request features is not the easiest thing to implement.

[simov]

https://github.com/request/request/issues/1982

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.