[초월번역] Axios vs. Alova

Ethan Yu·2023년 9월 8일

초월번역

목록 보기

1/2

Alova.js: 이 라이브러리는 무료로 다 해줍니다!

현재 서비스하는 [ 로키토키 ]를 포함해 개인 프로젝트에서도 axios + react-query의 조합을 많이 사용하고 있는데요, axios의 대항마가 나타났다고 하여 서둘러 알아보았습니다. 가벼운 프로젝트지만 데이터 캐싱이 필요한 상황에서는 아주 유용한 라이브러리가 될 것 같다는 생각입니다. 두 라이브러리를 비교하는 좋은 글이 있어 우리말로 옮겨봤습니다(🤬초월 번역 주의).

👉 원본

👶 Alova: Axios의 대항마

Axios.
Promise 기반의 HTTP 클라이언트로서 벌써 10년동안 그 자리를 굳건히 지키고 있는 그 라이브러리. 4천4백만 회의 다운로드를 훌쩍 넘긴 그 라이브러리.

다시 생각해보자구요. Axios가 히트 치기 전에 우리는 어떻게 요청을 보내고 있었냐구요.
콜백 함수를 넘겨 비동기 작업을 처리해주어야 했죠. 그러다 💥콜백 지옥💥에 빠지기라도 해봐요. 상상만 해도 끔찍했다구요.

Axios는 이 콜백 지옥의 문제를 어느 정도 해결해줄 수 있었기 때문에 빠르게 인기를 얻기 시작했습니다. 그러나 시간이 점점 흐르면서 Axios도 노후화되기 시작했습니다.

그리고 지금, Alova가 등장했습니다. 작년에 등장한 Alova는 그 특유의 가벼운 크기 덕분에 주목받았고, 매주 1,000회 정도로 다운로드되고 있어요.

아직은 신생아인 Alova가 Axios의 대항마가 될 수 있을까요? Axios의 이용자가 아직 수천배가 넘는데도요?
Alova를 찬찬히 살펴보며 판단해봅시다.🤔

1. 어디서든 사용가능

React, Vue와 같은 UI 프레임워크(라이브러리)들이 많이 사용되고 있지만 Axios는 이러한 프레임워크(라이브러리)에 꼭 들어맞지는 않습니다. 별도로 관리되어야 하기 때문에 운영 측면에서 효율적이지 않기 때문입니다.

Alova는 더 가볍고, 효율적이고, 사용하기 쉽기 때문에 어떤 환경에서든 Axios를 대체할 수 있어요.

2. 엄청나게 작은 크기

엄청나게 큰 번들 사이즈 공포증(Bundle Phobia)이 있는 저는 두 라이브러리의 번들 사이즈를 꼭 확인해봐야겠습니다.
번들 크기
Axios가 11.2kB인 반면 Alova는 4.8kB밖에 되지 않습니다. 거의 두 배 이상 차이나는 셈이죠. 게다가 Axios는 3개 라이브러리에 의존성이 있는 반면, Alova는 다른 어떠한 라이브러리에도 의존하지 않아요.

3. 뛰어난 api 제어력

서비스를 계속 사용하다보면 동일한 api를 반복적으로 호출하게 되는데요, Axios는 반복되는 동일한 api에 대해서 따로 처리해주는 것이 없습니다. 반면에 Alova는 요청 결과를 캐시하고, 공유할 수 있습니다.
카탈로그 페이지에서 상세 페이지로 진입하려고 두 컴포넌트(user)가 동일한 요청을 보냈다고 가정해보겠습니다. 이런 상황에서 Alova는 share method를 사용하여 동일한 요청이 두 번 전달되는 것을 막을 수 있습니다.

