DEV Community: Sachintha

Should you proxy through Server Actions or call APIs directly?

Sachintha — Fri, 13 Nov 2026 05:00:00 +0000

You've got a Next.js app, and it needs to talk to a backend that isn't Next.js, maybe a Python service, a Rails app, or plain Express. The first architectural decision you'll make, often without realizing it's a decision at all, is where that connection actually lives.

Some teams route every request through a Server Action and let Next.js sit in the middle. Others skip that step and have the browser call the backend directly. Both are common, both work, and picking wrong doesn't blow up right away. It just shows up later as latency nobody budgeted for, or a security gap nobody planned for.

This post walks through how each pattern works, then digs into the real trade-offs around performance, scaling, and security, so you can pick deliberately instead of by habit. It's written for developers who've built a Next.js app or two. You don't need to have used Server Actions before, the next section explains what they are.

There are two places the connection can live

The connection to your backend either runs through the Next.js server or skips it. A Server Action is an async function marked with 'use server' that runs on the Next.js server, but that a client component can call like a normal function. That makes it a natural middleman.

Pattern A: Server Actions as a proxy. The Next.js app becomes a middleman. Client components call Server Actions, which forward requests to the backend. This is the Backend-for-Frontend (BFF) approach.
Pattern B: direct client-side calls. The browser talks straight to the backend, the same way client-side rendering has always worked.

Here's how a request travels in each.

A proxy adds a hop, a direct call skips it

The proxy pattern sends every request through the Next.js server on its way to the backend, while a direct call goes straight from the browser.

Server Actions as a proxy

A user action in the app triggers a Server Action
The Server Action runs on the Next.js server and calls the backend API
The backend responds to the Next.js server
The Server Action processes that response and sends it to the client

The path: client, Next.js server, backend API, Next.js server, client.

Under the hood, each Server Action becomes a POST endpoint on the page that uses it, identified by an action ID Next.js generates. Called from the client, it always goes over POST, regardless of what the action actually does.

Direct client-side calls

A client component needs data
Your JavaScript calls the backend directly with fetch or Axios
The backend responds straight to the browser

The Next.js server serves the initial JavaScript bundle, then steps out of the way. Every request after that happens in the browser.

Each pattern wins on different things

Neither approach is better across the board. What matters is what you're optimizing for.

When Server Actions make sense

Secrets stay hidden. API keys and service tokens live on the server and never reach the browser.

Auth lives in one place. Every request can be validated against the user's session before it reaches the backend, instead of trusting each client call independently.

Client code stays simple. Components call functions instead of managing fetch calls, error states, and loading states by hand.

Cache invalidation is built in. After a mutation, calling revalidatePath or updateTag updates the UI in the same response. No manual cache bookkeeping.

When direct calls make more sense

Your backend already does the work. If the API already handles OAuth, JWTs, rate limiting, and CORS, a proxy layer adds a hop without adding much value.

Latency is the priority. Direct calls skip the extra round trip through the Next.js server, which matters for real-time features.

You want a thin frontend. If Next.js should just serve pages, direct calls keep it out of the request path entirely.

Developer experience, side by side

What you care about	Server Action proxy	Direct client calls
Client-side code	Function calls	Manual fetch setup
Type safety	Typed at the call site, manual past the backend boundary	Manual type definitions
Boilerplate	Minimal, hooks manage state	useState + useEffect
Cache invalidation	Built in with revalidatePath	Custom solution

That type safety row needs a caveat. "End-to-end, automatic" is the pitch when the whole stack is TypeScript, tRPC being the clearest example. The moment your backend is Python, Rails, or anything else, the automation stops at the Next.js boundary. The Server Action's own inputs and outputs are typed, but whatever the backend actually sends back still needs validating by hand, with something like Zod, unless you're maintaining matching types on both sides yourself.

Server Actions cost a hop and run one at a time

Server Actions add a network hop. There's no getting around that.

On serverless platforms like Vercel, that hop can push latency into the hundreds of milliseconds to low seconds, worse with cold starts. Direct calls go point to point, so they're faster by default.

That number is more a serverless characteristic than a Server Actions one. Run Next.js as a long-lived process next to your backend, same region, nothing scaling to zero, and the extra hop can cost single-digit milliseconds instead. If your own latency numbers look like the Vercel figures above, check what's actually adding the delay before blaming the pattern itself.

