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:

JavaScript Dictionary

JavaScript dictionary: How to use objects and maps for key-value pairs

Learn how to use JavaScript dictionaries with Objects and Maps. Discover key differences, performance insights, and best use cases with practical examples.

Elijah Agbonze
Feb 25, 2025 â‹… 9 min read
A guide to the CSS grid-template-columns property

A guide to the CSS grid-template-columns property

Take a deep dive into the CSS grid template columns property, an essential part of the CSS Grid Layout specification.

Samuel Martins
Feb 25, 2025 â‹… 15 min read
A Guide To Node.js Readable Streams

A guide to Node.js readable streams

Explore how Node.js readable streams process data in small chunks, manage data flow, handle errors, and ensure resource cleanup.

Yan Sun
Feb 25, 2025 â‹… 7 min read
Advanced React State Management Using URL Parameters

Advanced React state management using URL parameters

Manage state in React using URL parameters for better performance, SEO, and accessibility while enabling shareable and server-rendered application states.

Rahul Chhodde
Feb 24, 2025 â‹… 16 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