DEV Community: Scott Hu

Downstream started rate-limiting your Node BFF? Here's the retry layer that fixes it.

Scott Hu — Sun, 09 Aug 2026 14:13:06 +0000

Your Node BFF proxies to a downstream API — a payment provider, a recommendations service, a partner's data feed. One Tuesday the partner starts returning 429 and the occasional 503. Suddenly your users see errors, and the partner's status page lists you as their top traffic source. Something has to change on your side.

Here's the outbound call most BFFs start with:

import express from 'express';
import axios from 'axios';

const app = express();
const downstream = axios.create({ baseURL: 'https://api.partner.com' });

app.get('/recommendations/:userId', async (req, res) => {
  try {
    const { data } = await downstream.get(`/recs/${req.params.userId}`);
    res.json(data);
  } catch (e) {
    res.status(502).json({ error: 'bad gateway' });
  }
});

It does the happy path. It does nothing for the bad one. A transient 503 from the partner becomes a hard error for your user. And nothing stops a misbehaving client from calling this endpoint in a loop — which means you loop against the partner, exactly when they're struggling.

The usual fix, and where it breaks

Most of us reach for the obvious patch: a retry helper, and a manual counter for rate limiting.

async function withRetry(fn, n = 3) {
  for (let i = 0; i < n; i++) {
    try { return await fn(); }
    catch (e) { if (i === n - 1) throw e; await sleep(1000); }
  }
}

const hits = new Map(); // ip -> count, reset by... a timer? manually?

This compiles. It also has three holes you only find in production:

Retry storm. Ten concurrent requests each retry three times → thirty calls to a partner that's already down. You turned a blip into an outage.
No jitter. Every client retries after the same one second, so they all fire together, a thundering herd on recovery.
Per-process counters. That Map lives in one process. Behind a cluster or multiple instances, each worker counts on its own, so your "limit" is really limit × instances, and it resets wrong on restart.

You can fix all three by hand. People do, with varying success. The interesting part is that these are solved problems if the retry and the limit live with the request definition instead of bolted on after it.

alova/server: retry and rate limiting as request wrappers

alova isn't only a browser library. alova/server ships two server hooks — retry and createRateLimiter — that wrap a method and run when you send it. They use whatever alova instance you've set up, and on the server that instance uses the axios adapter just like on the client.

import { createAlova } from 'alova';
import { axiosRequestAdapter } from '@alova/adapter-axios';
import { retry, createRateLimiter } from 'alova/server';

const alova = createAlova({
  requestAdapter: axiosRequestAdapter()
  // server-side method use doesn't need a statesHook
});

const getRecs = userId =>
  alova.Get(`https://api.partner.com/recs/${userId}`);

Retry with backoff and jitter

retry wraps the method. Defaults are three attempts, one second apart; you can grow the delay and add jitter so a fleet of BFF instances doesn't retry in lockstep.

const data = await retry(getRecs(req.params.userId), {
  retry: 5,
  backoff: {
    delay: 1000,
    multiplier: 2,
    startQuiver: 0.1,
    endQuiver: 0.3
  }
});

First retry at ~1s, next at ~2s, next at ~4s, each with 10–30% random jitter. The downstream gets breathing room instead of a wall of retries.

Rate limiting inbound, so you don't hammer the partner

createRateLimiter wraps a method and tracks usage by a key — an IP, a user id, a tenant. Hit the limit and it throws (it does not queue), so you return 429 and stop there.

const rateLimit = createRateLimiter({
  duration: 1000,
  points: 5,
  keyPrefix: 'recs'
});

// before proxying, check the caller's budget
try {
  await rateLimit(alova.Get('/recommendations'), { key: req.ip });
} catch {
  return res.status(429).json({ error: 'too many requests' });
}

keyPrefix namespaces the counter so it won't collide with other limiters. duration and points set the window — here, five requests per second per IP.

Putting it in a middleware

Combine the two around the outbound call. Rate-limit the inbound caller first; if they're under budget, make the outbound call with retry.

app.get('/recommendations/:userId', async (req, res) => {
  try {
    await rateLimit(alova.Get('/recommendations'), { key: req.ip });
  } catch {
    return res.status(429).json({ error: 'too many requests' });
  }

  try {
    const data = await retry(getRecs(req.params.userId), {
      retry: 5,
      backoff: { delay: 1000, multiplier: 2 }
    });
    res.json(data);
  } catch {
    res.status(502).json({ error: 'partner unavailable' });
  }
});

The retry only runs on the outbound partner call, so a rate-limited caller is rejected before any retry logic kicks in — you're not retrying your own 429s.

For multi-instance deployments, point the limiter at a shared store so the count is consistent across workers:

import { createPSCAdapter, NodeSyncAdapter } from '@alova/psc';

const rateLimit = createRateLimiter({
  duration: 1000,
  points: 5,
  store: createPSCAdapter(NodeSyncAdapter())
});

createRateLimiter is built on node-rate-limiter-flexible, so cluster, multi-thread, and redis-backed stores are all supported through the storage adapter.

Canonical source: alova server rate limiting — https://alova.js.org/tutorial/server/strategy/rate-limit

Related reading

Server retry — https://alova.js.org/tutorial/server/strategy/retry
Storage adapters (psc / redis) — https://alova.js.org/resource/storage-adapter/psc

alova is on GitHub (alovajs/alova) and npm (alova). Full docs at https://alova.js.org.

You've kept that axios instance for years — do you really need to rewrite it?

Scott Hu — Sun, 09 Aug 2026 14:08:29 +0000

You have an axios setup that works. Interceptors handle auth, a baseURL is set once, error handling lives in one place. Nobody wants to rewrite all of that to try a new library.

Good news: you don't have to. alova can drive your existing axios instance — interceptors, baseURL, timeout, the lot — and add pagination, caching, retries, and request sharing on top. axios still sends the request. alova decides how the request runs.

The setup you already have

Here's a typical list view in React with plain axios. It works, until you look at everything it doesn't do.

import axios from 'axios';
import { useState, useEffect } from 'react';

const api = axios.create({ baseURL: '/api' });

export function UserList() {
  const [page, setPage] = useState(1);
  const [data, setData] = useState([]);
  const [total, setTotal] = useState(0);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    api.get('/users', { params: { page, pageSize: 10 } })
      .then(res => {
        if (cancelled) return;
        setData(res.data.data);
        setTotal(res.data.total);
      })
      .catch(e => { if (!cancelled) setError(e); })
      .finally(() => { if (!cancelled) setLoading(false); });
    return () => { cancelled = true; };
  }, [page]);

  // Where's the caching? The dedupe of a re-clicked page?
  // A retry when the network blips? None of it exists yet.
}

Three problems show up the moment this ships:

Every mount refetches, even for data that hasn't changed.
Click page 3, then quickly page 2 — the slower response can land last and show the wrong page.
A transient 500 means the user gets a hard error instead of a second try.

You could patch each one by hand. People do. But the patches are the same in every project, and they're easy to get subtly wrong.

What you actually want

Strip it down and the wish list is small:

Keep the axios instance and its interceptors exactly as they are.
Get loading/error/data state without writing it per component.
Paginate without hand-rolling page state and race handling.
Cache GETs so re-mounts don't refetch.
Share one in-flight request across components that ask for the same thing.
Retry the few requests that really matter.

alova covers all six, and it uses axios to actually send the bytes. Here's the whole wiring change:

import axios from 'axios';
import { createAlova } from 'alova';
import { axiosRequestAdapter } from '@alova/adapter-axios';
import ReactHook from 'alova/react';
import { usePagination } from 'alova/client';

// untouched — your interceptors and baseURL stay
const api = axios.create({ baseURL: '/api' });

const alovaInst = createAlova({
  statesHook: ReactHook,
  requestAdapter: axiosRequestAdapter({ axios: api })
});

const getUsers = (page, pageSize) =>
  alovaInst.Get('/users', { params: { page, pageSize } });

