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:

A Guide To Wrapper Vs. Container Classes In CSS

A guide to wrapper vs. container classes in CSS

A breakdown of the wrapper and container CSS classes, how they’re used in real-world code, and when it makes sense to use one over the other.

Temitope Oyedele
Jul 7, 2025 â‹… 10 min read
Stagehand and Gemini logos on a gradient background symbolizing AI web automation

How to build a web-based AI agent with Stagehand and Gemini

This guide walks you through creating a web UI for an AI agent that browses, clicks, and extracts info from websites powered by Stagehand and Gemini.

Elijah Asaolu
Jul 4, 2025 â‹… 8 min read
Getting Started With Claude 4 API: A Developer's Walkthrough

Getting started with Claude 4 API: A developer’s walkthrough

This guide explores how to use Anthropic’s Claude 4 models, including Opus 4 and Sonnet 4, to build AI-powered applications.

Andrew Baisden
Jul 3, 2025 â‹… 16 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [July 2025 edition]

Which AI frontend dev tool reigns supreme in July 2025? Check out our power rankings and use our interactive comparison tool to find out.

Chizaram Ken
Jul 2, 2025 â‹… 3 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