import Alova from 'alova';
const client = new Alova({ share: true });
const request = client.get(‘https://api.example.com/users');
client.share(request, [‘user1’, ‘user2’]);

Alova는 요청 결과를 복사하지도, 다른 클라이언트에 몰래 보내지도 않기 때문에 Privacy는 전혀 걱정하지 않아도 됩니다.

4. 간편한 캐싱

Axios는 자체적으로 캐싱 기능을 제공하지 않습니다. 따라서 사용하는 환경에 따라서 부차적인 라이브러리를 사용해주어야 합니다(react-query를 사용하는 것처럼요). 그러나 우리 뛰어난 Alova는 임시 저장 공간에 응답을 무료로 캐싱해줍니다!

Alova는 기본적으로 캐싱 옵션을 활성화합니다. 캐싱 옵션이 활성화되어 있으면 Alova는 요청에 대한 응답을 메모리에 저장해둡니다. 만약 동일한 요청이 또 발생한다면, Alova는 서버에 api콜을 보내는 대신 메모리에서 간편하게 데이터를 꺼내줍니다.

캐시 메모리의 사이즈는 cacheSize 속성을 세팅하여 조절이 가능합니다. 이렇게요.

	const client = new  Alova({  
	cache: true,  
	cacheSize: 1000,  
	});

캐시 메모리가 꽉 차게 되면, Alova는 사용하지 않은 가장 오래된 데이터부터 차례차례 지워 공간을 확보합니다.

5. 간결하지만 완벽한 문법

Axios에서의 데이터 페칭 구문이 살짝 더 복잡합니다. 간단한 GET 요청에서도 차이가 나요.

 //Axios
 import axios from ‘axios’;
 const requestData = () => {
   loading.value = true;
   axios.get(‘http://xxx/index').then(result => {
       data.value = result;
     }).catch(e => {
         error.value = e;
     }).finally(() => {
         loading.value = false;
   });
 }
 onMounted(requestData);

 // Alova
 import { createAlova, useRequest } from ‘alova’;
 const pageData = createAlova({ baseURL: ‘http://xxx' }).Get(‘/index’);
 const { loading, data, error } = useRequest(pageData);

6. Axios와의 유사성

Alova의 요청 구조는 Axios와 동일하기 때문에 쉽게 변경할 수 있어요.

 // axios
 axios.get(‘/index’, {
   headers: {
     ‘Content-Type’: ‘application/json’
   },
   params: {
     userId: 1
   }
 });

 // alova
 const todoListGetter = alovaInstance.Get(‘/index’, {
   headers: {
     ‘Content-Type’: ‘application/json’
   },
   params: {
     userId: 1
   }
 });

7. 페이징 처리는 덤

Alova에는 또 데이터를 페이지 단위로 쪼개주는 기능도 탑재되어 있습니다. 각 페이지는 동일한 개수의 레코드를 가지게 됩니다.

Axios를 이용한다면, 별도의 라이브러리를 사용하거나 언어 자체적으로 무언가를 제공해주지 않는 이상 페이지에 대한 요청을 반복해야 합니다. 하지만 Alova를 사용한다면? Alova는 request-paging을 통해 fancy 하게 이 문제를 해결합니다.

Alova를 통해 요청된 api는 기본적으로 첫 페이지에 대한 레코드를 응답으로 전달합니다. 이 때, 응답에 한 가지 속성을 추가로 끼워넣어 주는데요, 바로 next 라는 속성입니다. 응답은 이런 형태로 전달됩니다.

	{  
		statusCode:  200,  
		message: “Successfully fetched data.”,  
		body:  { … },  
		next: “……../page_2”,  
		…  
	}

next는 다음 페이지에 대한 URL을 그 값으로 가지고 있습니다. 다음 페이지를 원한다면 해당 URL을 다시 쏴주면 됩니다. 심지어 next를 통해 받을 다음 페이지에 대한 데이터는 이전 페이지 데이터를 제공 받는 시점에 같이 사전 로딩 되어 있기 때문에 기다릴 필요도 없이 바로 제공받을 수 있습니다. 사전 로딩된 데이터 역시 캐싱됩니다!

8. 다양한 요청 전략

requestStrategy 속성을 통해 다양한 요청 전략을 설정할 수 있습니다. 아래 요청 전략 중 하나를 선택해 api콜을 보낼 수 있어요.

default : 기본 전략. Alova가 알아서 최적의 요청을 보내줄거예요.
streaming : 데이터를 스트림 형태로 받을 수 있어요. 큰 데이터를 받고자 할 때 유용할 수 있습니다. 메모리에 저장할 필요없이 들어오는 족족이 처리해주면 되니까요.
polling : 응답이 올 때까지 계속 서버에 찔러볼 수 있어요. 엄청나게 긴 시간이 필요한 작업의 결과를 받고자 할 때 유용할 수 있습니다. 보낸 요청의 진행 상황을 쉽게 알 수 있기 때문입니다.