That's the migration. One instance, created once. Nothing about your axios config moves.

The same list, managed for you

export function UserList() {
  const {
    loading,
    error,
    data,
    page,
    pageSize,
    total,
    pageCount,
    isLastPage
  } = usePagination(getUsers, {
    initialPage: 1,
    initialPageSize: 10,
    initialData: { total: 0, data: [] }
  });

  if (loading) return <p>Loading…</p>;
  if (error) return <p>Could not load users.</p>;

  return (
    <div>
      {data.map(u => <Row key={u.id} user={u} />)}
      <button disabled={page <= 1} onClick={() => page.value--}>Prev</button>
      <button disabled={isLastPage} onClick={() => page.value++}>Next</button>
      <p>{page} / {pageCount} · {total} users</p>
    </div>
  );
}

usePagination owns page state, drops stale responses when you switch pages fast, and knows when the list ends (isLastPage) so you stop requesting empty pages. Your axios interceptors still run on every one of these requests — alova's beforeRequest fires before axios's request interceptors, and responded fires after axios's response interceptors, so ordering is predictable.

For a single request, useRequest is the same idea with less surface:

const { loading, data, error } = useRequest(alovaInst.Get('/me'));

The parts you didn't write

Four things are now handled that your hand-rolled version skipped:

Caching. GET responses are cached in memory for five minutes by default. Re-mount the component, hit the same URL — no second network call. Want a different window? cacheFor: 60 * 1000 on the method. Need it to survive a refresh? Switch the mode to restore and it lands in localStorage too, with tag-based invalidation when your data shape changes.

Request sharing. Two components asking for /me at the same time send one request, not two. It's on by default. (FormData bodies are the one exception — uploads are treated as intentional, so they never share.) Opt out per request with shareRequest: false.

Retries for the requests that matter. Most GETs shouldn't retry blindly, but a payment-status poll or a one-shot action can use one:

import { useRetriableRequest } from 'alova/client';

const { loading, data, error, send } = useRetriableRequest(
  alovaInst.Get('/order/status', { params: { id } }),
  { retry: 3, backoff: { delay: 2000, multiplier: 2 } }
);

It defaults to three retries, one second apart, and you can make the delay grow exponentially or add jitter so a fleet of clients doesn't retry in lockstep.

What this costs you

Honesty over hype: this isn't free.

You add two packages: alova and @alova/adapter-axios.
Your team learns a Method abstraction (alovaInst.Get(...)) and the hook model. It's a small mental shift, but it's real.
You pick a statesHook per framework (React, Vue, Svelte). It's one line, but it's a line you didn't have before.
Interceptor order changes in a way that matters if your interceptors assume a specific sequence relative to alova's hooks. Read it once and you're fine, but don't assume it's identical to plain axios.

The upside is that migration is gradual. You wrap the instance, move one endpoint to alovaInst.Get, and leave the rest on api.get until you get to them. axios and alova run side by side during the switch.

Canonical source: the alova migration guide — https://alova.js.org/tutorial/project/migration/from-axios

Related reading

axios adapter — https://alova.js.org/resource/request-adapter/axios
usePagination — https://alova.js.org/tutorial/client/strategy/use-pagination
useRetriableRequest — https://alova.js.org/tutorial/client/strategy/use-retriable-request
Caching modes — https://alova.js.org/tutorial/cache/mode

alova is on GitHub (alovajs/alova) and npm (alova). Full docs at https://alova.js.org.

The evolution of fetch libraries: from Promise to strategies

Scott Hu — Sat, 06 Jun 2026 01:28:26 +0000

Introduction

Frontend data fetching has gone through several paradigm shifts: from XMLHttpRequest callbacks, to Promise chains with fetch and axios, to declarative hooks with React Query and SWR. Each step traded more abstraction for less boilerplate.

A less-discussed but noteworthy direction is the move toward strategy-based request handling — where libraries don't just offer data-fetching hooks, but purpose-built hooks for specific business patterns: pagination, form submission, polling, file uploads, and more. Instead of telling the computer "how" to fetch data step by step, you declare "what" you need.

This article examines this evolution using alova as a reference implementation, analyzing when strategy-based approaches deliver value — and when simpler alternatives still make sense.

The Boilerplate Problem

Take paginated lists, one of the most common patterns in frontend development. Here's what a typical Promise-based implementation looks like with axios:

// Traditional Promise (axios) approach
import { useState, useEffect, useCallback } from 'react';
import axios from 'axios';

function TodoList() {
  const [list, setList] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [page, setPage] = useState(1);
  const pageSize = 10;
  const [total, setTotal] = useState(0);

  const fetchList = useCallback(async () => {
    setLoading(true);
    setError(null);
    try {
      const res = await axios.get('/api/todos', {
        params: { page, pageSize }
      });
      setList(res.data.list);
      setTotal(res.data.total);
    } catch (e) {
      setError(e.message);
    } finally {
      setLoading(false);
    }
  }, [page]);

  useEffect(() => { fetchList(); }, [fetchList]);

  return (
    <div>
      {loading && <Spinner />}
      {error && <ErrorMsg message={error} />}
      {list.map(item => <Item key={item.id} {...item} />)}
      <Pagination
        current={page}
        total={total}
        pageSize={pageSize}
        onChange={p => setPage(p)}
      />
    </div>
  );
}

This code works, but it has recurring problems:

Boilerplate state management: loading, error, and data appear in nearly every data-fetching component
Indirect dependency wiring: the useCallback dependency array + useEffect pattern adds cognitive overhead — the intent ("refetch when page changes") is buried under three layers of indirection
Scattered refresh logic: triggering a refresh from outside the component (e.g., after creating a new item) requires lifting state or using refs
Leaky pagination state: page, pageSize, and total are exposed and manually tracked

The Strategy-Based Approach

Promise-based code is imperative: you tell the computer how to do everything. Strategy-based code is declarative: you describe what you want, and the library handles execution.

alova implements this pattern with a set of scenario-specific hooks:

Strategy Hook	Use Case
`usePagination`	Paginated lists / infinite scroll
`useForm`	Form submission (drafts, multi-step forms)
`useAutoRequest`	Polling / focus refresh / reconnect refresh
`useCaptcha`	Verification code + countdown
`useUploader`	File uploads (progress, concurrency control)
`useRetriableRequest`	Exponential backoff retry

Before / After: Three Common Scenarios

Scenario 1: Paginated Lists

// alova usePagination
import { usePagination } from 'alova/client';

function TodoList() {
  const {
    data,
    loading,
    error,
    page,
    pageSize,
    total,
    send
  } = usePagination(
    (page, pageSize) => alovaInstance.Get('/api/todos', {
      params: { page, pageSize }
    })
  );

  // All states managed by the hook
  return (
    <div>
      {loading && <Spinner />}
      {error && <ErrorMsg message={error.message} />}
      {data.map(item => <Item key={item.id} {...item} />)}
      <Pagination
        current={page}
        total={total}
        pageSize={pageSize}
        onChange={p => send(p)}
      />
    </div>
  );
}

Compared to the Promise version:

Five state variables collapsed into one hook call
No useCallback + useEffect dependency wiring
send(p) is semantically clearer than setPage(p)
Built-in page tracking, preloading, and cache invalidation

Scenario 2: Form Submission

// Traditional Promise approach
function LoginForm() {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setLoading(true);
    setError(null);
    try {
      await axios.post('/api/login', formData);
      router.push('/dashboard');
    } catch (e) {
      setError(e.message);
    } finally {
      setLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      {error && <Alert type="error">{error}</Alert>}
      <button disabled={loading}>Login</button>
    </form>
  );
}

// alova useForm
function LoginForm() {
  const { loading, error, send } = useForm(
    (formData) => alovaInstance.Post('/api/login', formData),
    { resetAfterSubmitting: true }
  );

  return (
    <form onSubmit={e => send(e)}>
      {error && <Alert type="error">{error.message}</Alert>}
      <button disabled={loading}>Login</button>
    </form>
  );
}

