DEV Community: Nainik Mehta

Next.js 15: Why Server Actions are Replacing API Routes

Nainik Mehta — Sat, 22 Aug 2026 07:31:07 +0000

The Shift in Full-Stack Architecture

For years, the standard workflow for full-stack developers was rigid. If you wanted to update a user's profile, you followed a predictable, boilerplate-heavy path:

Define an API route (/api/user/update).
Implement the POST handler.
Parse the request body.
Validate types on the server.
Hit the database.
On the frontend, write a fetch call or use a library like TanStack Query to manage loading states, caching, and error handling.

It felt like building two separate applications—a frontend and a backend—that just happened to communicate via HTTP.

With Next.js Server Actions, that wall is finally coming down. In Next.js 15, the "API folder" is becoming a relic of the past for internal application logic.

What are Server Actions?

A Server Action is an asynchronous function marked with the 'use server' directive. It runs exclusively on the server but is callable directly from your React components.

When you call a Server Action, Next.js handles the RPC (Remote Procedure Call) boundary for you. You don't have to worry about defining URLs, manual fetch calls, or managing JSON serialization. You simply import the function and invoke it.

The Before and After

Consider a simple profile update form.

The Old Way (REST API Route):

// app/api/user/update/route.ts
export async function POST(req: Request) {
  const body = await req.json();
  // Validate, update DB...
  return NextResponse.json({ success: true });
}

// app/profile/page.tsx
const handleUpdate = async () => {
  const res = await fetch('/api/user/update', { 
    method: 'POST', 
    body: JSON.stringify(data) 
  });
  // Handle response, error states, etc.
};

The New Way (Server Action):

// app/actions/user.ts
'use server';

export async function updateProfile(formData: FormData) {
  // Validate, update DB directly
  await db.user.update({ ... });
  revalidatePath('/profile');
}

// app/profile/page.tsx
import { updateProfile } from '@/app/actions/user';

export default function ProfileForm() {
  return <form action={updateProfile}>...</form>;
}

Why This Changes Everything

This isn't just about deleting files. It’s about a fundamental shift in the mental model of full-stack development.

1. Reduced Cognitive Load

When your data mutations are co-located with your UI, debugging becomes significantly faster. You aren't chasing a bug across three different files, two different protocols, and a middle-layer of API definitions. The logic is right where you need it.

2. Type Safety Across the Boundary

Because Server Actions are just TypeScript functions, you get end-to-end type safety for free. If you change your database schema and update your action, TypeScript will immediately flag errors in your components. No more manual sync between frontend types and backend API contracts.

3. Automatic Integration

Server Actions are built to work with Next.js caching. Using revalidatePath or revalidateTag inside an action automatically refreshes your UI data without needing manual state invalidation logic.

When Should You Still Use API Routes?

While Server Actions are a game-changer for internal application logic, they are not a silver bullet. You should still reach for traditional API Routes (or Route Handlers) when:

Public-facing APIs: If you are building an API for third-party developers, mobile apps, or external integrations, you need a stable, documented REST or GraphQL contract.
Webhooks: Services like Stripe or GitHub require a stable URL to send payloads.
Streaming/Long-running tasks: If you need to handle long-running background jobs or custom streaming responses, Route Handlers provide the fine-grained control necessary.

Conclusion

The future of full-stack development isn't about building better APIs; it's about removing the need for them entirely for your internal application logic. By treating your backend as a set of functions rather than a set of endpoints, you can ship faster, reduce bugs, and focus on the user experience.

Are you still building traditional REST endpoints for your Next.js apps, or have you fully moved to Server Actions? Let's discuss in the comments.

Are Custom Hooks Ruining Your React App Performance?

Nainik Mehta — Sat, 22 Aug 2026 03:01:12 +0000

The Hidden Cost of "Clean" Code