Here's a quick test. Fire three Server Actions from the client with Promise.all, each taking about a second on the server. How long until all three finish? Most people guess one second. It's closer to three.

Server Actions run one at a time. Trigger several at once and they queue up while the UI waits. The React docs say frameworks typically process one action at a time, and Next.js does. Direct calls with Promise.all really do run concurrently.

Don't use Server Actions for fetching data. Use Server Components or API routes with GET requests instead, Server Actions are built for mutations, and using them for reads gives up caching behavior you'd otherwise get for free.

A proxy centralizes load as well as logic

Centralizing data logic behind Server Actions is easier to maintain. One pattern, one place to update. The cost is that all that load lands on the Next.js server. As traffic grows, that server needs to scale with it, and on pay-per-invocation platforms the bill grows with it too.

Direct calls let frontend and backend scale independently. The Next.js layer stays thin and the backend absorbs its own load. The cost shows up later: fetching logic spreads across components, and tracing what calls what gets harder as the app grows.

A proxy hides more, but it's still attack surface

The proxy pattern is architecturally stronger on security, for a few concrete reasons:

API keys and tokens never touch the browser
The backend doesn't need to be publicly exposed, it can be firewalled to accept requests only from the Next.js server
CSRF protection comes built in
Authorization checks happen in one place, before anything reaches the backend

Going direct puts more of that burden on the backend itself:

JWTs stored in the browser are a target. Store them wrong and an XSS attack can steal them.
CORS has to be configured correctly, which is easy to get wrong.
The API needs its own rate limiting, input validation, and abuse protection.

None of that is unworkable, it's just work the backend now has to do on its own.

Neither pattern is immune to real vulnerabilities. CVE-2025-55182, the "React2Shell" vulnerability, allowed remote code execution via crafted payloads sent through the same POST/action-dispatch mechanism Server Actions use. The bug lived in React's own Flight protocol deserialization, not in anyone's Server Action code, but a proxy architecture still means treating Server Actions as endpoints that need patching and secure coding practices. The Next.js server can be the point of compromise too.

That's worth sitting with, because it cuts against the "proxy is just safer" framing above. Every layer between the browser and your data is also a layer that can be exploited, and a full Next.js server running action-dispatch logic is a lot more code than a stateless API behind tight CORS and short-lived tokens. The proxy pattern reduces what the browser can reach directly. It doesn't reduce the total surface, it just moves where the risk lives.

Pick by what you're optimizing for

Reach for Server Actions as a proxy when secrets need to stay hidden, when a centralized data access layer keeps the codebase easier to reason about, or when type-safe function calls matter more than shaving off a network hop.

Reach for direct client calls when the backend already handles OAuth, rate limiting, and CORS on its own, when latency is the constraint you're optimizing for, or when Next.js should stay a thin layer that just serves pages.

Most large apps use both

Large applications often use both. Server Actions cover sensitive operations, payment processing, account settings, anything touching secrets. Direct calls handle public, cacheable data like blog posts or product listings that don't need protection.

Sensitive calls take the extra hop through a Server Action to keep secrets on the server, while public data goes direct.

That split gets you the security of a proxy where it matters and the speed of a direct call where protection isn't the point.

FAQ

Do Server Actions really only run over POST?

Yes. Every Server Action, no matter what it does internally, gets invoked as a POST request. Next.js generates a hidden action ID and routes the call through that same mechanism, which is also part of why they don't get GET-style caching for free.

How do Server Actions protect against CSRF?

Two layers, by default. POST-only requests already sidestep most CSRF vectors, since SameSite cookies block cross-site POSTs in modern browsers. On top of that, Next.js compares the request's Origin header against the Host header and rejects the call if they don't match. You can widen that with the allowedOrigins option in next.config.js if you need cross-origin calls, but each origin you add is one more thing that has to be trusted.

What's the actual difference between revalidatePath and revalidateTag?

revalidatePath invalidates one specific route, and when a Server Action calls it, the response already carries the re-rendered page. revalidateTag(tag, 'max') works by tag instead. It marks every piece of cached data with that tag as stale, wherever it's used, and serves the old version while fresh data loads in the background, so the user doesn't see their change right away. When they need to, call updateTag(tag) in the Server Action instead, which expires the tag immediately. Reach for tags when the same data shows up in multiple places, and revalidatePath when you only need to refresh one page.