useForm encapsulates the loading/error management and try-catch-finally boilerplate. Additional capabilities like draft persistence and multi-step form state sharing are available through configuration — no extra code required.

Scenario 3: Polling

// Traditional: useEffect + setInterval
useEffect(() => {
  const fetchStatus = async () => {
    const { data } = await axios.get('/api/status');
    setStatus(data);
  };
  fetchStatus();
  const timer = setInterval(fetchStatus, 3000);
  return () => clearInterval(timer);
}, []);

// alova useAutoRequest
useAutoRequest(
  () => alovaInstance.Get('/api/status'),
  {
    pollingInterval: 3000,
    enablePolling: true
  }
);

Beyond polling, useAutoRequest bakes in automatic refresh on tab focus and reconnection — features that would require separate visibilitychange and network event listeners with plain Promise code.

Three Technical Characteristics

1. Separation of Concerns

Strategy hooks decouple request execution logic from UI components. usePagination handles pagination state, data aggregation, and cache policies internally — the component only worries about rendering. This separation makes unit testing simpler: test component rendering and data logic independently.

2. Framework Agnostic

alova uses a StatesHook adapter layer to support React, Vue, Svelte, and other frameworks. The same usePagination / useForm API works consistently across frameworks, reducing cognitive overhead in multi-stack teams.

3. Composability

Strategies can be composed. For example, usePagination data can trigger refreshes from other components via actionDelegationMiddleware, and useForm can preload the next page's data with useFetcher after a successful submission.

Trade-Off Analysis

Every abstraction has a cost. Here's when strategy-based approaches help — and when they don't.

When It Works Well

Standard CRUD pages: list, form, and detail views with predictable patterns — strategy hooks cover most needs out of the box
Medium to large projects: many pages, complex request patterns, and frequent team collaboration — a unified strategy API promotes consistency and reduces review overhead
Multi-platform projects: applications targeting web, mini-programs, and mobile simultaneously — the framework-agnostic strategy layer reduces adaptation work
Projects needing caching: scenarios involving L1 (memory) + L2 (persistent) caching, auto-invalidation, and request deduplication — the built-in cache management reduces opportunities for manual errors

When to Think Twice

Trivially simple pages: a standalone page with a single GET request — the abstraction overhead exceeds the benefit; plain fetch or axios is lighter
Highly custom request flows: when your request pattern diverges significantly from built-in strategies, a custom implementation may be more straightforward (alova supports custom strategy hooks, but they require additional development)
Projects with established solutions: if your project already integrates deeply with React Query or TanStack Query and runs stably, a full migration has low ROI; introducing strategy hooks incrementally in new modules is more practical
Low-level HTTP scenarios: WebSocket connection management, streaming uploads, Server-Sent Events — these may require mixing low-level APIs with strategy hooks
Team unfamiliarity: the strategy paradigm requires team buy-in and understanding; teams accustomed to traditional Promise patterns face a learning curve

Conclusion

The shift from Promise to strategies represents a paradigm transition from imperative to declarative data fetching. It doesn't replace Promises — it adds a semantic abstraction layer above them for common patterns.

This trajectory mirrors the evolution in state management (Redux → Recoil / Zustand): it's not about which one is "better," but which abstraction level fits your context.

For most business applications, declaring intent in a few lines of code instead of writing boilerplate state management has concrete value. But in simple contexts, the same abstraction can add unnecessary complexity. The right choice depends on project scale, team experience, and specific requirements.

usePagination: 3 lines of code, infinite possibilities

Scott Hu — Fri, 05 Jun 2026 11:05:28 +0000

Paginated lists are one of the most common patterns in frontend development. A hand-written implementation — with state management for page, pageSize, total, loading, error, and handlers for pagination, search debounce, and item mutations — easily reaches 50+ lines. alova's usePagination hook collapses this into roughly 3 lines of configuration. This article examines how the abstraction works and where it fits.

The Hand-Written Baseline

Here's a standard paginated list written with Vue 3 and Axios:

const list = ref([]);
const loading = ref(false);
const error = ref(null);
const page = ref(1);
const pageSize = ref(10);
const total = ref(0);
const searchKeyword = ref('');

const fetchList = async () => {
  loading.value = true;
  error.value = null;
  try {
    const res = await axios.get('/api/users', {
      params: {
        page: page.value,
        pageSize: pageSize.value,
        keyword: searchKeyword.value,
      },
    });
    list.value = res.data.data;
    total.value = res.data.total;
  } catch (e) {
    error.value = e.message;
  } finally {
    loading.value = false;
  }
};

const changePage = (p) => { page.value = p; fetchList(); };
const changePageSize = (ps) => { pageSize.value = ps; page.value = 1; fetchList(); };
const onSearch = (keyword) => { searchKeyword.value = keyword; page.value = 1; fetchList(); };
const deleteItem = async (id) => { await axios.delete(`/api/users/${id}`); fetchList(); };

onMounted(() => fetchList());

The actual business logic — GET /api/users — is one line. The remaining 50+ lines are infrastructure: state wiring, loading toggles, pagination coordination, and filter resets. This pattern repeats in every list page across the project.

usePagination: Configuration Over Boilerplate

usePagination internalizes all of that infrastructure:

import { usePagination } from 'alova/client';

const searchKeyword = ref('');

const {
  loading, data, error,
  page, pageSize, total, pageCount, isLastPage,
  fetching, removing, replacing, status,
  refresh, insert, remove, replace, reload,
  onSuccess, onError, onComplete,
} = usePagination(
  (page, pageSize) => alovaInstance.Get('/api/users', {
    params: { page, pageSize, keyword: searchKeyword.value },
  }),
  {
    initialPage: 1,
    initialPageSize: 10,
    watchingStates: [searchKeyword],
    debounce: 300,
  }
);

Three lines of configuration replace 50+ lines of imperative code. Here's what you get:

1. Automatic pagination

Modifying page.value or pageSize.value triggers a request automatically. Changing pageSize resets to page 1 — no manual wiring needed.

page.value = 3;       // fetch page 3 automatically
pageSize.value = 20;  // reset to page 1 and fetch automatically

2. Debounced search with filter watching

Add reactive states to watchingStates with an optional debounce, and the list re-fetches whenever any filter changes:

searchKeyword.value = 'John';  // auto-fetch from page 1 after 300ms debounce

3. Optimistic list mutations

insert, remove, and replace update the local list and sync with the server — no manual refetch needed:

await insert({ id: 99, name: 'New User' }, 0);       // prepend
await remove(2);                                         // delete 3rd item
await replace({ id: 5, name: 'Updated' }, 4);          // replace 5th item
await refresh(page.value);                               // force-refresh current page
await reload();                                          // clear and reload from page 1

4. Adjacent-page preloading

Next and previous pages preload in the background by default. When the user clicks "next page," data is already in cache — no loading spinner.

5. Granular operation states

Beyond a single loading boolean, usePagination exposes per-operation states:

loading,    // current page is loading
fetching,   // preloading in background (doesn't block the UI)
removing,   // array of row indices currently being removed
replacing,  // index of the row being replaced
status,     // current operation: "loading" | "removing" | "inserting" | "replacing"

This enables row-level loading indicators during delete operations while keeping the rest of the list interactive.

The Core Abstraction

The code reduction comes from elevating the abstraction level:

Manual approach: You handle each HTTP request individually, managing all state transitions by hand
usePagination approach: The entire "paginated list" scenario is a single configurable unit, with common logic (loading toggles, error handling, pagination coordination) baked into the hook

When usePagination Is a Good Fit

Standard CRUD admin panels: User lists, order tables, content management — pages with pagination, search, and inline CRUD
Multi-filter + pagination combos: Several filter dimensions that must reset pagination on change
Frequent list item mutations: Inline edit, delete, insert operations where optimistic updates eliminate refetch overhead
Standard API response shapes: { data: [], total: number } or structures configurable via data/total callbacks