As React developers, we are taught to value clean, DRY (Don't Repeat Yourself) code. We see a component cluttered with 50 lines of state management and fetch logic, and our immediate instinct is to refactor it into a sleek, reusable custom hook like useDashboardFilters(). It feels like a win: the parent component shrinks to a pristine 10 lines of JSX, and the logic is neatly tucked away.

But this "clean" architecture can be a silent performance killer. While custom hooks are excellent for sharing logic, they do not isolate state. When you move state into a custom hook, you haven't hidden the performance impact—you've simply moved the source of the re-renders. If you aren't careful, your pursuit of clean code can lead to significant React custom hooks performance issues that plague your users with laggy interfaces.

How Hooks Trigger Re-renders

To understand why this happens, we must remember that custom hooks are just functions. When a component calls a custom hook, it is essentially running that hook's code as part of its own render cycle. If that hook uses useState or useReducer, any update to that state will trigger a re-render of the consuming component.

This is the core of the problem: state changes in a hook propagate to the host component.

Imagine a useDashboardFilters() hook that manages search queries, date ranges, and sorting. If you import this hook at the root of your dashboard shell, every keystroke in your search input updates the hook's state. Because that state lives "inside" the hook, the entire dashboard shell—including heavy data tables, sidebar navigation, and complex graph components—is forced to re-render on every single character typed. The input feels sluggish, and frame rates drop because the entire tree is re-evaluating.

The Anti-Pattern: Over-Abstracting State

We often fall into the trap of "lifting state up" into custom hooks prematurely. While this makes the code look cleaner, it often violates the principle of keeping state as close to the leaf nodes of your component tree as possible.

Consider this simplified example of a problematic hook:

// ❌ The performance trap: State is too high up
function useSearch() {
  const [query, setQuery] = useState('');
  return { query, setQuery };
}

function Dashboard() {
  const { query, setQuery } = useSearch(); // Re-renders the whole Dashboard on every keystroke
  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <HeavyDataTable /> 
    </div>
  );
}

In this scenario, HeavyDataTable re-renders every time the user types, even though it likely doesn't care about the intermediate keystrokes. The abstraction created an illusion of simplicity while hiding a massive performance bottleneck.

How to Optimize React Custom Hooks

Improving React state management doesn't mean abandoning custom hooks; it means changing how you structure them. Here are three strategies to keep your app performant:

1. Move State Down

The most effective fix is to keep the state local to the component that actually needs it. Instead of forcing the dashboard shell to manage the search state, move the search input into its own component.

// ✅ The fix: Isolate the state
function SearchInput() {
  const [query, setQuery] = useState('');
  return <input value={query} onChange={(e) => setQuery(e.target.value)} />;
}

function Dashboard() {
  return (
    <div>
      <SearchInput />
      <HeavyDataTable />
    </div>
  );
}

Now, typing in the search bar only re-renders the SearchInput component. The Dashboard and HeavyDataTable remain untouched.

2. Memoize Return Values

If your hook returns objects or functions, ensure they are stable. Returning a new object literal on every render will break React.memo for any child component consuming that hook.

// ✅ Stable return values
function useStableData(data) {
  return useMemo(() => ({
    data,
    formatted: data.toUpperCase()
  }), [data]);
}

3. Split Large Hooks

Don't create "God hooks" that manage unrelated pieces of state. If a hook manages both user profile data and notification settings, any update to notifications will force components only interested in the profile to re-render. Split these into useUserProfile and useNotifications to ensure components only subscribe to the state they actually consume.

Conclusion: Performance Over "Cleanliness"

Clean architecture is a goal, but runtime performance is the reality your users experience. Before you extract logic into a custom hook, ask yourself: Does this component truly need to re-render when this state changes? If the answer is no, keep the state local. Only abstract logic when you genuinely need to share it, and always be mindful of how your state placement affects the React rendering lifecycle. By keeping your state focused and your hooks surgical, you can enjoy clean code without sacrificing the responsiveness of your application.",article_title:

Building a React AI Chatbot with Vercel AI SDK v5

Nainik Mehta — Fri, 21 Aug 2026 13:02:07 +0000

Building a robust AI chatbot in React used to be a minefield of security vulnerabilities and performance bottlenecks. Many developers start by streaming raw text chunks directly from the frontend, inadvertently exposing API keys in their network tab or struggling with complex state management as they try to sync UI updates with LLM responses.

The release of Vercel AI SDK v5 changes the game. By moving away from experimental patterns and embracing a stable, transport-based architecture, the latest iteration of the Vercel AI SDK React integration provides a secure, type-safe, and highly performant way to build modern AI applications.

The Security Trap: Why Frontend Streaming Fails

