Alternative libraries to request
reconbot opened this issue Β· 104 comments
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;
Package Name | Bundle Size | API Style | Summary |
---|---|---|---|
node-fetch | 0.4kb | promise / stream | A light-weight module that brings window.fetch to Node.js |
bent | 1kb | fp / promise / stream | Functional HTTP client w/ async/await |
got | 48.4kb | promise / stream | Simplified HTTP requests |
make-fetch-happen | 442kb | promise / stream | make-fetch-happen is a Node.js library that wraps node-fetch-npm with additional features node-fetch doesn't intend to include, including HTTP Cache support, request pooling, proxies, retries, and more! |
axios | 11.9kb | promise / stream | Promise based HTTP client for the browser and node.js |
unfetch | 1kb | promise / stream | Tiny 500b fetch "barely-polyfill" |
superagent | 18kb | chaining / promise | Small progressive client-side HTTP request library, and Node.js module with the same API, sporting many high-level HTTP client features |
tiny-json-http | 22kb | promise | Minimalist HTTP client for GET and POSTing JSON payloads |
needle | 164kb | chaining / promise | The leanest and most handsome HTTP client in the Nodelands |
urllib | 816kb | callback / promise | Help in opening URLs (mostly HTTP) in a complex world β basic and digest authentication, redirections, cookies and more. |
As a frontend focused guy who also does node.js from time to time, axios has been my go to.
Easy API, from Facebook, works on browsers and node? Done
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:
- Number of stars in Github (yes I already know this is not the only factor when choosing a lib)
- Number of npm downloads (maybe weekly, same stat as npm website, and yes I already know this is not the only factor when choosing a lib)
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.
axios
gets my vote, especially as a front-ender.
Worth a look: ky
(frontend) and ky-universal
(isomorphic)
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
, request
, node-fetch
, axios
, and superagent
in the got
readme: https://github.com/sindresorhus/got#comparison
(PR welcome if you see any inaccuracies. We've tried to keep it as neutral as possible)
Got also has a migration guide for moving from request
: https://github.com/sindresorhus/got/blob/master/migration-guides.md
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 global.fetch
in node, so I can rely on it always being available, much like in the browser (via polyfill for older browsers). Can also use isomorphic-fetch
which is pretty much a wrapper around node-fetch for node, and the fetch polyfill (or already available fetch) in browser. Since I don't have to support legacy browsers, I just use the global, and establish the global for use in node.
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
node-fetch/isomorphic-fetch
is a suitable low level building block for most clients. I'd love to see a fetch based request shim.
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).
@Velveeta I see where you're going with this, I just don't know if meta-libs are the way to go.
My vote from Frontend is for axios
. Tiny, stable and predictable.
I personally use wretch for both my FE- and BE projects - mainly because the API is really intuitive.
A wrapper around fetch - works well with node-fetch as well.
For folks seeking for an axios
-like experience on top of the fetch
API, there is gaxios
. It was built by a developer at Google and currently powers all the HTTP interactions of the Google API's Node.js client, so it seems safe to consider it battle tested and actively used!
(π at @JustinBeckwith)
Hey, Wreck (https://www.npmjs.com/package/wreck) is what I use
It's also the underlying http client for the hapijs framework. The implementation is very clean to boot.
Axios may work okay in the browser, but that hasn't been our experience with it on Node.js. Also, I am not sure if it is actively maintained anymore.
I use axios in Node with great satisfaction. Mainly in lambdas and mainly because it's feature rich yet it doesn't come with a crazy dependency chain. @ofrobots what has been your experience with it in Node?
As a frontend focused guy whonalso does node js from time to time, axioms has been my go to. Easy API, from Facebook, works on browsers and node? Done
I didn't know it was Facebook? But yes, this is my goto library for all API access.
We use this library tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Small, works in the browser and on the server and is built on the concept of plug-ins. The library was created to allow simultaneous use of several types of complex caching.
Did anyone use typed-rest-client from Microsoft? Seems like nicely maintained package written in TypeScript (for me it's a big plus).
this should include wreck
(from the hapi
ecosystem)
I have recently been using https://github.com/grantila/fetch-h2 with great success
Is there currently any known compatible drop-in replacement? It is integrated into KOA and giving me stream-trouble
As was mentioned in the beginning of the issue, I have been working on another library that I now prefer to use called bent
.
For a while bent
hasnβt been designed to work in the browser. Since the API is pretty stable now, I spent some time writing a browser version on top of fetch
. Instead of trying to browserify the Node.js version, the browser version is its own entry point in package.json.
So, ya, bent
has browser support now and itβs quite good:
- zero dependencies or polyfills (entirely built on fetch and ArrayBuffer, so no Buffer or Stream polyfill and no deps to bundle)
- ~2K webpack bundle un-minified or gzipped (someone should let me know what this is after their preferred minifiers and compressors).
- All tests are passing in headless chrome, which have 100% coverage in the Node.js version (still donβt have a great way to do automated browser coverage testing)
This is great @mikeal
@csantanapr thanks! :)
axios can crash your node service: axios/axios#1804
For me, the top concerns are:
- Does it work with minimal config in my corporate environment? (contributing factors: corporate proxies are HTTP for both HTTP and HTTPS targets, not all proxies handle all certs correctly, in the same way, ...)
- This one particularly stopped me from switching off Request a year or so back.
- Does it support streaming, for those cases where I need to, say, proxy file uploads/downloads?
After that, I don't care what the interface looks like so long as the most common operations are convenient. I also am not overly concerned with the size, server side, though that is important if you want to reuse the same library on both ends.
EDIT: Yeeeaaaah can't exactly say I blame you there.
EDIT 2: Guess I'll take a look at node-libcurl
.
@joedski ya, the proxy stuff is not widely supported outside of request. And TBH, given the amount of work it took to get that working and to support it, Iβm not surprised nobody wants to do it, including me ;) Iβve done it once and Iβm not exactly jumping up to write it again for bent π€·π½ββοΈ
Finally I've start to use node-libcurl
library for making requests from nodejs. Because it uses native curl library, which is very mature & tested for years in production. It works flawlessly with all kind of proxies, redirects, and has promise & stream interfaces.
teeny-request (>1mio weekly downloads)
Drop-in replacement for request, but much smaller - and with less options. Uses node-fetch
under the hood. Pop it in where you would use request
.
node-fetch
is being reported incorrectly and only the "browser" version is reported (defeating the point of a Node.js list). This is what seems to be wrongly measured:
Instead, either of these should be measured:
- https://unpkg.com/node-fetch@2.6.0/lib/index.js
- https://unpkg.com/node-fetch@2.6.0/lib/index.mjs
- https://unpkg.com/node-fetch@2.6.0/lib/index.es.js
They are all around ~40kb
unfetch
is also incorrectly reported:
- The homepage says that "Use in Node.JS is handled by isomorphic-unfetch", so it should be reporting the combination of both.
isomorphic-unfetch
uses node-fetch (code, docs) for Node.js, so its reported size should be at least that of node-fetch (see my previous comment).
Since it has been brought up so much I should say a bit about my experience with node-fetch
.
First of all, itβs quite an achievement. The amount of code and engineering effort that has gone in to it is much greater than what we ever put into request. fetch
seems like a small API and I think people assume the effort to provide a compatible API in Node.js is nominal, but it really is not.
As a result, the code base is massive. Itβs a sizable dependency in Node.js, which you likely wonβt see at all in browser bundles, but itβs not as though dependency size is not an issue in Node.js, particularly in serverless environments.
node-fetch
is indispensable when testing because it does all the work of fully emulating the browserβs APIs, but if youβre using it in an application, even one that is being run in Node.js and in the browser, itβs just too much code and too much indirection to be worth it.
IMO, the right approach at this time for a library that wants to be an http client in both Node.js and browsers is to implement a uniform API with a split implementation using fetch
in the browser and require(βhttpβ)
in Node.js. Applications, and http clients, should not target fetch
or require(βhttpβ)
directly and should not rely on emulating these APIβs on either side. This is actually a lot easier than you might think, as you can see in the implementation of bent
which is incredibly small https://github.com/mikeal/bent/tree/master/src
@mikeal I'm having a hard time squaring
As a result, the code base is massive. Itβs a sizable dependency in Node.js, which you likely wonβt see at all in browser bundles, but itβs not as though dependency size is not an issue in Node.js, particularly in serverless environments.
with the 0.4 kB bundle size listed in the OP, which is the smallest of all the alternatives given?
@domenic the complexity of emulating the browser APIβs is the main problem, itβs a lot of unnecessary code and indirection when trying to debug. Youβve got the Blob API
, youβve got a lot of marshalling for the body
, youβve got almost 400 lines of header marshalling
, and thatβs not even looking at the actual API that gets exposed.
Like I said, itβs impressive, but itβs also just a ton of terse, clever, and ultimately unnecessary code if you want to do anything except emulate the fetch
API.
@mikeal you didn't even mention that there's a tonne more code required for node-fetch to be 100% compatible with the fetch API: it doesn't support readable and writable streams from what-wg (something that you need when emulating environments like Cloudflare Workers.
Hmm, I still don't quite understand how to square "a ton" of "ultimately unnecessary" code with "0.4 kB, less than every other entry on the table and 0.25x the size of bent" (which is supposedly "the right approach" and "incredibly small").
@domenic are you comparing the browser bundle size? Iβm talking about the complexity of debugging these in Node.js. In the browser I would expect most of the node-fetch
code to be non-existent, so I donβt really understand what youβre comparing.
I'm comparing the value in the OP; I'm not sure how that is measured. Perhaps it is not measured correctly, which would be good information to update the OP with!
@domenic ah yes, those are all browser bundle sizes, and since the post is pretty old many of them may be out of date although the bent
figure is still close enough.
@root/request - an 80/20 drop-in replacement written in 500 LoC, < 10kb and ZERO dependencies:
Created and tested against the behavior of request.js, on purpose.
https://github.com/therootcompany/request.js
- API compatible (for the common use cases)
- Promise support
- FormData support
- ZERO dependencies
Hi everyone! Im doing a little research in order find to find a request's worthy replacement for my projects. For now, this is what i've put together: https://github.com/emanuelcasco/http-packages-benchmark
Recommendations and opinions are welcome of course!
Γs request
is now officially deprecated, I could not stress more the importance of officially proposing postman-request
as a feature-complete drop-in replacement for request
, and possibly @root/request
for those who just need a limited subset of request
and don't care about eg. streams.
This allows any package maintainer to drop request
and get rid of the annoying deprecation message without spending more than a few minutes of dev time on this issue, and without having to refactor their entire library or app. It took me quite some time & frustration to figure out even that such drop-in replacements exist.
And yes, I'm aware that just "deprecation" doesn't break anything. Yes, technically everyone can still use request
and possibly continue to use it for maybe even decades to come. That's not what deprecation is supposed to be used for, though. Deprecation IS supposed to act as a call to action, as a "grace period" for people to upgrade their code until someone somewhere decides to pull a plug.
I really, really hate it when "deprecation" is just used to mark "end-of-support" or "end-of-maintenance", as appears to be the case here. But I'd be bothered a lot less buy this, if there was an officially supported AND actively maintained feature-complete drop-in replacement like postman-request
.
In fact, has anyone considered handing over maintenance of this package to the Postman team? Instead of deprecating request
, why not propose for them to port postman-request
to request
and let them become the new official maintainers?
Sorry to promote my own little library here
Designed to be used only in nodejs
const http = require('@zhangfuxing/http');
const assert = require('assert');
(async () => {
// http
const httpRes = await http.get('http://baidu.com');
assert(httpRes.includes('<html>'));
// https
const httpsRes = await http.get('https://cnodejs.org/api/v1/topics?limit=1&mdrender=false');
assert(httpsRes.success === true);
// download file: use pipe
const fs = require('fs');
const res = await http.get('http://localhost:3000', {
responseType: "stream"
})
res.pipe(require('fs').createWriteStream('zfx.txt'))
// or use pipeline
const stream = require('stream');
const util = require('util');
const pipeline = util.promisify(stream.pipeline);
const res = await http.get(`${url}/stream`, {
responseType: "stream"
});
await pipeline(res, fs.createWriteStream('zfx.txt'));
// post Buffer
const res = await http.post('http://localhost/upload', Buffer.from('abc'));
assert(res.success === true);
// post Stream
const fs = require('fs');
const readStream = fs.createReadStream('./index.js');
const res = await http.post('http://localhost/upload', readStream);
assert(res.success === true);
// post json
const data = {
username: 'zfx',
password: 'password'
};
const res = await http.post('http://localhost/upload', data);
assert(res.success === true);
// post application/x-www-form-urlencoded
const data = {
username: 'zfx',
password: 'password'
};
const options = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
}
};
const res = await http.post('http://localhost/upload', data, options);
assert(res.success === true);
// post FormData
const FormData = require('form-data');
const form = new FormData();
const fs = require('fs');
const readStream = fs.createReadStream('./index.js');
form.append('my_field', 'my value');
form.append('my_buffer', Buffer.from('abc'));
form.append('my_file', readStream);
// Set filename by providing a string for options
form.append('my_file', readStream, '1.js' );
// provide an object.
form.append('my_file', readStream, {
filename: 'bar.jpg',
contentType: 'image/jpeg',
knownLength: 19806
});
const formHeaders = form.getHeaders();
const res = await http.post('http://localhost/upload', form, {
headers: {
...formHeaders,
},
});
assert(res.success === true);
// head
const res = await http.head(url);
assert(res.statusCode === 200);
assert(res.statusMessage === 'OK');
assert(res.headers && typeof res.headers === 'object');
assert(res.statusCode === 200);
assert(res.data === '');
// options
const res = await http.options(url);
assert(res === 'GET,HEAD,POST,PUT,PATCH,DELETE');
})().catch(console.error);
I've found Wretch to be the best option if you're building modern typescript SPAs, given its written in TS to begin with. Is effectively feature equal to Axios and supports additional middleware. I think the API is a little nicer in a couple of places compared to Ky too.
Any of these support http2?
near drop in replacement?
Really sad to see this library being deprecated. I like axios, but foe some purposes, request was my fist choice.
Any of these support request timing? Like the time to first byte, network lag and so on?
I'm using request library for a project and timing is crucial for it.
Google offers gaxios https://github.com/googleapis/gaxios - axios api over node-fetch
We have a good comparison between
got
,request
,node-fetch
,axios
, andsuperagent
in thegot
readme: https://github.com/sindresorhus/got#comparison
(PR welcome if you see any inaccuracies. We've tried to keep it as neutral as possible)Got also has a migration guide for moving from
request
: https://github.com/sindresorhus/got/blob/master/migration-guides.md
Got's migration guide for moving from request
has moved to:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md
Might I suggest adding postman-request? I'll be trying this one out on my next project. Anyway, this is what it is said about it on the documentation...
This is a fork of the excellent request module, which is used inside Postman Runtime. It contains a few bugfixes that are not fixed in request.
Redaxios is like 800 byte using native fetch https://github.com/developit/redaxios
Gosh!! I was figuring this out from 3 hours checked my code again and again. And it gave me error 404, I was frustrated. Thanks a lot. I think I'll go with Fetch.
https://www.npmjs.com/package/teeny-request is another option, used by Google APIs.
Like request, but much smaller - and with less options. Uses node-fetch under the hood. Pop it in where you would use request. Improves load and parse time of modules.
What would be better node-fetch
or the forked version of requests
which is now maintained by PostMan. I have only just started my Node journey so require something simple.
axios's timeout seems never to be fixedππΏ
I was very surprised to not see phin here.
How about url-request
?
How about
url-request
?
Still a bit young (1 day!) and (thus) lacks some features, but looks promising - will watch is closely.
@cjk thanks for feedback, what features will you like? If you could be more specific.
Quick q. What's the advantage of using these libraries instead of native nodejs http?
@cgarrovillo Small Code => More Impact
try url-request, just look at the feature set and possibilities π€
@cjk thanks for feedback, what features will you like? If you could be more specific.
@Debdut I'm thinking of features like:
- Authentication
- HTTP2
- Proxy-support
- Compression
- Timeout handling
- custom hooks
- Request cancellation
It's not obvious from the docs of url-request
which of those are supported and how.
However, I liked the many examples you provide!
Just keep using request until it stops working.
In angular rxjs and observable are excellent
Any lib has cookie jar like request?
Testing Got HTTP library with node red. β
- npm installed
- added to context
- Now in flow editor, imported got in my js function
Results
Works fine when doing HTTP requests. (made a single test).
FAILS β when doing HTTPS requests. I got :
RequestError: connect ECONNREFUSED 127.0.0.1:443
At first I thought this was something related to node-red env. Later found this is an open issue in got repo: sindresorhus/got#1414. π
And in my opinion, it's enough reason to go for axios instead. β
Just wanted you to know.
@damdauvaotran Any lib has cookie jar like request?
See got.js, the migration guide.
Why is gaxios not mentioned?
FWIW, here is an NPM trends link that compares all the projects mentioned at the top. While it's not the only factor involved in the decision, popularity is quite important for us and on most projects.
As of this writing, node-fetch
is the most popular alternative.
Interesting @ericsnap ... node-fetch and axios are first and third (nearly second) in popularity, respectively.
And I note the following strapline from the gaxios docs:
An HTTP request client that provides an axios like interface over top of node-fetch
So gaxios combines two of the most popular libraries. I've been converting across to gaxios and it is super fun to use.
After reviewing a bunch of the current request alternatives, I've taken the plunge @sindresorhus into got. It took me about a day to get used to the API (docs have been fairly good). I've experienced a significant reduction in LoC due to extend
and setting so much up in one place, then the call sights and error handling are usually only a handful of LoC. It feels so much slicker than the request, request-promise, request-promise-native dance. A great feature-set also. Great work and thanks muchly @sindresorhus!
I wasn't looking forward to the migration, but I feel so much cleaner now.
no @types/axios but there are types for node-fetch and got - im going with node-fetch
@danday74 axios provides its own type definitions in the same way as node-fetch, so there is no need to avoid axios in terms of use with TypeScript.
@yudai-nkt thanks for the info, it seems they are built in to axios and do not have their own @types/axios package? just axios on its own seems to be working well with typescript for me.
node-fetch is cumbersome - I wrote 20 lines of code to do what axios does in 5 - back to axios for me - not to mention axios error handling is so much simpler - thanks
As a frontend focused guy who also does node.js from time to time, axios has been my go to.
Easy API, from Facebook, works on browsers and node? Done
Was axios developed by facebook?
Since fetch
in a browser is a very well standardized interface, node-fetch
seems the most attractive. If alternatives are better under the hood, they should still use the same interface as fetch
for the average use cases. We don't need so many different ways to make a simple HTTP1.1 request, and I'm sick of dealing with them.
For people who have to take care of HTTP connect proxies (e.g. with the software Squid
): I have not been able to get needle
to work (the callback function is never executed). With axios
everything works fine.
axios.get('https://api.abuseipdb.com/api/v2/check', {
headers: {
'Key': process.env.ABUSE_IP_DB_KEY,
'Accept': 'application/json',
},
params: {
ipAddress: '123.123.123.123',
},
proxy: {
protocol: 'http',
host: 'corporate-proxy',
port: 3128,
auth: {
username: null,
password: null
}
}
})
.then(function(response){
// handle success
// console.log(response.data);
// console.log(response.status);
// console.log(response.statusText);
// console.log(response.headers);
// console.log(response.config);
console.log(`ip: 123.123.123.123`);
console.log(`response.data.data.abuseConfidenceScore: ${response.data.data.abuseConfidenceScore}`);
})
.catch(function(error){
// handle error
console.log(error);
})
.then(function(){
// always executed
});
Thanks buddy.
Here is a simple wrapper around node-fetch that provides the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY support.
You can see an example of using QCObjects for universal client requests here:
+1 for @csantanapr's suggestion of adding numbers, and thanks to @sindresorhus for sharing the comparison:
got |
request |
node-fetch |
ky |
axios |
superagent |
|
---|---|---|---|---|---|---|
Issues open | ||||||
Issues closed | ||||||
Downloads | ||||||
Coverage | ||||||
Build | ||||||
Bugs | ||||||
Dependents | ||||||
Install size | ||||||
GitHub stars | ||||||
TypeScript support | ||||||
Last commit |
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;
Package Name Bundle Size API Style Summary
node-fetch 0.4kb promise / stream A light-weight module that brings window.fetch to Node.js
bent 1kb fp / promise / stream Functional HTTP client w/ async/await
got 48.4kb promise / stream Simplified HTTP requests
make-fetch-happen 442kb promise / stream make-fetch-happen is a Node.js library that wraps node-fetch-npm with additional features node-fetch doesn't intend to include, including HTTP Cache support, request pooling, proxies, retries, and more!
axios 11.9kb promise / stream Promise based HTTP client for the browser and node.js
unfetch 1kb promise / stream Tiny 500b fetch "barely-polyfill"
superagent 18kb chaining / promise Small progressive client-side HTTP request library, and Node.js module with the same API, sporting many high-level HTTP client features
tiny-json-http 22kb promise Minimalist HTTP client for GET and POSTing JSON payloads
needle 164kb chaining / promise The leanest and most handsome HTTP client in the Nodelands
urllib 816kb callback / promise Help in opening URLs (mostly HTTP) in a complex world β basic and digest authentication, redirections, cookies and more.
Hello, I have took the references from the API of request/request and created a new HTTP request library Poke in written typescript by myself. Appreciate if anyone can give it a try and make things better together :) CheersπΊ
The comparison table in the README of got looks more detailed than the table here.
My default would be node-fetch
, but got
while I've never personally used it seems interesting.
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.