When to Look Elsewhere

Cursor-based pagination: APIs using after/before cursors don't map cleanly to the page-number model
Bidirectional infinite scroll: UIs that load in both directions (e.g., chat histories) exceed the hook's design scope
Multi-list coordination: One operation must update several paginated lists with strict ordering requirements
Multi-endpoint data aggregation: List data assembled from multiple APIs that can't be mapped through data/total callbacks

Comparison at a Glance

Dimension	Manual	usePagination
Code volume	50-60 lines	~3 lines config
Pagination logic	Manual page + fetch	Auto-response to state changes
Search debounce	Hand-rolled	`watchingStates` + `debounce`
List mutations	Refetch after each operation	Optimistic `insert`/`remove`/`replace`
Preloading	Build from scratch	Built-in, enabled by default
Loading granularity	Single boolean	Multi-level: loading/fetching/removing/replacing
Customization ceiling	Fully flexible	Constrained by hook design
Learning curve	Framework fundamentals	Understanding hook config and behavior

Summary

usePagination doesn't do anything you couldn't write yourself. Its value is packaging a battle-tested pagination implementation so you don't write — and debug — the same 50 lines for every list page. For standard pagination use cases, the reduction in boilerplate and the built-in preloading and optimistic updates are measurable improvements. For scenarios outside its design scope, a custom implementation remains the clearer choice.

Why TanStack Query is overrated (and what to use instead)

Scott Hu — Fri, 05 Jun 2026 01:20:00 +0000

⚠️ 【待 review】

Why TanStack Query is overrated (and what to use instead)

I've been a TanStack Query user for two years. I wrote about it, recommended it to my team, and genuinely thought it was the final form of frontend data fetching.

Then I built a real product — a full-blown admin dashboard with forms, paginated lists, file uploads, polling, and cross-component communication.

That's when I realized: TanStack Query gives you a glorified fetcher and leaves all the complexity to you.

It's not that TanStack Query is bad. It's excellent at what it does: query caching, request deduplication, and background refetching. But in real-world application development, "fetching data" is only a fraction of what you actually need.

Here are 5 scenarios where I found alova drastically out-performs TanStack Query.

1. Form Submission

TanStack Query

const { mutateAsync } = useMutation({
  mutationFn: (data) => axios.post('/api/form', data),
})

const { register, handleSubmit, reset, watch } = useForm({
  defaultValues: loadFromDraft()
})

useEffect(() => {
  saveDraft(watch())
}, [watch()])

const onSubmit = async (data) => {
  await mutateAsync(data)
  reset()
  clearDraft()
}

You need React Hook Form (or Formik), manual draft persistence, manual reset after submit — easily 30+ lines for what should be a one-liner.

alova

const {
  loading, submit, form, reset
} = useForm(
  (formData) => alova.Post('/api/form', formData),
  {
    store: true,                // auto draft persistence
    resetAfterSubmiting: true,  // auto reset after submit
  }
)

3 lines. Draft persistence survives page refresh. Multi-step form state is shared automatically. No useEffect, no localStorage calls.

The philosophy difference: TanStack Query gives you a primitive and says "figure it out." alova gives you a complete form abstraction and says "just use it."

2. Pagination / Infinite Scroll

TanStack Query

const [page, setPage] = useState(1)

const { data, isPreviousData } = useQuery({
  queryKey: ['list', page],
  queryFn: () => fetch(`/api/list?page=${page}`),
  keepPreviousData: true,
})

// Manual prefetch
const queryClient = useQueryClient()

const prefetchNext = () => {
  queryClient.prefetchQuery(['list', page + 1], ...)
}

useEffect(() => {
  if (data?.length < pageSize) return
  prefetchNext()
}, [page, data])

This is just page management. Once you add edit-then-refresh or delete-then-remove, the boilerplate doubles.

alova

const {
  data, loading, page, pageSize,
  handlePrevPage, handleNextPage, reload
} = usePagination(
  (page, pageSize) => alova.Get('/api/list', {
    params: { page, pageSize }
  }),
  {
    preloadNextPage: true,   // auto prefetch next page
    total: res => res.total,
  }
)

usePagination manages the entire pagination lifecycle — page state, prefetching, list mutation — in one hook. Deleting an item? It's automatically removed from the list. Editing one? Automatically updated.

3. Smart Polling + Focus Refetch

TanStack Query

const { data } = useQuery({
  queryKey: ['notification'],
  queryFn: () => fetch('/api/notification'),
  refetchInterval: 5000,
  refetchOnWindowFocus: true,
})

Looks fine until you need dynamic control:

const [enabled, setEnabled] = useState(false)

const { data } = useQuery({
  queryKey: ['notification'],
  queryFn: () => fetch('/api/notification'),
  refetchInterval: enabled ? 5000 : false,
  refetchOnWindowFocus: enabled,
})

alova

const { loading, data, stop, resume } = useAutoRequest(
  () => alova.Get('/api/notification'),
  {
    enablePoll: true,
    pollInterval: 5000,
    enableThrottle: true,      // stop when tab is hidden
    enableVisibility: true,    // resume when tab regains focus
  }
)

// Full control
stop()   // pause
resume() // restart

Polling, focus refetch, throttling, and visibility control — all in one hook. Call stop() and resume() whenever you need.

4. Cross-Component Communication

TanStack Query

// Component A
const mutation = useMutation({
  mutationFn: (data) => axios.post('/api/item', data),
  onSuccess: () => {
    queryClient.invalidateQueries({ queryKey: ['list'] })
  },
})

As your app grows, invalidateQueries calls scatter across your codebase. Tracking queryKey dependencies becomes a manual mental exercise.

alova

// Declarative cache invalidation
const updateTodo = (id, data) =>
  alova.Put(`/api/todo/${id}`, data, {
    hitSource: 'todoList',  // auto-invalidate todoList cache
  })

Anyone reading the code immediately sees: "updating a todo → refreshes the list." No need to hunt down mutation callbacks.

For more complex scenarios, actionDelegationMiddleware lets you call another component's request method from anywhere — no prop drilling, no global store:

// In Component A:
const { send } = useRequest(updateTodo, {
  middleware: actionDelegationMiddleware('updateTodo')
})

// In Component B (anywhere in the tree):
accessAction('updateTodo', ({ send }) => { send() })

5. File Upload

TanStack Query — No native support

You'd write your own upload logic with FormData, progress events, concurrency control, and pause/resume. Every. Single. Time.

alova

const {
  upload, loading, progress
} = useUploader(
  ({ file }) => alova.Post('/api/upload', { file }),
  { limit: 3 }  // max 3 concurrent uploads
)

// Pause / resume
controller.pause()
controller.resume()

6 lines. Progress tracking, concurrency control, pause/resume — all built in.

The Bottom Line

Scenario	TanStack Query	alova
Basic GET + cache	✅ Works well	✅ Works well
Form + draft + reset	❌ DIY ~200 lines	✅ useForm: 3 lines
Pagination + prefetch	❌ DIY	✅ usePagination
Smart polling + throttle	❌ DIY	✅ useAutoRequest
Cross-component communication	⚠️ invalidateQueries	✅ hitSource / actionDelegation
File upload + concurrency	❌ Not supported	✅ useUploader
Bundle size	~13KB gzipped	~4KB gzipped

TanStack Query is an excellent library. For simple data fetching and caching, it's a solid choice.

But if your application deals with forms, paginated lists, file uploads, or any of the "messy real-world" request scenarios, alova's strategy hooks will save you hundreds of lines of code and countless hours of debugging.

Give it a try — you might be surprised how simple data fetching can be.

📦 alova v3 is now live | GitHub | Docs

From Axios to alova: how we cut 80 lines to 5

Scott Hu — Mon, 01 Jun 2026 03:35:01 +0000

Frontend request code often involves repetitive state management. This article compares Axios and alova through a paginated list example, analyzing how request strategization reduces boilerplate and when it's a good fit.

