DEV Community

When do you need axios?

Emmanuel Okiche on August 31, 2019

Introduction Earlier this year when i worked as an Instructor in a bootcamp teaching Full-Stack Software Engineering, a student asked wh...

Read full post

Emmanuel Okiche • Aug 31 '19

Thanks so much for the feedback.
I did not forget to add isomorphic-unfetch.
I just didn't know about it yet. Lol...

About the open issues, react and flutter has 600+ and 5000+ open issues respectively.
Measuring the awesomeness of a library or framework by using only open issues and PRs alone is not a good yardstick. You need to include other variables to your analysis to draw a conclusion that is more precise and reflects the opinion of the community using the said library or framework.

Thanks for the feedback once again and i have mentioned isomorphic-unfetch in the article. But you'll be the one replying to any question related to that library in the comment section ;)

Kriz Poon • Sep 2 '19 • Edited

There is also the request package (npmjs.com/package/request), although for Node only. It has 15M downloads weekly while Axios has 5M only.

Emmanuel Okiche • Sep 3 '19

I'm in trouble. The list never ends :(

David Wickes • Sep 1 '19

Oddly enough I always bring up axios when I want to talk about how not to write an HTTP client. I think a lot of the decisions around the design of its API make it harder to use in the long run. Two examples:

Conflating network errors with valid HTTP responses. While it's initially easier to use, I've found it inevitably leads to confusion about what the source of an 'error' is. I much prefer the explicit handling of different HTTP responses (including 4xx and 5xx) that the fetch api encourages.
What happens when the auto-parsing of JSON fails: nothing. Axios will swallow the error and leave you trying to access properties on a string that don't exist. Extremely hard to debug. The owner recognises the problem but has no solution

With axios we gain some convenience but at the expense of control and transparency. What we have to ask is whether it is worth the trade. Is the removal of a single method call to parse JSON worth the time it will take to work out what's going wrong when it (inevitably) does go wrong? Is the convenience of throwing on a 404 worth the pain of reconfiguring the client so that it doesn't throw on a 404 when I'm expecting a 404 response?

I prefer simple but verbose in the style of fetch; everyone has to make their own mind up.

Emmanuel Okiche • Sep 2 '19 • Edited

Thanks for the feedback.
You have made a clear case with some strong points.
I learnt from your comment and i appreciate it.

Every library has its downsides and tradeoffs. You just have to choose what you can manage and which gets the job done.

Axios shines in terms of convenience and has a simpler API. This might be what a developer wants at some point. The issue link you shared definitely has some workarounds. No library is perfect. I absolutely get your point and you passed your message in a very clear and consise way. I respect that.

This article was just a way to show beginners why thousands of articles and tutorials use third party libraries like axios for node.js based projects. Most articles don't tell them why.

Ahh...lastly, i would update the article with my conclusion. Wrote this article at midnight so i missed that.

Thanks once again David

Samuel Sharpe • Aug 31 '19 • Edited

Enjoyed the article, thank you for sharing 👍In addition to this list, I find the biggest advantage of axios is that it is using XHR internally, meaning we can get updates on request progress 🎚️(onUploadProgress and onDownloadProgress).

Pavindu Lakshan • Sep 1 '19

Didn't know that until now. Thanks for sharing..

Chris Achard • Aug 31 '19

The other thing that I've found that axios can do that I couldn't get fetch to do correctly was to properly save a cookie to use for post requests over https (I think that was the issue) in a React Native application. It's been awhile, so I don't 100% remember the specifics - but I remember that axios worked when fetch didn't.

Thanks for the post!

Emmanuel Okiche • Sep 1 '19

Ah nice.
You're welcome

Vitaly Pinchuk • Nov 26 '19 • Edited

this means axios is not maintained.

Totally agree! Axios loooks like is not maintained.

Interesting discussion about 1.0
github.com/axios/axios/issues/1333...
Issue about esm version since 2018
github.com/axios/axios/issues/1879
Initial maintainers:
github.com/axios/axios/issues/1965...
Nowadays maintainer:
github.com/axios/axios/issues/2531...

Emmanuel Okiche • Sep 1 '19

Thanks for the feedbacks.
Would update the article by Monday with examples to show more differences between the two.
More ideas are coming in :)

Brian Barbour • Aug 31 '19

I often use isomorphic-unfetch myself, it's a good choice

Shubham Battoo • Aug 31 '19

Error handling is very nicely done in axios too. With fetch lots of if statements for simple error handling.

Emmanuel Okiche • Sep 1 '19

Ah this is true. I intended adding that to the article but forgot.
Yeah. fetch throws for only network errors and you'll have to manually check for other errors unlike axios.

Guess I'll have to add this to the article with an example.

Thanks for sharing