The most common mistake when building a React AI chatbot is handling API calls directly in the browser. When you initialize an LLM client in your useEffect or event handlers, your secret API keys are bundled into the client-side code. Anyone inspecting your network requests can extract these credentials, leading to potential abuse and unexpected costs.

Furthermore, manual streaming implementations often rely on useState to buffer incoming chunks. As the LLM streams text, React triggers re-renders for every single chunk, leading to UI flickering and significant performance degradation—especially when dealing with complex data or tool calls.

How Vercel AI SDK v5 Solves This

Vercel AI SDK v5 introduces a redesigned useChat hook and a robust streaming architecture that shifts the heavy lifting to the server. By leveraging Server-Sent Events (SSE), the SDK ensures that your API keys remain securely on the server-side, while your frontend only receives the processed, sanitized output.

Key Architectural Improvements:

Transport-Based Architecture: The SDK now uses a modular transport system, making it easier to integrate with different backend setups while maintaining security.
Typed Tool Invocations: Tool calls are no longer generic strings. They are fully typed parts of the message stream, ensuring that your frontend knows exactly how to render them.
Decoupled State Management: The useChat hook no longer manages input state internally, giving you more control over your UI and easier integration with state management libraries like Zustand or Redux.

Implementation: A Secure Chatbot with `useChat`

To get started, you need to separate your concerns: handle the LLM interaction on the server using streamText and render the interface on the client using useChat.

Server-Side: `streamText`

Your API route (e.g., app/api/chat/route.ts) handles the LLM logic securely.

import { streamText } from 'ai';
import { openai } from '@ai-sdk/openai';

export async function POST(req: Request) {
  const { messages } = await req.json();

  const result = await streamText({
    model: openai('gpt-4o'),
    messages,
    tools: {
      // Define your tools here
      getWeather: {
        description: 'Get weather for a location',
        parameters: z.object({ location: z.string() }),
        execute: async ({ location }) => { /* ... */ },
      },
    },
  });

  return result.toDataStreamResponse();
}

Client-Side: `useChat`

In your React component, you simply call the useChat hook. The SDK handles the streaming, message history, and tool invocation automatically.

'use client';

import { useChat } from '@ai-sdk/react';