The Pattern: Paginated List in Two Ways

A common requirement: fetch a user list with pagination.

Approach 1: Axios

const [data, setData] = useState([]);
const [page, setPage] = useState(1);
const [total, setTotal] = useState(0);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

const fetchUsers = async (currentPage) => {
  setLoading(true);
  setError(null);
  try {
    const res = await axios.get('/api/users', {
      params: { page: currentPage, pageSize: 10 },
    });
    setData(res.data.list);
    setTotal(res.data.total);
  } catch (e) {
    setError(e.message);
  } finally {
    setLoading(false);
  }
};

useEffect(() => { fetchUsers(page); }, [page]);

This pattern appears in nearly every data-fetching component. The actual business logic — GET /api/users — occupies a single line. The rest is infrastructure: state declarations, loading toggles, error handling, and effect management.

Approach 2: alova with usePagination

const {
  data, total, loading, error,
  page, pageSize, nextPage, prevPage,
} = usePagination(
  (page, pageSize) => alovaInstance.Get('/api/users', {
    params: { page, pageSize },
  }),
  { page: 1, pageSize: 10 }
);

Both implementations are functionally identical. The key difference is where the state management logic lives: in the component (Axios) vs. inside the hook (alova).

What Changed

Component of Axios version	Handled by alova
`loading` state + toggling	Managed internally by usePagination
`error` state + try/catch	Managed internally by usePagination
`data` state + assignment	Returned as reactive value
`page` state + change handler	Built-in `nextPage` / `prevPage`
`total` state extraction	Extracted from response automatically
useEffect dependency tracking	Managed internally

The removed code shares one characteristic: it's infrastructure for the request pattern, not business logic. alova encapsulates this infrastructure into scenario-specific hooks.

Beyond Pagination

alova provides hooks for common request patterns:

useRequest — basic fetch

// Auto-fetch on mount
const { data, loading, error } = useRequest(getUserList());

// Manual trigger
const { send } = useRequest(createOrder, { immediate: false });

useWatcher — reactive fetch with debounce

const { data } = useWatcher(
  () => searchApi(keyword.value),
  [keyword],
  { debounce: 300 }
);

useForm — form submission

const { form, loading, send: submit, reset } = useForm(
  submitApi,
  { initialForm: { name: '', email: '' } }
);

All hooks share a consistent return interface (data, loading, error) while adding scenario-specific capabilities.

Code reduction across six common scenarios:

Scenario	Axios (core lines)	alova (core lines)	Reduction
Paginated list	~30	6	~80%
Search with debounce	~25	3	~88%
Form submission	~30	3	~90%
Polling / auto-refresh	~25	3	~88%
Chained requests	~30	5	~83%
File upload	~35	8	~77%

Line counts reflect core logic only, excluding UI rendering and imports.

When to Use (And When Not To)

Good fit for:

Medium-to-large projects with many data-fetching pages
Teams wanting consistent request patterns across codebase
New projects where the abstraction can be established early

Less suitable for:

Small projects where the abstraction overhead outweighs the benefit
Teams already deeply invested in React Query or SWR — evaluate migration cost carefully
Non-standard request patterns that don't map well to existing hooks
Framework ecosystems outside of React/Vue/Svelte support

Other considerations:

Learning curve: Understanding the strategy hook paradigm takes initial investment
Debugging: The abstraction layer can add indirection when troubleshooting unexpected behavior
Ecosystem: alova's community and third-party integrations are smaller than Axios'
Migration path: The Method API mirrors Axios, enabling incremental adoption

// Nearly identical API
axios.get('/api/users', { params: { page: 1 } });
alovaInstance.Get('/api/users', { params: { page: 1 } });

Summary

Moving from Axios to alova is not about "switching HTTP libraries." It's about treating requests as composable scenarios rather than one-shot operations you wire up manually. Whether this abstraction is valuable depends on your project's specific needs — the code reduction is real, but so are the trade-offs.

Stop writing useEffect for data fetching. Use Request Strategies instead.

Scott Hu — Sat, 30 May 2026 12:16:45 +0000

⚠️ 【Draft – Pending Review】

Stop writing useEffect for data fetching. Use Request Strategies instead.

I've been a React developer for about three years. And for most of that time, I wrote data fetching the same way everyone else did:

useEffect(() => {
  fetch('/api/users')
    .then(res => res.json())
    .then(setData)
    .catch(setError)
    .finally(() => setLoading(false));
}, []);

It works. But it's not good.

Every list page. Every search box. Every filter. Same pattern. And the code kept growing — loading states, error handling, debounce timers, race condition flags. A simple user list with search would easily hit 80 lines of boilerplate.

Then I found alova, and I realized: I'd been fighting problems that didn't need to exist.

The Before: useEffect Hell

Here's what my code used to look like:

// 🔴 Before: 80 lines of manual state management
import { useState, useEffect, useCallback } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [keyword, setKeyword] = useState('');
  const [page, setPage] = useState(1);

  const fetchUsers = useCallback(async () => {
    setLoading(true);
    setError(null);
    try {
      const res = await fetch(`/api/users?keyword=${keyword}&page=${page}&pageSize=10`);
      const data = await res.json();
      setUsers(data.list);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  }, [keyword, page]);

  useEffect(() => { fetchUsers(); }, [fetchUsers]);

  // Manual debounce
  useEffect(() => {
    const t = setTimeout(() => fetchUsers(), 500);
    return () => clearTimeout(t);
  }, [keyword]);

  // Manual race condition handling
  useEffect(() => {
    let cancelled = false;
    fetch(`/api/users?keyword=${keyword}&page=${page}`)
      .then(res => res.json())
      .then(data => { if (!cancelled) setUsers(data.list); });
    return () => { cancelled = true; };
  }, [keyword, page]);

  if (loading) return <Spinner />;
  if (error) return <Error msg={error} />;

  return (
    <div>
      <SearchInput value={keyword} onChange={setKeyword} />
      <UserList data={users} />
    </div>
  );
}

This code has several issues:

Too many manual states — loading, error, data all declared by hand
DIY debounce — setTimeout/clearTimeout everywhere, easy to mess up
Race conditions — the classic cancelled flag pattern, error-prone
Dependency chains — useCallback + useEffect, changing one prop means tracing the whole chain

I wrote this pattern dozens of times. Every new project, same boilerplate.

The After: Request Strategies with alova

Then I switched to alova, and the same component became this:

// 🟢 After: 15 lines with alova request strategies
import { useRequest, useWatcher } from 'alova/client';
import { alovaInstance } from './api';

function UserList() {
  const [keyword, setKeyword] = useState('');

  // List data — auto-managed loading/data/error
  const { loading, data: users = [], error } = useRequest(
    () => alovaInstance.Get('/api/users', {
      params: { page: 1, pageSize: 10 }
    }),
    { initialData: [] }
  );

  // Search — debounce + race condition handling built in
  const { data: searchResult = [] } = useWatcher(
    () => alovaInstance.Get('/api/users', {
      params: { keyword, page: 1, pageSize: 10 }
    }),
    [keyword],
    { debounce: 500 }
  );

  if (loading) return <Spinner />;
  if (error) return <Error msg={error.message} />;

  return (
    <div>
      <SearchInput value={keyword} onChange={setKeyword} />
      <UserList data={users} />
    </div>
  );
}

This isn't magic. It's design.

alova transforms data fetching from imperative to declarative. Instead of telling the computer how to fetch, you tell it what to fetch — and the library handles the rest.

What you used to write by hand	What alova does for you
3x `useState` for loading/data/error	`useRequest` returns them automatically
`useEffect` + `useCallback` chains	Declarative watchers with auto dependency management
`setTimeout` / `clearTimeout` for debounce	`debounce: 500` — one line
`cancelled` flag for race conditions	Built-in abort on next request
Manual URL parameter construction	`params` object, auto-serialized

What Are "Request Strategies"?

