home / skills / hoangnguyen0403 / agent-skills-standard / data-fetching

data-fetching skill

This skill helps you implement Next.js data fetching best practices across app router components, enabling efficient caching, revalidation, and parallel data

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill data-fetching

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.4 KB

---
name: Next.js Data Fetching
description: Fetch API, Caching, and Revalidation strategies.
metadata:
  labels: [nextjs, data-fetching, caching]
  triggers:
    files: ['**/*.tsx', '**/service.ts']
    keywords: [fetch, revalidate, no-store, force-cache]
---

# Data Fetching (App Router)

## **Priority: P0 (CRITICAL)**

Fetch data directly in Server Components using `async/await`.

## Strategies

- **Static**: Build-time. `fetch(url, { cache: 'force-cache' })`.
- **Dynamic**: Request-time. `fetch(url, { cache: 'no-store' })` or `cookies()`.
- **Revalidated**: `fetch(url, { next: { revalidate: 60 } })`.

## Patterns

- **Direct Access**: Call DB/Service layer directly. **Do not fetch your own /api routes.**
- **Colocation**: Fetch exactly where data is needed.
- **Parallel**: Use `Promise.all()` to prevent waterfalls.
- **Client-Side**: Use SWR/React Query for live/per-user data (no SEO).

## Revalidation

- **Path**: `revalidatePath('/path')` - Purge cache for a route.
- **Tag**: `revalidateTag('key')` - Purge by tag.

## Anti-Patterns

- **No Root Awaits**: Avoid blocking the entire page. Use `<Suspense>`.
- **No useEffect**: Avoid manual fetching in client effects.
- **Internal API**: Never call `/api/...` from Server Components.

## Examples & References

- [Usage Examples](references/usage-examples.md)
- [Caching Documentation](https://nextjs.org/docs/app/building-your-application/caching)

Overview

This skill documents Next.js App Router data fetching, caching, and revalidation strategies for building fast, consistent React apps. It focuses on Server Component patterns, caching options, and best practices to avoid common anti-patterns. Use it to choose the correct fetching mode and revalidation mechanism for SEO, performance, and real-time needs.

How this skill works

The skill explains how to fetch data directly in Server Components using async/await and how to configure caching via fetch options (static, dynamic, revalidated). It covers colocating fetch logic near UI, running parallel requests with Promise.all, and when to delegate live or per-user data to client libraries like SWR or React Query. It also details revalidation APIs (revalidatePath, revalidateTag) and which internal calls to avoid.

When to use it

Server-rendered pages requiring SEO or build-time data use static caching (force-cache).
Request-time or per-request data (auth-sensitive or frequently changing) use no-store or cookies.
Partial staleness where periodic freshness is acceptable use next.revalidate with a TTL.
Client-side libraries (SWR/React Query) for live updates or user-specific interactive experiences.
Colocate fetches in components that consume the data to reduce complexity and coupling.

Best practices

Always fetch directly in Server Components with async/await; do not call your own /api routes from the server.
Choose cache: 'force-cache' for build-time static, 'no-store' for fully dynamic, and { next: { revalidate: seconds } } for ISR-style revalidation.
Avoid root-level awaits that block full page render; use <Suspense> to progressively render. Use Promise.all to parallelize independent requests and prevent waterfalls.
Use revalidatePath and revalidateTag to selectively purge caches instead of broad invalidation. Prefer tag-based invalidation for granular updates.
Push live, per-user, or optimistic updates to client libraries; avoid manual useEffect-based server fetching for primary data.

Example use cases

Static marketing pages: fetch CMS content at build time with cache: 'force-cache' for fast, SEO-friendly delivery.
User dashboard: fetch per-request stats with cache: 'no-store' or use client-side SWR for live updates and optimistic UI.
Product pages with periodic updates: fetch server-side with next: { revalidate: 60 } to serve cached pages and refresh every minute.
Background updates and admin edits: call revalidatePath('/product/123') or revalidateTag('product-123') after a mutation to purge relevant cache entries.
Microservices/DB access: call service or DB layer directly from Server Components; avoid routing through internal /api endpoints.

FAQ

Can I call my internal /api routes from a Server Component?

No. Server Components should call the service or database layer directly. Calling your own /api routes adds unnecessary HTTP overhead and can defeat caching benefits.

When should I use revalidateTag versus revalidatePath?

Use revalidateTag for granular, content-oriented invalidation across pages that share data. Use revalidatePath when you need to purge a specific route’s cached output.