Can I run several Server Actions in parallel with Promise.all?

Not really, at least not the way you'd hope. Next.js's client sends Server Actions one at a time, waiting for each to finish before sending the next, and there's no setting to change that. The server itself doesn't queue them. If you need several things to happen at once, do the parallel work inside a single Server Action with Promise.all there, or move the read side to a Server Component or route handler instead.

Why do Server Actions feel especially slow on Vercel?

Serverless functions spin down when they're idle, and spinning one back up for the next request is what shows up as a cold start. That sits on top of the network hop a Server Action already adds. Keeping functions warm or moving latency-sensitive mutations closer to the edge helps, but it doesn't remove the extra hop.

Should I ever use a Server Action to fetch data?

Generally no. Server Actions are built for mutations, and fetching through one gives up the caching you'd get from a Server Component or a GET-based route handler. If a component just needs to read data, reach for those instead and save Server Actions for the writes.

Wrapping up

If you're optimizing for security and maintainability, the proxy pattern is the better default, even with the added latency. If you're optimizing for speed and a fully decoupled frontend, direct calls get you there, provided the backend can stand on its own as a public-facing API.

Most real applications end up mixing both rather than picking one architecture for everything. The important part is making that choice deliberately, based on what a given feature actually needs, rather than copying whatever pattern the last tutorial used.

Originally published at Notes by Sachintha.

How useEffect Works Behind the Scenes in React

Sachintha — Fri, 21 Nov 2025 01:19:37 +0000

You've probably called useEffect hundreds of times and wrestled with its dependency array at least once. But what does React actually do when it hits that call? If you've read how useState works under the hood, the fiber architecture here will look familiar, it's the same system powering both hooks.

React doesn't just run your effect function whenever it feels like it. There's scheduling, cleanup, and a few optimizations behind the scenes that decide exactly when your code runs.

So why does your effect run after the screen updates, and not the moment React reads it? This post answers that by walking through the Fiber architecture, the render and commit phases, and how React schedules and cleans up effects. If you've used useEffect but never looked at what React does with it, you have all the background you need.

Every useEffect call becomes an object on a fiber

Every component you write gets turned into a fiber node, React's internal data structure for tracking everything about that component. It's the same structure behind useState's state management.

When you call useEffect, React doesn't run your function immediately. It creates an Effect object and attaches it to the component's fiber. That object holds everything React needs to manage the effect's lifecycle.

Here's what's inside it:

tag marks whether the effect should actually run, based on whether its dependencies changed. React checks this flag before deciding to execute anything.
create() is your effect callback, the function you pass as the first argument to useEffect. It holds the actual side-effect logic: fetching data, setting up a subscription, touching the DOM.
destroy() starts out null. If your effect returns a cleanup function, React stores it here and calls it later.
deps is your dependency array. React compares it against the previous render's array to decide whether the effect needs to run again.

This is React's to-do list for side effects: what to run, and when to clean it up.

Effects wait until React has updated the DOM

React renders in two phases, render and commit, and effects only run once both are done. This split is the key to understanding when useEffect fires.

The render phase

During render, React runs your component function, diffs the virtual DOM, and figures out what needs to change. This is also where it registers your useEffect calls, it doesn't run them yet.

This phase is also where reconciliation happens: React compares the new virtual DOM tree against the previous one to figure out the minimal set of real DOM changes.

The commit phase

Once React knows what needs to change, it commits: it writes those changes to the real DOM. Only after that is done does React start running effects.

useEffect runs after the commit phase, not during it. That ordering matters. If effects ran during commit, every effect would have to finish before the user saw any visual update. Running them after commit means the screen updates first and effects catch up in the background.

This split also lets React batch effects together instead of running them one at a time as each component commits.

That's the general case, not a guarantee. If the effect was triggered by a direct interaction like a click, React may run it before the browser paints, so the effect's result stays observable to the event system.

Dependencies decide whether an effect runs again

On every render, React compares an effect's dependencies with the previous render's, and only a changed value marks the effect to run. Each useEffect call in your component creates an entry in that component's hook list, a linked list attached to its fiber.

Here's what happens on each render:

React creates or updates the Effect object for that call.
It retrieves the dependency array from the previous render.
It compares the new dependencies against the old ones using Object.is().

