I do miss the axios extensions tho, it was very easy to add rate-limits, throttling, retry strategies, cache, logging ..
You can obviously do that with fetch but it is more fragmented and more boilerplate
I do miss the axios extensions tho, it was very easy to add rate-limits, throttling, retry strategies, cache, logging ..
You can obviously do that with fetch but it is more fragmented and more boilerplate
Totally get that! I think it depends on your context. For Lambda where every KB and millisecond counts, native fetch wins, but for a full app where you need robust HTTP handling, the axios plugin ecosystem was honestly pretty nice. The fragmentation with fetch libraries is real. You end up evaluating 5 different retry packages instead of just grabbing axios-retry.
Sounds like there's space for an axios-like library built on top of fetch.
I think that's the sweet spot. Native fetch performance with axios-style conveniences. Some libraries are moving in that direction, but nothing's really nailed it yet. The challenge is probably keeping it lightweight while still solving the evaluating 5 retry packages problem.
Is this what you're looking for? https://www.npmjs.com/package/ky
I haven't used it but the weekly download count seems robust.
Ky is definitely one of the libraries moving in that direction. Good adoption based on those download numbers, but I think the ecosystem is still a bit fragmented. You've got ky, ofetch, wretch, etc. all solving similar problems. But yeah, ky is probably the strongest contender right now, in my opinion.
Like axios can do it if you specify the fetch backend, it just won't do the .json() asynchronously.
I'm actually not a big fan of the async .json from fetch, because when it fails (because "not json"), then you can't peak at the text instead. Of course, you can clone the response, apparently, and then read text from the clone... and if you're wrapping for some other handling, it isn't too bad.
[dead]