alova isn't a simple fetch wrapper. It's a strategy-based request library that covers the most common data-fetching patterns in frontend development:

Strategy Hook	You tell it	It handles
`useRequest`	What to fetch	loading, data, error, send, abort
`useWatcher`	What state to watch	debounce, auto-refetch, race conditions
`usePagination`	Page config	Page state, preloading, optimistic updates
`useForm`	Form data	Draft persistence, auto-submit, reset
`useAutoRequest`	Polling config	Auto-polling, focus refresh, reconnect
`useCaptcha`	Phone number	Countdown timer, auto-send
`useSerialRequest`	Dependent calls	Pass previous result to next request
`useRetriableRequest`	Retry config	Exponential backoff with jitter

Each hook maps to a pattern you've probably implemented dozens of times. The goal isn't to write less code — it's to not write it at all.

The Results

After switching to alova across my projects, here's what I've seen:

60% less boilerplate — pages went from ~150 lines to ~60 lines
Fewer bugs — no more "forgot to clearTimeout" or "wrong cancelled flag"
Faster onboarding — new devs learn "use this hook for this pattern" instead of debugging useEffect chains
Better code review — request logic is declarative and self-documenting

Getting Started

npm install alova

Then pick an adapter:

npm install @alova/fetch     # For browsers / Node.js
npm install alova/axios       # If you're on axios

And write your first strategic request:

import { createAlova } from 'alova';
import fetchAdapter from '@alova/fetch';
import ReactHook from 'alova/react';

export const alovaInstance = createAlova({
  baseURL: 'https://api.example.com',
  statesHook: ReactHook,
  requestAdapter: fetchAdapter(),
  responded: res => res.json()
});

// In your component:
function Profile() {
  const { loading, data, error } = useRequest(
    () => alovaInstance.Get('/user/profile'),
    { initialData: {} }
  );
  // ...
}

Stop writing useEffect for data fetching. Your time is better spent on actual product logic.

Give alova a try. The docs are at alova.js.org, the source is on GitHub, and the community is welcoming.

Using alova v3. Tested in React, Vue, and Svelte.

Hello Dev.to - Test Post

Scott Hu — Sat, 30 May 2026 07:11:57 +0000

Hello Dev.to

This is a test post to verify the API publishing flow works.

Nothing fancy, just making sure everything is wired up correctly.

Thanks for stopping by!

文章标题23

Scott Hu — Sat, 30 May 2026 05:59:25 +0000

文章内容 markdown

文章标题

Scott Hu — Sat, 30 May 2026 05:57:54 +0000

文章内容（markdown）

I replaced TanStack Query with alova and cut my code by 70%

Scott Hu — Fri, 29 May 2026 08:41:33 +0000

I replaced TanStack Query with alova and cut my code by 70%

A frontend engineer's real-world migration story — 5 scenarios, 133 lines reduced to 10 (92.5% reduction)

Six months ago I took over a mid-office project with a wishlist the size of a CVS receipt: paginated lists, multi-step forms, real-time SSE notifications, file uploads, autocomplete search…

Naturally, I reached for TanStack Query (formerly React Query). It's the de facto standard for React data fetching, right?

But as the project grew, something felt off. To handle different request patterns, I kept wrapping TanStack Query with more and more custom logic:

Pagination? Write useInfiniteQuery + manually manage page state + flatten pages with flatMap.
Forms? useMutation handles submission only — form state, draft saving, reset, all DIY.
SSE? TanStack Query doesn't support it. I pulled in @microsoft/fetch-event-source.
Server-side retry? TanStack Query is client-only.

By the end, I counted 2,000+ lines of request-related code.

Then a colleague dropped a link: alova.

First shock: Pagination went from 50 lines to 3

Before: TanStack Query

import { useInfiniteQuery } from '@tanstack/react-query'

const PAGE_SIZE = 10

function TodoList() {
  const {
    data, fetchNextPage, hasNextPage,
    isFetchingNextPage, isLoading, isError, error,
  } = useInfiniteQuery({
    queryKey: ['todos'],
    queryFn: async ({ pageParam = 1 }) => {
      const res = await fetch(`/api/todos?page=${pageParam}&pageSize=${PAGE_SIZE}`)
      return res.json()
    },
    getNextPageParam: (lastPage, allPages) => {
      return lastPage.hasMore ? allPages.length + 1 : undefined
    },
  })

  if (isLoading) return <Loading />
  if (isError) return <Error message={error.message} />

  const todos = data?.pages.flatMap(page => page.items) ?? []

  return (
    <div>
      {todos.map(todo => <TodoItem key={todo.id} todo={todo} />)}
      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? 'Loading...' : 'Load more'}
        </button>
      )}
    </div>
  )
}

After: alova `usePagination`

import { usePagination } from 'alova/client'

function TodoList() {
  const {
    loading, data, page,
    pageSize, total,
    nextPage, prevPage,
  } = usePagination(
    (page) => alova.Get('/api/todos', { params: { page, pageSize: 10 } }),
    { total: res => res.total }
  )

  if (loading) return <Loading />

  return (
    <div>
      {data.map(todo => <TodoItem key={todo.id} todo={todo} />)}
      <Pagination
        page={page} total={total}
        onNext={nextPage} onPrev={prevPage}
      />
    </div>
  )
}

3 lines of core logic. page, pageSize, total, navigation, loading state — all built in. No useInfiniteQuery, no manual page state, no flatMap.

5 scenarios, side by side

1. Form submission + draft persistence

TanStack Query: You get useMutation for submission. Everything else — form state, localStorage draft, sync logic — is on you.

const mutation = useMutation({
  mutationFn: (data) => api.submitForm(data),
})
const [formData, setFormData] = useState({})
const [draft, setDraft] = useState(() => {
  return JSON.parse(localStorage.getItem('formDraft') || '{}')
})
useEffect(() => {
  localStorage.setItem('formDraft', JSON.stringify(formData))
}, [formData])
const handleSubmit = () => mutation.mutate(formData)

alova: One store: true flag = automatic draft persistence.

const {
  form, loading, sendForm,
  updateForm, reset,
} = useForm((formData) => alova.Post('/api/submit', formData), {
  initialForm: {},
  store: true,  // auto-draft to localStorage
})
const handleSubmit = () => sendForm()

2. Real-time SSE notifications

TanStack Query doesn't support SSE out of the box. You need a third-party library plus manual connection/reconnection logic.

alova has built-in useSSE:

const { data, readyState } = useSSE(
  alova.Get('/api/notifications', { /* SSE config */ })
)

readyState automatically reflects connection status (CONNECTING/OPEN/CLOSED). data is a reactive stream.

3. Auto-polling + focus refetch + throttling

Both libraries support polling and focus refetch. But alova's throttle parameter controls the minimum interval for both polling and focus refetch — no frantic re-fetching when the user keeps tab-switching.

useAutoRequest(alova.Get('/api/todos'), {
  throttle: 3000,    // 3s throttle
  enablePoll: true,  // polling on
  enableFocus: true, // focus refetch on
})

4. Server-side retry + rate limiting

TanStack Query is client-only. Its retry option only works in the browser.

alova's retry and RateLimiter work in Node.js, Bun, and Deno — and RateLimiter even supports Redis for distributed rate limiting across processes.

import { retry, RateLimiter } from 'alova/server'

// Server-side retry with exponential backoff
const result = await retry(
  alovaInstance.Post('/api/order', orderData),
  { retry: 3, backoff: { start: 1000, multiplier: 2 } }
).send()

// Distributed rate limiting
const limiter = new RateLimiter({
  points: 10,     // 10 requests
  duration: 1,    // per second
})
const result = await limiter.limit(
  alovaInstance.Get('/api/external')
).send()

This is a category of functionality TanStack Query simply cannot provide.

5. Cross-framework consistency

TanStack Query has different APIs per framework (@tanstack/react-query, @tanstack/vue-query, @tanstack/svelte-query).

alova uses the same API everywhere:

// React
const { data } = useRequest(alova.Get('/api/todos'))
// Vue — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Svelte — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Mini-programs (UniApp/Taro) — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Node.js backend — just await
const data = await alova.Get('/api/todos')

Different imports, identical API. One mental model for every environment.

By the numbers

Scenario	TanStack Query	alova	Reduction
Paginated list	~50 LOC	3 LOC	94%
Form + draft	~35 LOC	3 LOC	91%
SSE notifications	~30 LOC (3rd party)	1 LOC	97%
Auto-polling	~10 LOC	2 LOC	80%
Retry (server)	~8 LOC	1 LOC	87%
Total (5 scenarios)	~133 LOC	~10 LOC	92.5%

This isn't to say TanStack Query is bad — it's excellent at what it does (caching + state management). But its philosophy is "here are the tools, you build the solution."

alova takes a different approach: 20+ built-in request strategies for real-world scenarios. Pagination, forms, SSE, polling, retry, rate limiting — they're all ready to use, not ready to build.

When to choose what?

Simple CRUD + caching: TanStack Query is fine. No issues.
Complex mid-office / BFF projects: Multiple request patterns → alova's strategy-based approach saves significant time.
Cross-framework / cross-platform projects: alova's framework-agnostic design is a clear advantage.
Server-side request control: Retry, rate limiting, distributed locking → alova is the only choice.

⭐ GitHub: alovajs/alova

🌐 Site: alova.js.org

What do you think is the next evolution of request libraries? Drop a comment below.

30 months of open source: How I maintain the Next-Gen request tool

Scott Hu — Tue, 03 Sep 2024 09:13:46 +0000

Two years ago, I designed and developed a JavaScript request strategy library called alovajs. Since its promotion in April 2023, it has received acclaim from developers around the world and has garnered over 2700+ stars, including recognition from experts at major companies.

Currently, alova@3.x has been released, positioned as "the next-generation request tool for streamlined workflows."

I have been maintaining it without compensation for 30 months, and the version has reached 3.x. During this period, through continuous reflection, rejection, and rethinking, I aimed to achieve something that other request tools have not done, to become a tool that can truly help front-end development. I believe I have found a reliable direction.

That is, to create a "next-generation request tool for streamlined workflows", maximizing the assistance to front-end development in streamlining the API integration process.

Below is the exploration story of alovajs, which is also the story of an open-source project from its inception.

If you are interested in alovajs, I sincerely invite you to join the community and make progress together.

Join the Discord community

alovajs Originated from a Small Project, but Its Mission is to Sail the Ocean

One day in March 2022, due to certain circumstances, I conceived the idea of developing an App called "Con of goal." Inspired by some apps, I hoped that "Con of goal" could achieve delay-free data requests and submissions, that is, an immediate response mode, even under weak or no network conditions. However, after searching online and not finding a suitable solution, and similar optimistic update solutions not meeting the needs, my damn desire to share led me to decide to implement it in the form of a request library, which was the starting point of alovajs, but it didn't have a name at that time.

Designing alovajs

The beginning of a library is not design, not development, but clarifying the needs

pro Tips: It is strongly recommended that you first briefly understand the overview section of alovajs to better understand the following content.

At that time, there was no product positioning, just creating a JavaScript library to meet my own needs. I studied existing request libraries and listed the following needs:

Support for seamless data interaction mode, that is, under network disconnection, it can still be submitted without delay, without the user's perception
Designed according to the popular useHook of the time, making the interface more user-friendly
A set of code supports multiple frameworks such as Vue, React, etc., and JavaScript operating environments such as browsers, React Native, UniApp, and Taro, etc.
Consistent usage in multiple JavaScript environments
Considering the caching function of react-query is very good, this should also be added
Due to the influence and simplicity of axios, make alovajs easy to get started with, and the design should be similar to axios

Then, based on the needs, the library's API was designed.

For needs 1, it was the starting point for me to do alovajs, but it was not simple. The design at the time was to add a silent parameter in the useHook configuration, which could immediately respond to the success callback, but it was later proven to be problematic and redesigned, which is now the seamless data interaction strategy

For needs 2, three core useHooks were designed: useRequest, useWatcher, and useFetcher. This is very familiar to everyone, such as ahooks' useRequest, vueuse's useAsyncState, react-query, and swr, needless to say, it is indeed very convenient.
Since the useHook design is used, different frameworks will have different state management, but I don't want to create a JavaScript library for each framework like react-query. Therefore, for needs 3, the specifications for stateHook adapters, request adapters, and storage adapters were designed, and different adapters can be written according to the specifications, separating the framework environment and runtime environment-related logic into separate modules.
For needs 4, the method instance proxy pattern was designed, and the method instance proxy calls the hook functions of different adapters, so that even if you develop any application, you can get started with alovajs without any unfamiliarity, and it can also be seamlessly transplanted.
For needs 5, similar JavaScript libraries implement caching in the form of custom keys, but my idea is to focus on request information. The common scenario is that when requesting the same interface with the same request method and parameters, it is necessary to hit the response data of the last time. Why don't we use these request information as caching keys? Therefore, alovajs has designed an automatic caching mechanism, which is enabled by default on GET requests.
For needs 6, refer to and learn from axios.

These designs have indeed been proven over time. alovajs has perfectly compatible with Vue, React, Svelte frameworks through the adapter method, and can also run in various JavaScript environments such as browsers, React Native, UniApp, and Taro, while maintaining a consistent usage method, which has given me a glimmer of hope.

In the following months, although alovajs was released, it has not been promoted. On the one hand, it is because I used it in the "Con of goal" project. Although it has been tempered and improved in this project, it is still very incomplete, and the positioning is not clear. The initial version introduction is like this.

Later, the "Con of goal" project was aborted, but alovajs is still persisting.

alovajs' Direction Exploration

With the obsession of once being an Internet product manager, I still hope to make alovajs a differentiated product. I often ask myself, what is the difference between alovajs and other request libraries? Why should users use alovajs? It is indeed different from other libraries in design, which is not a question that can be answered immediately. Later, I tried to position the direction of the request library as a "lightweight request library" and a "multi-end unified request library", but they were all denied by myself, because these cannot bring substantial help to developers, and they cannot be called advantages.

In September 2022, an opportunity made me discover the excellent request library based on Vue, vue-request. Its usePagination and useLoadMore immediately inspired me. This form of pagination implementation made me realize that this is also what I want. At the same time, it made me realize the power of useHook. I can divide the module according to the request scenario, use different useHooks for different scenarios, and the previously implemented seamless data interaction is actually one of the scenarios. If this is the direction, developers can choose different useHooks according to different request scenarios, which not only improves development efficiency and reduces coding complexity, but also prevents junior front-end from writing inefficient code, and can make better use of the core features of alovajs to achieve better performance and less server pressure. request features, so far, the "lightweight request strategy library" was chosen by me.

Then, in order to guide the future design direction of alovajs, I also refined and abstracted the request scenario model (RSM) of alovajs, mainly divided into the following four processes:

Request timing -> Request behavior -> Request event -> Response processing

Let's do it, I started to reconstruct alovajs 2.0 according to this positioning, separated the seamless data interaction function from 1.0, and designed a middleware mechanism to adapt to the development of more request scenario strategy useHooks, studied and developed the pagination strategy and seamless data interaction strategy.

The pagination strategy of alovajs is what I think is the most useful usePagination. It uses the caching function of alovajs to achieve pre-loading of front and back page data, pagination data search, request-level debouncing, and provides automated management of new editing and deletion functions, as well as refreshing the data of a specified page code without resetting.
The seamless data interaction strategy took me 4 months, constantly encountering dead ends, and constantly redesigning the result. It has achieved a strategy that allows users to interact with data without delay even in weak or disconnected network environments, and it can also more stably ensure the success of the request. I designed a virtual data thing, which can be used as a placeholder for response data before the response, making users feel that it is an immediate response, and then replace the virtual data with real data after the response is successful. According to the current exploration results, its usage scenarios can be editor-like applications, system setting modules, and some simpler lists.

Later, request strategy modules such as useForm, useAutoRequest, and useSSE were also added, but this is far from enough.

The idea of the Next-Generation Request Tool

On May 13, 2023, I received such an issue on github

At first, I didn't pay much attention to this issue, just simply understood the function of automatically generating request code for openAPI, and thought it was very good, but due to limited energy, I didn't think deeply about it, and I hadn't been thinking about the direction of alovajs at that time. But recently, I would occasionally think about the direction of alovajs, and this issue that is still open has always come to my mind, and then quietly changed the label of this issue from "feature-request" to "feature-request:confirmed".

At the same time, this issue made me realize that alovajs can also narrow the collaboration distance between front-end and back-end, and further simplify the front-end development workflow. This is the development direction I set for alovajs 3.0:

alovajs will help developers simplify the API integration workflow to the greatest extent, you only need to specify which API to use (this is also the result of thinking for 3 months)

My specific plan is as follows:

The steps 1, 2, 3, 4, 6 in the above figure are solved by automatically generating API code, but our generation plan will go further compared to tools like openapi-generator. It will automatically generate complete ts type, complete description request functions, whether it is a js project or a ts project, there is no need to introduce, let developers call as convenient as directly calling location.reload, and the request function can directly see the complete description and request parameter type prompts.
Since the automatically generated request functions have complete descriptions and type prompts, the vscode plugin completes the interactive way to quickly retrieve the required APIs, and you no longer need to refer to the API documentation.
Solve the problem of the front-end and back-end collaboration gap, and any changes in the interface can be automatically notified to the front-end. If there are changes found during the project construction, an error will be thrown to stop the construction. If it is a ts project, an error will also be thrown during compilation, and the change records can also be viewed through the vscode plugin.

Here is the demo video of vscode extension.

How to solve step 6 "write complex request logic"? Of course, it is to use the request strategy module, which has the characteristics of high performance and scene-based, and users can use a very small amount of code to implement various scene request functions.

In March 2024, the development plan for alova@3.0 was formulated, and it took 4 months to restructure almost the entire project with core member MeetinaXD, and there are many optimizations:

The underlying architecture was redesigned, and a set of hooks can be used simultaneously in Vue, React, Svelte, and even in the Vue options style.
The available range has been increased to the server side. You can use alova in server-side frameworks such as express, koa, and nestjs, and new server-side request strategy server hooks have been added.
10 configurations in alova@2.x were deprecated, and 9 designs were optimized.

In addition, the most important part of 3.0, the vscode plugin, which is in charge of our core member czlin, is also available, and it has basically achieved the goals we set at the beginning.

So far, alova@3.0 has passed the beta period and can be stably used in the production environment.

Only by continuous exploration can we become better

At that time, an article that was criticized, It's time to replace your axios made it to the hot search.

It was indeed not that good when it was just launched, but I know that every product is not achieved overnight, and it needs time to precipitate.

The Apple 1 computer didn't even have a case at the beginning

The development journey of Vue is also a process of continuous exploration and progress

I am just moved by such a product journey, and persisting in doing one thing is the easiest way to succeed. Good products need to be tested for several years, let alone alovajs, which has only been around for about 1.5 years, and has only been contacted by some people for 8 months. During this period, it has also been exploring better solutions and moving forward step by step.

alovajs initially designed useHooks including useRequest, useWatcher, useEffectWatcher, useManual, useController, and then gradually reduced to only three core hooks: useRequest, useWatcher, and useFetcher.

Commit address

In the design of parallel requests, whether to implement a form similar to Promise.all, or the current form of binding to the onSuccess function, I have been entangled in several versions, changed back and forth, and the following is the design of the abandoned responder of that year.

Commit record not found

In order to be compatible with asynchronous caching schemes such as IndexedDB, I initially tried to design the storage adapter as an asynchronous function, but it would bring a series of problems, and then tried to implement the event mechanism through StorageConnector, which is still not perfect enough, and finally to the current custom localCache asynchronous function mechanism.

Commit address

I also thank friends who have supported and contributed to alovajs. The following are a few screenshots, and there are many contributions that are not included.

And continuously supplement the details of the document and improve the best practices, boldly try the cache version plan for the cache recovery mode, and in order to provide complete ts type prompts for alovajs, try to use automatic type inference to reduce the trouble of developers defining types, and indeed spend a lot of effort to optimize and compatible with different UI frameworks, etc.

Among them, the document has been greatly changed two to three times. I am grateful to @Orange Peel for providing the first document modification opinion, and @Well for providing the second document modification opinion, and then our document has such a reputation.

@green tree helped me open up new ideas for alova.

Many things are no longer clear, and the records on npmjs tell me that 146 versions have been released.

There are also many people on github who have raised bugs, and I have also responded and fixed them in the first time. I am really very grateful. If I can't judge the problem immediately, I will also reproduce it on codesandbox, and use this demo as a bridge for communication with users.

The END

Thank you very much for your reading🤗, no matter how difficult it is, the road still needs to continue.

If you recognize alovajs, please go to Github to give it a star.

If you want to understand alova, you can visit the official website, where you can find more detailed documentation and example code to help you better understand and use this tool.

If you have any questions, you can join the following group chats for consultation, or you can also post Discussions in the github repository. If you encounter problems, please submit them in github issues, and we will solve them in the fastest time.

Join the Discord community

We also welcome you to contribute your strength, please go to the Contribution Guide.

DEV Community: Scott Hu

Downstream started rate-limiting your Node BFF? Here's the retry layer that fixes it.

The usual fix, and where it breaks

alova/server: retry and rate limiting as request wrappers

Retry with backoff and jitter

Rate limiting inbound, so you don't hammer the partner

Putting it in a middleware

You've kept that axios instance for years — do you really need to rewrite it?

The setup you already have

What you actually want

The same list, managed for you

The parts you didn't write

What this costs you

The evolution of fetch libraries: from Promise to strategies

Introduction

The Boilerplate Problem

The Strategy-Based Approach

Before / After: Three Common Scenarios

Scenario 1: Paginated Lists

Scenario 2: Form Submission

Scenario 3: Polling

Three Technical Characteristics

Trade-Off Analysis

When It Works Well

When to Think Twice

Conclusion

usePagination: 3 lines of code, infinite possibilities

The Hand-Written Baseline

usePagination: Configuration Over Boilerplate

1. Automatic pagination

2. Debounced search with filter watching

3. Optimistic list mutations

4. Adjacent-page preloading

5. Granular operation states

The Core Abstraction

When usePagination Is a Good Fit

When to Look Elsewhere

Comparison at a Glance

Summary

Why TanStack Query is overrated (and what to use instead)

Why TanStack Query is overrated (and what to use instead)

1. Form Submission

TanStack Query

alova

2. Pagination / Infinite Scroll

TanStack Query

alova

3. Smart Polling + Focus Refetch

TanStack Query

alova

4. Cross-Component Communication

TanStack Query

alova

5. File Upload

TanStack Query — No native support

alova

The Bottom Line

From Axios to alova: how we cut 80 lines to 5

The Pattern: Paginated List in Two Ways

What Changed

Beyond Pagination

When to Use (And When Not To)

Summary

Stop writing useEffect for data fetching. Use Request Strategies instead.

Stop writing useEffect for data fetching. Use Request Strategies instead.

The Before: useEffect Hell

The After: Request Strategies with alova

What Are "Request Strategies"?

The Results

Getting Started

Hello Dev.to - Test Post

Hello Dev.to

文章标题23

文章标题

I replaced TanStack Query with alova and cut my code by 70%

I replaced TanStack Query with alova and cut my code by 70%

First shock: Pagination went from 50 lines to 3

Before: TanStack Query

After: alova usePagination

5 scenarios, side by side

After: alova `usePagination`