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:

8 Reasons Your Next.js App Is Slow — And How To Fix Them

8 reasons your Next.js app is slow — and how to fix them

You don’t need to guess what’s wrong with your Next.js app. I’ve mapped out the 8 biggest performance traps and the fixes that actually work.

Chizaram Ken
Jun 20, 2025 â‹… 16 min read
how to truncate text in CSS (single and multi-line)

How to truncate text in CSS (single and multi-line)

Learn how to truncate text with three dots in CSS, and use two reliable CSS text truncation techniques while covering single-line and multi-line truncations.

Chinedu Okere
Jun 20, 2025 â‹… 10 min read
how to use the Interest Invoker API for better, more accessible UX

How to use the Interest Invoker API for better, more accessible UX

Explore how to use Google’s new experimental Interest Invoker API for delays, popovers, and smarter hover UX.

Emmanuel John
Jun 19, 2025 â‹… 7 min read
How To Build And Deploy A Web App With Bolt.new

How to build and deploy a web app with Bolt

Bolt.new revolutionizes how you build and deploy web apps with no-code development and seamless AI integration.

Isaac Okoro
Jun 19, 2025 â‹… 8 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