Back

O Que o Axios Ainda Oferece em Relação ao Fetch

O Que o Axios Ainda Oferece em Relação ao Fetch

A Fetch API amadureceu significativamente. Está integrada em todos os navegadores modernos, disponível nativamente no Node.js desde a v18 através do Undici, e é capaz de lidar com JSON, cancelamento de requisições e streaming. Para muitas requisições de API no frontend, ela é genuinamente suficiente.

Então por que as equipas continuam a recorrer ao Axios? Não por hábito, mas porque o Axios ainda resolve problemas específicos da experiência do programador que o Fetch deixa por sua conta. É aqui que essa lacuna realmente se manifesta.

Pontos-Chave

  • O Fetch resolve com sucesso em respostas 4xx e 5xx, forçando verificações manuais de response.ok em cada requisição.
  • Os interceptors do Axios centralizam preocupações transversais como tokens de autenticação, logging e normalização de erros sem boilerplate por requisição.
  • A configuração partilhada via axios.create() simplifica o trabalho com múltiplas APIs que necessitam de diferentes base URLs, headers ou timeouts.
  • O acompanhamento do progresso de uploads e as opções de timeout integradas continuam a ser exclusivos do Axios, algo que o Fetch não consegue igualar nativamente.
  • Para projetos pequenos com necessidades mínimas de HTTP, o Fetch é a opção padrão correta, sem dependências.

Axios vs Fetch: Onde Estão as Diferenças Reais

1. Tratamento de Erros HTTP que Funciona por Padrão

O Fetch só rejeita em caso de falha de rede. Uma resposta 404 ou 500 resolve com sucesso — tem de verificar response.ok você mesmo todas as vezes.

// Fetch — tem de verificar manualmente
const res = await fetch('/api/user');
if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
const data = await res.json();

// Axios — rejeita automaticamente em 4xx/5xx por padrão
const { data } = await axios.get('/api/user');

Em aplicações grandes com dezenas de endpoints, essa verificação manual torna-se em boilerplate repetitivo. O Axios elimina a maior parte disso por padrão.


2. Interceptors de Requisição e Resposta Integrados

Esta é a funcionalidade que a maioria dos programadores cita ao escolher o Axios. Os interceptors permitem anexar lógica — tokens de autenticação, logging, normalização de erros — uma única vez, globalmente, sem tocar em requisições individuais.

axios.interceptors.request.use(config => {
  config.headers.Authorization = `Bearer ${getToken()}`;
  return config;
});

axios.interceptors.response.use(
  response => response,
  error => {
    if (error.response?.status === 401) redirectToLogin();
    return Promise.reject(error);
  }
);

Com o Fetch, pode simular isto envolvendo o fetch() numa função personalizada. Mas esse wrapper não é componível, não é empilhável, e é você que o tem de manter.


3. Configuração Partilhada com Instâncias do Axios

O Axios permite criar instâncias isoladas com base URLs, headers e timeouts predefinidos — um padrão genuinamente útil quando a sua aplicação comunica com múltiplas APIs.

const apiClient = axios.create({
  baseURL: 'https://api.example.com',
  timeout: 8000,
  headers: { 'X-App-Version': '2.1.0' },
});

Replicar isto de forma limpa com Fetch requer uma classe wrapper ou uma factory function. É exequível, mas é mais escopo de que tem de tomar conta.


4. Acompanhamento do Progresso de Uploads

O Fetch ainda não tem uma API nativa padronizada de progresso de upload nos navegadores. O Axios expõe onUploadProgress diretamente, suportado por XMLHttpRequest por baixo nos navegadores.

await axios.post('/upload', formData, {
  onUploadProgress: e => {
    if (e.total) {
      console.log(`${Math.round((e.loaded / e.total) * 100)}%`);
    }
  },
});

Se precisa de progresso de upload numa configuração apenas com Fetch, terá de voltar ao XMLHttpRequest puro. Isso é uma regressão real.


5. Configuração de Timeout Sem o Boilerplate do AbortController

O Axios aceita uma opção timeout diretamente. O Fetch exige que configure manualmente AbortController e setTimeout — o que funciona, mas adiciona ruído.

// Axios
await axios.get('/api/data', { timeout: 5000 });

// Equivalente com Fetch
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), 5000);
try {
  const res = await fetch('/api/data', { signal: controller.signal });
} finally {
  clearTimeout(id);
}

Os ambientes modernos também suportam AbortSignal.timeout(), que encurta isto consideravelmente, e o suporte nos navegadores já está amplamente disponível.


Comparação Rápida: Funcionalidades do Axios vs Fetch API

CapacidadeFetchAxios
Rejeição de erros HTTPVerificação manual de response.okAutomática por padrão
InterceptorsWrapper personalizado necessárioIntegrados
Instâncias partilhadasPadrão factory manualaxios.create()
Progresso de uploadNão suportado nativamenteonUploadProgress
Timeout de requisiçãoAbortController + setTimeoutOpção timeout
Tamanho do bundle0 KB (nativo)~15 KB gzipped

Conclusão

O Fetch não é inadequado. Para clientes HTTP JavaScript simples — alguns endpoints, sem lógica de autenticação partilhada, sem progresso de upload — é a escolha padrão correta. Sem dependências, sem overhead.

Mas o Axios merece o seu lugar quando as suas requisições de API no frontend crescem em complexidade. Interceptors, instâncias partilhadas, tratamento automático de erros e progresso de upload não são funcionalidades de que sentirá falta até precisar delas — e nessa altura vai querê-las integradas, e não construídas à mão. É isso que o Axios ainda lhe oferece.

FAQs

Depende da complexidade do projeto. Para um punhado de requisições simples, o Fetch é suficiente e evita uma dependência. Para aplicações com autenticação partilhada, tratamento centralizado de erros, múltiplos clientes de API ou requisitos de progresso de upload, o Axios poupa boilerplate significativo que de outra forma teria de reimplementar você mesmo.

Parcialmente. Pode envolver o fetch numa função que injete headers ou trate erros, mas perde a natureza empilhável e componível dos interceptors do Axios. Cada nova preocupação exige modificar o wrapper diretamente, e encadear múltiplos interceptors independentes torna-se complicado. A maioria das equipas que tentam isto acaba por reconstruir uma versão mais pequena e menos testada do Axios.

Não exatamente. O Axios suporta progresso de upload e download no Node.js, mas a implementação difere dos navegadores porque o Node não usa XMLHttpRequest. Os eventos de progresso nos navegadores são geralmente mais suaves e granulares, enquanto alguns cenários de upload no Node.js — especialmente uploads com FormData — têm limitações dependendo do adaptador e do runtime.

Ambas são sólidas. O ky é um pequeno wrapper baseado em Fetch que adiciona retries, hooks e timeouts mantendo-se leve. O got é rico em funcionalidades, mas apenas para Node. O Axios continua popular porque funciona tanto em ambientes de navegador como Node com uma única API, tem amplo suporte do ecossistema e é familiar à maioria dos programadores JavaScript.

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.

OpenReplay