Alternative libraries to request

[reconbot]

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.

[jeffscottward]

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

[bnb]

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 💖

[paambaati]

@reconbot You might want to add got, needle and urllib.

[simov]

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.

[csantanapr]

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.

[reconbot]

@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.

[kreig303]

axios gets my vote, especially as a front-ender.

[JamesMGreene]

Worth a look: ky (frontend) and ky-universal (isomorphic)

[rmngrc]

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.

[sindresorhus]

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

[tracker1]

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.

[vdeturckheim]

Hey, Wreck (https://www.npmjs.com/package/wreck) is what I use

[Velveeta]

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.

[kreig303]

@Velveeta I went and looked at the axios codebase and see no evidence that it is based on a "lower-level standard request library". Please tell me how you came to this conclusion?

[reconbot]

@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.

[simov]

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.

[dar5hak]

There's r2 by @mikeal himself. It is meant to be a spiritual successor to request. It has a Promise API and is 16kb compressed.

[ofrobots]

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.

[Velveeta]

@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.

[simov]

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.

[kreig303]

@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).

[sindresorhus]

There's r2 by @mikeal himself. It is meant to be a spiritual successor to request. It has a Promise API and is 16kb compressed.

That library is not maintained. If you want a similar API, I would recommend ky, which is ~1kb minified and gzipped, and maintained by the same people as got.

[attila]

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?

[mikeerickson]

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.

[Tom910]

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.

[stanmots]

Did anyone use typed-rest-client from Microsoft? Seems like nicely maintained package written in TypeScript (for me it's a big plus).

[kreig303]

this should include wreck (from the hapi ecosystem)

[triblondon]

I have recently been using https://github.com/grantila/fetch-h2 with great success

[BananaAcid]

Is there currently any known compatible drop-in replacement? It is integrated into KOA and giving me stream-trouble

[mikeal]

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)

[csantanapr]

This is great @mikeal

[mikeal]

@csantanapr thanks! :)

[Strate]

axios can crash your node service: axios/axios#1804

[joedski]

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.

[mikeal]

@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 🤷🏽‍♀️

[Strate]

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.

[fhinkel]

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.