Server actions to READ data (vs WRITE)

[ivan-kleshnin]

So I've checked all this new NextJS stuff with RSC, Router Handlers and Server Actions and there's one thing I fundamentally do not get 🤔

Server Actions are presented as an alternative to API routes. It's an implementation of an old RPC idea explored in TRPC, Telefunc and Zodios. I understand and share the appeal to replace API routes with functions. Afterall, a function is the most straigtforward to describe a contract between a producer and a consumer (of some functionality).

There're some rough edges that currently make the approach less convenient than it could be. But such issues will be fixed in the future – I guess.

Hovewer, what I find missing in the context of Server Action is the read (vs write) part of a data flow. From the docs it seems like we are proposed to implement Router Handlers which are, still... HTTP/API endpoints – that were supposed to become unnecessary.

I realize that fetching data on the server should be preferred, but it's not always an option (infinite scrolls, etc. interaction-triggered fetching). So let's assume we're talking about interactive, client components.

To read data we should fetch from an HTTP endpoint declared e.g in a app/api/route.ts file, in one folder, with one kind of syntax and conventions. And to write data we should call a server action, declared e.g in actions/index.ts file in another folder with another kind of syntax and conventions.

Am I the only one who's surprised by it, and finds it counter-intutive & inconsistent?

There's an API to directly call a Server Action which can be used to fetch data on the client:

const [todos, setTodos] = useState<any[]>([])

const [isPending, startTransition] = useTransition()
useEffect(() => {
  startTransition(() => getTodos().then(setTodos))
}, [])

Hovewer, the above is not compatible with cache & invalidations, unlike a fetch function 🤷‍♂️

I'm not excited by the necessity to have 2 very different and naturally incompatible approaches to connect a client and a server. If we go the action road, wouldn't it be natural to use them for ALL client-server communications, at least by default. Do I miss something?

[nikitastryuk]

100% agree, have exact same thoughts

[ivan-kleshnin]

@nikitastryuk thanks! You may find the following video interesting:

https://www.youtube.com/watch?v=IFYFezylQlI

There, the author implements an infinite scroll where initial data loading is performed on the BE, and the consequent fetches are performed on the FE (via a server action). One commenter even asks the same question as we have: "Is the approach legit and (if so) why it's not documented properly?" The answer was that "I think it's legit but, you know, it's all experimental, bro..."

I've also messed with this in sandboxes and what I can confirm – there're definitely pitfalls with caching. As soon as you need to combine non-interactive server-side with interactive client-side, working with the same data. Overly aggressive NextJS caching interferes with everything.

The simplest example. If you have an infinite scroll with a server-side initial load – you have to revalidate in the server-action, it's currently the only way to avoid stale data. But if you revalidate – you'll have DOM reconcilations from the root while the infinite scroll component fetches the next page. One solution can be a split between 2 very similar server actions: one for the initial load (with revalidation) and another for the consequent loads (without revalidation). It all kinda works but feels finicky, t.b.h.

[Bruce9000]

Leerob made an interesting commit to NextJS repo yesterday:
29fcd57
"You don't fetch data with Server Actions, but mutate."

Quietly removing the recommendation that Server Actions can be used for Data Fetching :(

If Vercel are shifting the narrative to SA are only for mutations not fetching, then continuing to use SA for data fetching feels like you are swimming against the tide and it will essentially becomes unsupported...

[ivan-kleshnin]

Thanks, Bruce! Yes, it makes sense as server actions turn out to be sequential by design... So it's really mutation-only.
And we personally won't invest into refactoring to S.A as, in our current view, they add no value to the fullstack project architecture. You'll have to invest time in API design, API authentication, API error handling anyway. So why bother with two different approaches one of which is fundamentally limited and React/NextJS specific?!

[AsadSaleh]

I just want to add to this because it has been in my head for so long, but now I will write it all down.

Disclaimer: I love React.js and Next.js, I'm not to disrespct anyone here.

I started using Next.js app directory when the version 14 came out (and now as I'm writing this, Next.js 15 just came out). I feel the ability to fetch data on the server with Server Components and easily mutate it with Server Action is really fun, and I found it solve 80% of my problems.

What I love about Next.js is, obviously, the full-stack nature of the framework. I can integrate many things in a single code base. For example: connect to my database or integrate with 3rd party APIs. Something that fully client-side framework cannot do.

However, in an application, usually we need client-side data fetching. Be it for a dropdown with async data, or we just want to defer a query until some local state changes. Obviously this is common thing. Surely you must have had this requirement in your projects.

Before I jump to the problem, I want to let you feel my pain first:
We have Server Action with it's beautiful end-to-end type safety. It is really awesome. It's like gRPC freely installed on your project, without the overhead of installing it.

Pic 1: Let see one example of a beautiful Server Action.

(it's not the full code, just type definition of it)

From the code above, we can securely call the Sever Action with a strongly typed arguments and a strongly typed return value. SUUUPEEER ✨

Not only that, we can easilly call it from our buttons, or our forms, or wrap it in a useMutation. In other words: anywhere from our client components. "THIS THING HAS AN AWESOME DX", I said to myself.

Now we jump to the problem:
But why on earth, if I want to do a client-side data fetching, Next.js pushed me to use an old school Route Handlers and destroy the awesomeness, the type-safety, the super good DX, of a Server Action?

Pic 2: Example of client-side data fetching using route handlers. We need to create a route handler first.

Pic 3: Then from a client component, we fetch it. However we lose all the type and need to cast is manually.

WHY? Just WHY?

Are client-side data fetching a rare use case? Or I'm in the wrong here? I missed a docs or something?

What I end up doing, and I know this is against the rules, is to use Server Action for data-fetching. I comprehensively tested it and it works quite nicely in my project. Everything works fine. I even use it inside useQuery and it worked really great. However I noticed a drawback. Some request take longer than expected. And also I need to exclude Server Action in middleware.ts, or else it won't work.

So, I really need to find a better solution here.

If someone can explain to me what is the recommended approach to do client-side data fetching WITH GOOD DX, please let me know. It will be much appreciated.

Thank you guys.

[rwieruch]

I think many people came to a similar conclusion and started to exploit server actions for data fetching. That's a big reason why the React team decided to introduce Server Functions.

[AsadSaleh]

Hi @rwieruch. I read your blog and I'm glad I'm not the only one doing it.

I just read again about React 19's Server Functions. However in their example it still mostly resemble Server Action. There are no provided example that uses Server Functions to do data fetching.

But maybe they'll add it in the future?