내가 Axios를 버리는 이유(스포일러: Wretch로 옮겼습니다!)

저는 지금까지 5년 이상 웹 개발 분야에서 일해 왔지만 첫 날부터 제 마음속에 한 가지 질문이 있었습니다. 왜 Axios가 HTTP 클라이언트에 대해 항상 "가는 곳"입니까? 경쟁자가 없는 것 같은 이유는 무엇입니까?
가져오기 API에 대한 많은 기사가 있지만 여전히 인터셉터(미들웨어 패턴)와 클라이언트의 구성 가능한 인스턴스가 필수적이라는 것을 알았습니다. 특히 여러 HTTP 클라이언트가 있는 상용 등급 애플리케이션의 경우 많은 추가가 필요합니다. 헤더가 여기 저기 있고 복잡한 오류 처리가 있습니다.

동기 부여

1. Axios는 최근에 많은 브레이킹 체인지가 있었습니다.

최근 Axios는 몇 가지 주요 변경 사항과 버그가 포함된 v0.27.0을 출시했습니다. 8년이 넘은 패키지가 여전히 v1.0.0이 아닌 것을 상상하기는 어렵습니다. 그들은 마침내 시맨틱 버전 관리를 따를 계획이었지만(참조: github.com/axios/axios/issues/4614). Renovate와 같은 자동 패키지 관리에는 이미 많은 문제가 있습니다. 깨지기 쉬운 코드베이스는 말할 것도 없습니다.

2. Axios 코드베이스는 취약합니다.

이 움직임의 트리거 포인트는 v0.27.0이 의도하지 않게 FormData 처리를 중단한다는 것입니다(참조: https://github.com/axios/axios/pull/4640 ). 모바일 문제를 해결하면 브라우저 버그가 발생합니다. 이것은 현재 관리자가 지원하는 플랫폼과 고대 코드의 작동 방식에 대한 지식이 부족함을 보여줍니다. 말할 것도 없이 v0.27.0은 PR이 병합된 지 1년 후에 배송되었으며 더 많은 문제가 몇 년 동안 해결되지 않은 상태로 남아 있었습니다. 모멘텀이 낮기 때문에 이 패키지가 꾸준하게 앞으로 나아갈 수 있을지 의심스럽습니다.

// Some example for weird design choice, it calls your interceptor in the reverse order.
// ref: https://github.com/axios/axios/issues/841
const instance = axios.create();
instance.interceptors.request.use(function () {/*This will run second*/});
instance.interceptors.request.use(function () {/*This will run first*/});

3. Axios는 여전히 이전 XMLHttpRequests API를 사용하고 있습니다.

그 이유 중 하나는 Axios가 여전히 이전 XMLHttpRequests API를 사용하고 있기 때문입니다. Fetch API를 통해 무료로 얻을 수 있는 많은 처리 및 해킹을 수동으로 구현해야 합니다. Fetch API는 대부분의 브라우저에서 지원하므로 2022년에는 표준이 되어야 합니다. Fetch API 기반 HTTP 클라이언트는 또한 일반적으로 번들 크기가 더 작아집니다.

그래서 거기에서 선택은 무엇입니까?

따라서 목표는 매우 명확합니다. Fetch API 기반 HTTP 클라이언트는 보기 좋은 구문과 적극적인 유지 관리를 제공합니다. 약간의 조사 후 몇 가지 선택 사항이 있지만 모두 내 기준에 맞지는 않습니다.

Got(Node Js 전용)

superagent(또한 XMLHttpRequests 기반)

Gaxios(Node Js 전용)

마지막으로 Ky와 Wretch라는 두 명의 견고한 참가자를 얻었습니다. 둘 다 작은 번들 크기(~3KB, Axios는 6.7KB)의 새로운 Fetch API 기반 HTTP 클라이언트입니다.

Ky
Ky는 몇 가지 흥미로운 기능을 제공하는 Got의 동일한 그룹에 의해 생성됩니다. Like는 2xx가 아닌 상태 코드를 오류로 취급하고 실패한 요청 및 이벤트 후크(Axios 인터셉터와 같은)를 재시도합니다.

const instance = ky.create({
  headers: {
    rainbow: 'rainbow',
    unicorn: 'unicorn'
  }
});

instance.extend({
  hooks: {
    beforeRequest: [
      async ({request, options, error, retryCount}) => {/*request interceptor*/}
    ]
  }
});

instance.extend({
  hooks: {
    beforeError: [
      async (error) => {/*error interceptor*/}
    ]
  }
});

instance.extend({
  hooks: {
    afterResponse: [
      async (error) => {/*response interceptor*/}
    ]
  }
});

Wretch
반면에 Wretch는 함수 연결 방식을 사용합니다. 일반적인 오류 유형을 별도의 도우미 메서드로 분할하므로 매번 인터셉터를 생성할 필요가 없습니다.

const instance = wretch()
  .auth("Basic d3JldGNoOnJvY2tz")
  .headers({ "Content-Type": "text/plain", Accept: "application/json" })

// helper methods to directly intercept common error
instance()
  .badRequest(err => console.log(err.status))
  .unauthorized(err => console.log(err.status))
  .forbidden(err => console.log(err.status))
  .notFound(err => console.log(err.status))
  .timeout(err => console.log(err.status))
  .internalError(err => console.log(err.status))
  .error(418, err => console.log(err.status))
  .fetchError(err => console.log(err))
  .res()

instance.middlewares([
  next => (url, opts) => {/*request interceptor*/}
])

Wretch가 Ky가 아닌 이유

NPM 트렌드를 살펴보면 Ky가 Wretch보다 더 많은 다운로드 스타 등을 가지고 있다는 것을 알 수 있습니다. 그런데 왜 여전히 Wretch를 선택해야 할까요?

Ky가 더 많은 별점과 다운로드 수를 가지고 있지만 대부분 Got 제작자의 과대 광고에 의해 주도된 것 같습니다. 생성된 지 6년이 지난 후에도 v1.0.0을 통과하지 못했습니다. 작성자는 이미 v1.0.0에 대한 이정표를 작성했지만 거의 진행되지 않은 상태로 반년 이상 전입니다. 반면에 Wretch는 이미 v2를 계획하고 있는 v1.7.9입니다. 따라서 현재 어댑터로서 Ky는 Wretch보다 위험합니다. 게다가 저는 Ky의 객체 구성보다 함수 체인 접근 방식에 더 관심이 있습니다. Ky의 extends()보다 깔끔한 함수로 미들웨어를 등록했습니다. 하지만 다소 주관적입니다. 판사.