New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative libraries to request #3143
Comments
As a frontend focused guy who also does node.js from time to time, axios has been my go to. |
Per a recent discussion with @mikeal, I have Bent a try. As a Node.js developer whose been using request for a while now, bent was definitely an easy transition - highly recommended |
Well, it feels kind of wrong to promote my own little library here, but since that's the goal of the issue, here it is: request-compose is a functional, 0 deps HTTP client with support for promises, streams, and a bunch of other useful options, most of which are very close to the ones found in request. I also wrote an article about it. The general idea is that everyone is encouraged to compose their own HTTP clients, specifically tailored to their own needs. As for the bundle size, I've no idea, but it should be pretty small, though this client was never designed to be used in the browser. |
It might be good to add the following columns to the table:
When putting side by side these numbers some libs have thousands of stars and million of downloads weekly, vs others in the hundreds. My 2 cents, OK to ignore and move on, no need to correct or dispute the comment. |
@csantanapr I agree, it might be worth comparing feature sets too. Proxy support, cache support, auth features etc. If you use a specific feature of request and need to find it elsewhere, this would be a good time to talk about it. |
|
Worth a look: |
Axios user here. That way, all our teams can use the same library regardless the environment: browser or nodejs (running in server or serverless). Very well maintained, and all our people love it. |
We have a good comparison between Got also has a migration guide for moving from |
For me, I tend to do wrappers around fetch api, so node-fetch is my goto. Despite the negative aspects, I usually load it onto |
Hey, Wreck (https://www.npmjs.com/package/wreck) is what I use |
I would prefer something that mimics the fetch api on the client. Libs like axios, superagent, etc are higher level abstractions on top of a standard request library. As a replacement for the low-level request library, I'd like to see something that mirrors the low-level equivalent on the client for the purposes of universal js development. Libs like axios and superagent can then just reimplement themselves on top of that, and its users can continue using them, but those shouldn't be considered foundational for this purpose. |
@sindresorhus's comparison is by far the better approach than my list above. https://github.com/sindresorhus/got#comparison
|
I would wrap fetch with nicer API any day. Well, I guess that's just a matter of preference, but implying that the fetch API is great just because it's a defacto standard in the browsers is just wrong. I know it's less noise to have it isomorphic on both sides, but that don't make it any better. |
@kreig303 I haven't looked into the internals of axios, so I wasn't aware of that. Looks like it's currently based on regular XHR's, which makes sense, since it's a solution for both client and server requests. I simply meant that axios is pretty feature rich, and something a little more bare bones should be considered for a foundational module like a replacement for request, and then let other more feature rich libs build on top of that if they desire. I opted for something that mirrors the fetch API specifically for the purposes of having a consistent API on both client and server (like the XHR's that underly axios), and because it's the logical successor to XHR's. If a nicer API wrapper is desired, there's plenty of opportunity to wrap it and release another library with that optimal API, but I'm all for feature and API parity between client and server wherever it can be done. |
Well, one of the issues we have in request is too many features, and too much exposed state, even the one that's considered internal. It's both a curse and a bless to have so many features. It's a bless because that's why it is so popular, and it was first. It's a curse because without a huge amount of constant effort to keep the codebase clean, straightforward, and generally exciting to work with, the project eventually dies. And that's not even a request's problem, it's the user's own perspective of always wanting to put something out of their own layer, and instead put it under the blanket somewhere else. Well, I guess axios have the same faith .. So what we can all do instead, is put at least some amount of effort into understanding how the wheel works, and then try to think through each individual task at hand, and see which wheel fits best. |
@ofrobots that's a bit of a selective screenshot for such a popularly used library. Here's mine: FWIW I don't recall if I'd used it as a back-end lib, so I am in no position to verify your claims (unless you had a peculiar use case it didn't cover). |
The comparison table in the README of got looks more detailed than the table here. |
The npm package `request` has been deprecated. request/request#3142 The main suggested alternative is `node-fetch`, which we already use. request/request#3143 This change replaces `request` and `request-promise` users with `node-fetch`.
My default would be edit: Some more reflecting has me thinking that node-fetch more acceptable testing and coverage and is probably the “safer” bet. It’s really not used in more than a handful of places. |
You might want to add undici - it's made by the nodejs team. |
What is the alternative for this Node.js code?: var request = require("request")
/* var parser = require("robots-txt-parser") */
var options = {
url: "https://google.com/",
headers: {
'User-Agent': 'Mozilla/5.0 (compatible; Alternabot/1.0; +https://example.info/path/to/alternabots/info.html)'
}
};
function success(error, response, body) {
if (error !== undefined) {
return
}
console.log("Is fetched: " + ((response && response.statusCode) == 200).toString())
console.log("Content: " + body)
}
request(options, success) This Node.js code 101 comments LOL! |
Shameless plug: I've just updated request-micro to V2, now written in typescript. It weighs in at 7kb and has no dependencies. If you just need standard HTTP(s) stuff its the lightest-weight you can get. It's been getting a non-trivial >2k downloads a week for at least a year and is in use in several production systems, so I am confident it is stable and safe to use. It is only for Node, but it is the smallest library in the OP table (which no longer has accurate sizes, sometimes off by a factor of over 50). |
reconbot commentedApr 1, 2019
•
edited by mikeal
Since the announcement of request going into "maintenance mode" (full details in #3142) I'd like to collect a list of alternative libraries to use. Please comment below and I'll update this table. When we have a list of good alternatives we should add this to the readme.
In no particular order and dreadfully incomplete;
The text was updated successfully, but these errors were encountered: