This cheatsheet outlines 29 common mistakes, explaining why they're problematic and how to fix them with practical, best-practice solutions. Use this as a checklist before your next PR, during code reviews, or as you build your Next.js application to ensure you're leveraging the framework effectively.

1. Marking the Root Page as a Client Component

• Problem: Adding "use client" at the top of a root page component forces the entire component tree to render on the client, negating all performance benefits of Server Components. Often done unnecessarily due to misunderstanding architecture.
• Solution: Only mark the individual, interactive leaf nodes (child components) that truly require client-side interactivity as client components. Keep parent pages and layouts as Server Components where possible.

2. Not Protecting Server Actions

• Problem: Server Actions are public HTTP endpoints. If unprotected, anyone can trigger them, potentially leading to unauthorized data manipulation or security vulnerabilities.
• Solution: Always implement robust protection for Server Actions: verify user authentication, perform thorough input validation and standardization, and check user access rights before executing any sensitive logic.

3. Placing Server Component get Calls Inside a Server Actions File

• Problem: Any function exported from a file containing "use server" becomes a public HTTP endpoint. Placing data fetching (get) functions here unnecessarily exposes them and potentially sensitive data.
• Solution: Separate data fetching logic (functions that don't perform mutations) into a dedicated file (e.g., lib/data.ts or lib/cart-server.ts). Only functions intended for mutations should reside in "use server" files.

4. Shipping AI-Generated Code to Production Without Review

• Problem: While AI tools accelerate development, their code isn't always perfect. Shipping unreviewed AI code can introduce bugs, missing edge cases, or inconsistent variable naming.
• Solution: Use AI for speed, but always perform thorough code reviews. Leverage AI-powered code review tools (like Graphite) to catch potential issues before deployment.

5. Using Route Handlers Instead of Server Components for GET Requests

• Problem: Creating separate API routes (/api/...) for simple GET requests that could be handled directly by Server Components. This adds unnecessary boilerplate, separate API management, and often forces the use of client components for state management.
• Solution: For simple GET requests, fetch data directly within an async Server Component. This reduces code, eliminates separate API routes, and keeps logic closer to where it's used. Use Suspense for loading states instead of useState.

6. Placing a Suspense Boundary at the Wrong Level

• Problem: Placing a <Suspense> boundary directly around the async function call itself will not trigger the loader. It can also lead to errors if cache components are enabled and uncached data is accessed outside Suspense.
• Solution: Place the <Suspense> boundary one level below the async data fetching logic, wrapping the component that consumes the fetched data. This ensures the loader displays correctly while the data is being prepared.