2024-08-29
3726
#nextjs
Peter Ekene Eze
183861
Aug 29, 2024 ⋅ 13 min read

Diving into Server Actions in Next.js 14

Peter Ekene Eze Learn, Apply, Share

Recent posts:

Why third-party integrations break in React 19 — And how to future-proof them

React 19 breaks old third-party integrations. Learn why concurrent rendering exposes brittle SDKs and how to rebuild them with resilient modern patterns.

Ikeh Akinyemi
Oct 20, 2025 ⋅ 4 min read
React useEffectEvent: Goodbye to stale closure headaches

React useEffectEvent: Goodbye to stale closure headaches

Discover why the useEffectEvent Hook is important, how to use it effectively, and how it compares to useRef.

David Omotayo
Oct 17, 2025 ⋅ 5 min read
I Tried Shadcn CLI 3.0 — Here’s What I Learned

I tried Shadcn CLI 3.0 — here’s what I learned

Shadcn CLI 3.0 takes component management to a new level. With namespaced registries, private access, and AI-powered discovery, it’s now faster and smarter to build React UIs.

Emmanuel John
Oct 17, 2025 ⋅ 6 min read

Why is Zod so slow?

Zod’s flexibility comes at a cost. This article breaks down why Zod is slower than AOT-compiled validators like Typia, and how to fix it with a build-time optimization that brings production-grade performance.

Ikeh Akinyemi
Oct 16, 2025 ⋅ 5 min read
View all posts

2 Replies to "Diving into Server Actions in Next.js 14"

  1. So the main issue was that if we posted a new item into a list, we had to do the POST request and then pull data again with a GET to have the UI updated? And this was expensive because there are 2 requests for 1 action, basically, right?

    What we did was:
    – we had a layer for state management (i.e Redux)
    – a layer for API calls (middleware on client side)

    Upon a request, we updated UI optimistically or pessimistically, depending on what the team wanted.

    So, when someone does a POST request, it calls the middleware API, We await the status code, if it’s 200, we update the UI (redux state) and this way, we achieve consistency between server and client’s UI in 1 request, not 2. Which means only 1 server is needed (some S3 bucket for the react site files) and 1 action needed (like the pessimistically update mentioned above). No need for having a second server running the server-side components, no need to trigger a GETall after a POST to see the updated UI. Nothing. Just a well structured and organized application. And it still adheres to separation of concerns since on the backend I run edge functions for the updates etc. It’s just more things on the client. And I am totally fine with SSG because yes, first load is larger but then everything else is a breeze, not requiring calls to a server. But yeah, I guess anything goes nowadays.

Leave a Reply

Hey there, want to help make our blog better?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now