If any dependency changed, or if there's no dependency array at all, React marks the effect to run.

let hasChanged = true;
if (oldDeps) {
  hasChanged = deps.some((dep, i) => !Object.is(dep, oldDeps[i]));
}
if (hasChanged) {
  // Schedule this effect for execution
}

Object.is() matters here because it handles edge cases regular equality misses. Object.is(NaN, NaN) returns true; NaN === NaN returns false. That precision keeps dependency tracking correct.

Effects usually run after the browser paints

Once React finishes committing DOM updates, it moves into the post-commit phase, where effects execute, and it lets the browser paint before it starts.

React flushes all pending DOM updates, so every visual change is applied before any effect runs.
It collects every effect marked for execution across all components in the current render cycle.
It runs cleanup functions from the previous round of effects first, before running the new ones.
It runs the new effect callbacks asynchronously, through React's own Scheduler rather than a microtask.

That last step trips people up. queueMicrotask() looks like the obvious tool for "soon, but not right now," but it isn't what React uses here. Microtasks drain before the browser gets a chance to paint, so effects scheduled that way would fire before the screen updated instead of after, undoing the whole point of deferring them. React posts the flush through MessageChannel instead, the same mechanism its Scheduler package uses elsewhere, a macrotask-like hand-off that lets the browser paint first and gives effects the next turn after that.

Cleanup runs before the next effect and on unmount

If your effect returns a function, React stores it as the cleanup for that effect and calls it before the next run of that effect, or when the component unmounts.

Here's what happens without one. This effect starts polling a chat room, and restarts whenever roomId changes.

useEffect(() => {
  setInterval(() => fetchMessages(roomId), 5000);
}, [roomId]);

Switch rooms twice and three intervals are running, one per room you've visited, each still fetching and holding on to its old roomId. Returning a cleanup fixes it.

useEffect(() => {
  const id = setInterval(() => fetchMessages(roomId), 5000);
  return () => clearInterval(id);
}, [roomId]);

Subscriptions, timers, and event listeners all hold references that keep objects alive in memory. Without cleanup, those references pile up and the app leaks memory over time.

React calls cleanup functions in two situations:

Before the next effect runs, if dependencies changed. This stops subscriptions or timers from overlapping.
When the component unmounts, so no reference outlives the component. That includes when an error boundary catches a render error and unmounts the failing subtree, so a render error doesn't skip cleanup and leak memory anyway.

You don't have to track any of this timing yourself. React handles it.

Children's effects run before their parent's

Before reading on, guess what this logs when Parent mounts.

function Child() {
  useEffect(() => console.log('child'));
  return null;
}

function Parent() {
  useEffect(() => console.log('parent'));
  return <Child />;
}

Most people expect parent first, since Parent renders first. It prints child, then parent. React renders top-down, but it runs effects bottom-up. React runs effects in a fixed, predictable order:

Child effects run before parent effects, so a child's updates settle before the parent's do.
Cleanup functions run before new effects, so side effects never overlap.
Unmount cleanups always run, so nothing gets left behind when a component is removed.

This ordering isn't arbitrary. If a parent's effects ran before its children's, the parent could end up processing data the children haven't finished updating. And if new effects ran before old ones cleaned up, you could end up with two WebSocket connections open at once instead of one, causing duplicate data or race conditions.

Hooks are matched by call order

React keeps a linked list of hooks attached to each fiber. Every useEffect, useState, or useMemo call adds an entry to that list.

This is the reason the Rules of Hooks exist. React matches hook state between renders by call order, the same mechanism behind useState's hook registration. Change the order hooks are called in between renders, and that mapping breaks.

class Hook {
  constructor() {
    this.state = null; // Stores the effect object
    this.next = null; // Pointer to the next hook
  }
}

React walks this list in order on every render, matching each hook call to its entry. Reorder the calls, for instance by putting a hook inside a conditional, and React can end up handing a useEffect hook the state meant for a useState hook. That's why hooks can't live inside loops, conditions, or nested functions: React needs to know exactly how many hooks will run, and in what order, to keep the mapping straight.

useLayoutEffect is the one that blocks paint

useEffect usually lets the screen update first, while useLayoutEffect always holds it up. Running effects asynchronously buys a few things:

Rendering never waits on an effect to finish.
The browser paints before effects run, not after.
Effects from one render cycle run together instead of one at a time.

useLayoutEffect is the exception: it runs synchronously, before paint. That's useful for DOM measurements or layout adjustments, but it can block the UI if the work takes too long.

Hook type	Execution timing	Blocking?
`useEffect`	After paint (asynchronous)	No
`useLayoutEffect`	Before paint (synchronous)	Yes

The async default matters most while a user is actively interacting, scrolling a list or typing into a field. If effects ran synchronously, they could stall the response to that interaction.

Four common misreadings of useEffect

"useEffect runs during render." It doesn't. React only schedules it during render; the actual call happens after commit.

"Dependencies cause re-renders." They don't. Dependencies decide whether the effect re-runs, not whether the component re-renders. The component can re-render for unrelated reasons, like a state or prop change, while the effect stays untouched.

"Cleanup runs instantly." It runs before the next effect, or on unmount, not the moment the effect finishes.

"Every dependency must be in the array, no exceptions." The lint rule is a safe default, not a law. React's own guidance is that an effect should synchronize with something outside React, not fire in response to every value it happens to read. If you're fighting the array just to keep a function or value "current" without wanting to restart the effect, that's usually a sign the logic belongs in a ref, an event handler, or shouldn't be an effect at all.

Keep effects small and their dependencies honest

Keep dependency arrays accurate and minimal. Every extra dependency gets compared on every render; every missing one risks a stale closure.
Split unrelated effects into separate useEffect calls. It's easier to debug, and React can skip each one independently.
Reach for useLayoutEffect only when you need a DOM measurement or a synchronous layout update. useEffect is the right default otherwise.
Don't use an effect to compute a value from props or state. Calculate it during render, with useMemo if it's expensive. An effect would render once with the stale value, then again with the new one.

FAQ

Why does my useEffect run twice in development?

That's Strict Mode. In development, React intentionally mounts, unmounts, and remounts your component to check that your cleanup function actually works. In production, effects run once. Write effects so they behave correctly even when called more than once.

Can I use useEffect for data fetching?

Yes, with some care around cleanup and error handling. A common pattern uses a flag to skip setState calls after the component has unmounted:

useEffect(() => {
  let cancelled = false;

  const fetchData = async () => {
    try {
      const response = await api.getData();
      if (!cancelled) {
        setData(response);
      }
    } catch (error) {
      if (!cancelled) {
        setError(error);
      }
    }
  };

  fetchData();

  return () => {
    cancelled = true;
  };
}, []);

The flag makes sure setState never fires after teardown. Once the effect has dependencies, such as [userId], the same flag also stops a slow, older response from overwriting a newer one. React 18 removed the old "Can't perform a React state update on an unmounted component" warning, but ignoring stale results still matters. For anything more involved, a library like React Query handles the caching and race conditions for you.

What's the difference between useEffect and useLayoutEffect?

useEffect runs asynchronously, after the browser paints. useLayoutEffect runs synchronously, before paint. Use useLayoutEffect only when you need to measure the DOM or apply a layout change before the user sees anything, otherwise the extra synchronous work just delays the paint.

Why do I need to include functions in my dependency array?

Functions are objects in JavaScript, and a new one gets created on every render. If your effect uses a function from props or state and you leave it out of the dependency array, the effect keeps calling whatever version of that function existed when it first ran, a stale closure. The same issue shows up with stale state values in useState.

Can I skip the dependency array?

You can, but the effect will then run after every render, which usually isn't what you want and can cause a render loop. Include exactly the dependencies the effect reads.

How do I clean up subscriptions in useEffect?

Return a function from the effect. React calls it before the next effect runs and again when the component unmounts, which is where you clear intervals, cancel in-flight requests, or remove event listeners. Anything that keeps a reference alive after your component is gone needs to be released here, following the same lifecycle React uses to manage state cleanup.

Wrapping up

useEffect looks like a simple API, but underneath it's a fiber-based scheduling system deciding exactly when your side effects are allowed to run.

Knowing how dependency comparison, scheduling, and cleanup fit together makes your effects more predictable, and makes the bugs easier to track down when they happen. Paired with how useState manages state internally, that's most of what you need to know about how React's hook system actually works.

Originally published at Notes by Sachintha.