export default function Chat() {
  const { messages, input, setInput, handleSubmit } = useChat();

  return (
    <div>
      {messages.map(m => (
        <div key={m.id}>
          {m.role}: {m.content}
          {/* Render tool parts here */}
        </div>
      ))}
      <form onSubmit={handleSubmit}>
        <input value={input} onChange={e => setInput(e.target.value)} />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

Moving Beyond Text: Handling Tools

One of the most powerful features of the Vercel AI SDK is how it handles tool calls. Instead of parsing raw text to detect a function call, the SDK streams structured data parts. When the model invokes a tool, the useChat hook receives a typed tool invocation that your UI can respond to immediately.

By using the onToolCall callback and addToolOutput helper, you can create interactive experiences—like rendering a calendar component or a weather widget—directly inside your chat interface without the performance overhead of manual state synchronization.

Conclusion

If you are still manually parsing streams or exposing keys in your frontend config, you are building on shaky ground. Vercel AI SDK v5 provides the primitives you need to build professional, production-grade AI applications. By leveraging the secure streamText and useChat flow, you can focus on building delightful user experiences while the SDK handles the complexity of AI engineering.

Ready to upgrade? Dive into the official documentation and start building more secure, reactive AI interfaces today.

Next.js Server Actions vs Route Handlers: When to Use Each

Nainik Mehta — Fri, 21 Aug 2026 10:30:02 +0000

Are you still manually writing fetch('/api/user') boilerplate for every simple form in your Next.js application? If so, you are likely over-engineering your codebase.

Since the introduction of the App Router, Next.js has provided two powerful ways to handle server-side logic: Server Actions and Route Handlers. While both run on the server, they serve fundamentally different purposes. Choosing the wrong one can lead to bloated code, unnecessary complexity, and even security pitfalls.

The good news is that the decision isn't difficult if you follow one core rule.

The 1-Rule Decision Guide

When deciding between Next.js Server Actions vs Route Handlers, ask yourself this question:

"Is this request triggered by a user action inside my React UI, or is it an external system/public integration calling my application?"

If it's a UI action: Use Server Actions.
If it's an external client: Use Route Handlers.

This simple distinction keeps your code clean, type-safe, and performant by matching the tool to the intended consumer.

When to Use Server Actions

Server Actions are designed for mutations triggered directly from your React components. They act as an RPC (Remote Procedure Call) mechanism, allowing you to call server-side functions as if they were local, without needing to manually define an API endpoint or write client-side fetch calls.

Why they win for UI mutations:

Reduced Boilerplate: No need to manage useState for loading/error states, no manual fetch calls, and no manual API route serialization.
Type Safety: You get end-to-end type safety from your database to your form.
Progressive Enhancement: Forms using Server Actions can work even before JavaScript hydrates on the client.
Tight Integration: They trigger React Server Component (RSC) re-renders, allowing your UI to update immediately after a mutation.

Concrete Example: Form Submission

Instead of creating an API route, parsing the body, and managing client-side state, you simply pass a function to the action attribute:

// app/actions.ts
"use server";

import { z } from "zod";

export async function onboardUser(formData: FormData) {
  const schema = z.object({ email: z.string().email() });
  const data = schema.parse(Object.fromEntries(formData));

  // Perform database mutation
  await db.user.create({ data });

  // Revalidate the page to show new data
  revalidatePath("/dashboard");
}

// app/components/OnboardingForm.tsx
export function OnboardingForm() {
  return (
    <form action={onboardUser}>
      <input name="email" type="email" />
      <button type="submit">Submit</button>
    </form>
  );
}

When to Use Route Handlers

Route Handlers are the App Router's equivalent of traditional API routes. They provide a stable, public HTTP interface. They are not tied to your React UI lifecycle, which makes them the correct choice for anything that needs to be accessed by a non-React caller.

Use Route Handlers for:

Webhooks: Services like Stripe or GitHub need to POST to a stable, public URL.
Public APIs: If you are exposing data to mobile apps, browser extensions, or third-party developers.
Custom Responses: If you need to return non-JSON data (e.g., RSS feeds, XML, or file streams).
Cross-Origin Requests: When you need full control over CORS headers.

Concrete Example: Stripe Webhook

Because Stripe's servers are invoking your endpoint—not your React UI—a Server Action is the wrong tool. You need a stable HTTP endpoint:

// app/api/webhooks/stripe/route.ts
import { NextResponse } from "next/server";

export async function POST(req: Request) {
  const body = await req.text();
  const signature = req.headers.get("stripe-signature");

  // Verify signature and process event
  // ...

  return NextResponse.json({ received: true });
}

The Pitfalls of Over-Engineering

A common mistake is trying to use Server Actions as a public API. While they are powerful, they are not intended to be a replacement for RESTful endpoints.

URL Stability: Server Action URLs are generated by the framework and can change between deployments. Never document them for external developers.
Concurrency: Server Actions are designed for UI-driven mutations and are often executed sequentially to maintain React state consistency. If you need high-concurrency, parallel API calls, use Route Handlers.
Security: Just because a Server Action is imported in a component doesn't mean it's secure. Always validate inputs and check authentication inside the action, just as you would with a Route Handler.

Conclusion

Next.js Server Actions and Route Handlers are not competing technologies; they are complementary tools for different layers of your application.

Server Actions are for your UI. They are tightly coupled to your React components and simplify internal mutations.
Route Handlers are your API. They are for external clients, webhooks, and any integration that requires a stable HTTP contract.

By keeping this distinction clear, you avoid the "leaky abstraction" trap and ensure your codebase remains maintainable as your project scales. Stop writing manual fetch boilerplate for your forms—embrace the Server Action pattern for your UI, and reserve Route Handlers for the public-facing edges of your system.

All About Axios…🥳

Nainik Mehta — Sat, 23 Nov 2024 07:40:16 +0000

Axios is a popular JavaScript library that serves as a powerful HTTP client for making asynchronous HTTP requests in the browser and Node.js. It provides an easy-to-use interface and supports various features such as promise-based requests, interceptors for request and response handling, and the ability to cancel requests. Axios simplifies the process of sending HTTP requests and handling responses, making it a preferred choice for many developers for tasks like fetching data from APIs, interacting with servers, and managing HTTP requests and responses in web applications. Its flexibility and comprehensive functionality make it a valuable tool for building robust and efficient applications that rely on network requests.

HTTP Interceptors :
HTTP interceptors allow us to check or modify all the incoming or outgoing HTTP requests in our application. We can use them if we want to apply something like an authorization header to all the requests. Let's see how we can implement it using Axios.

Getting started with Axios

To install Axios in your project, you can use either npm (Node Package Manager) or Yarn (a package manager developed by Facebook). Both npm and Yarn allow you to manage and install JavaScript packages, including Axios. Here's how you can install Axios using npm or Yarn:

Axios Request Interceptor :

Let's see how we can use Axios to setup request interceptor that will run before a request is made.

import axios from 'axios';

/* The code `axios.interceptors.request.use((config) => { ... })` is creating an interceptor for Axios
requests. */
axios.interceptors.request.use((config) => {
  // Log to print that request is intiated..
  console.log('Request was sent');

  // Data that can be keep track of which are sent in request
  console.log(`[${config.method}] ${config.url}`);
  console.log(`Headers :`);
  console.log(config.headers);
  console.log(`Params : `);
  console.log(config.params);
  console.log(`Data : `);
  console.log(config.data);

  return config;
});

const fetchQuotes = async () => {
  try {
    const res = await axios.get(`https://type.fit/api/quotes`);
  } catch (error) {
    console.log(error);
  }
};

Setting Request Headers :

We can use request interceptors to set default HTTP headers that we want to send in every request.

Using request interceptors in Axios allows you to intercept outgoing requests before they are sent to the server. This feature is particularly useful for setting default configurations, headers, or any other properties that you want to apply to every request in your application. Here’s how you can use request interceptors to set default HTTP headers:

Response Interceptor :

Similarly, we can also setup a response interceptor with Axios that will execute whenever we receive API response.

Setting up a response interceptor with Axios allows you to intercept responses before they are handled by the then() or catch() methods. This feature is useful for globally handling errors, modifying the response data, or performing any other operations you require. Here's how you can set up a response interceptor with Axios:

// Axios response interceptor setup
axios.interceptors.response.use(
  (response) => {
    // Handle successful responses
    console.log('Response received:', response.data);
    return response;
  },
  (error) => {
    // Handle response errors
    console.error('Error encountered:', error);
    return Promise.reject(error);
  }
);

// Make a sample GET request
axios.get('https://jsonplaceholder.typicode.com/posts/1')
  .then((response) => {
    console.log('Response data:', response.data);
  })
  .catch((error) => {
    console.error('Error fetching data:', error);
  });

Also, please feel free to share your own tips in the comments. 🧐

👇 You can find and connect with me over 👇
Facebook
LinkedIn
Twitter
Github
Happy Coding and keep exploring!

DEV Community: Nainik Mehta

Next.js 15: Why Server Actions are Replacing API Routes

The Shift in Full-Stack Architecture

What are Server Actions?

The Before and After

Why This Changes Everything

1. Reduced Cognitive Load

2. Type Safety Across the Boundary

3. Automatic Integration

When Should You Still Use API Routes?

Conclusion

Are Custom Hooks Ruining Your React App Performance?

The Hidden Cost of "Clean" Code

How Hooks Trigger Re-renders

The Anti-Pattern: Over-Abstracting State

How to Optimize React Custom Hooks

1. Move State Down

2. Memoize Return Values

3. Split Large Hooks

Conclusion: Performance Over "Cleanliness"

Building a React AI Chatbot with Vercel AI SDK v5

The Security Trap: Why Frontend Streaming Fails

How Vercel AI SDK v5 Solves This

Key Architectural Improvements:

Implementation: A Secure Chatbot with useChat

Server-Side: streamText

Client-Side: useChat

Moving Beyond Text: Handling Tools

Conclusion

Next.js Server Actions vs Route Handlers: When to Use Each

The 1-Rule Decision Guide

When to Use Server Actions

Why they win for UI mutations:

Concrete Example: Form Submission

When to Use Route Handlers

Use Route Handlers for:

Concrete Example: Stripe Webhook

The Pitfalls of Over-Engineering

Conclusion

All About Axios…🥳

Implementation: A Secure Chatbot with `useChat`

Server-Side: `streamText`

Client-Side: `useChat`