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.
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oddly enough I always bring up
axioswhen 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
fetchapi 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.
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