@Vesper Sparrow I wouldnt do it for most cases.

Like server components exist for a reason, dont overuse fetching from server actions.

Also server actions are POST requests, you making GET requests from them is bad practice.

Any function exported from a file marked use server will be described as a Server Action. You won't leak sensitive data to the client as long as you use a dedicated file for your server actions (don't define an anonymous function with use server inside a component) and as long as the data you return to the client doesn't include things it shouldn't.

As a best practice, I like to parse all non-trivial data that goes to a client with zod before returning it.

In some cases its fine, like when you have an infinite scroll component, where you are fetching data on the client.

+1 to @Arinji though. If you're just trying to get data, you're probably better off with an API route or finding a way to pass it from a Server Component into the client.

Yup, im assuming here OP is talking about GET requests since they mentioned "getting data and returning it to the client"

is retrieving data from a server action or a server function slower than getting same data from an API route ? i just want to get most of NextJS and getting data from a server fucntion is easier than making an API route and passing data from a server component to client component and sometimes i use this data in different places so it easier to just call a function where its needed

The important thing to know is that Server Actions in Next.js cannot work in parallel

They always execute serially

So if you fire 10 server actions, each will wait for the previous to resolve before it starts

This is a problem if you have a very dynamic page. Image a social media feed where users can "Like" multiple posts. If they click 10 Like buttons and one of those hangs for some reason, everything will stop.

Server Actions are optimized for mutations that might bust your cache: form submissions, basically.

At least in the Next.js implementation. As I understand it, some other frameworks working on implementing Server Actions allow them to run in parallel.

This is entirely different from traditional API requests where you can fire off a bunch of them, they'll be handled by different threads/processes/servers on your backend and come back in the order that they were processed.

I would say it is generally a bad idea to treat Server Actions as API requests for this reason. It is a path to surprising behavior and bad experiences for users.

It's also completely invisible from a developer perspective so it will be hard to troubleshoot if you get reports of it.

i didn't know that! u explore new things in next every day 😀 thank u for this explanation 🙏

IMO it's the most important aspect of server actions that gets almost no discussion

Yup, we did discuss it once in discussions, but yea most just dont talk about it.. even took me a while to recall xD

This was the discussion
https://discord.com/channels/752553802359505017/752647196419031042/1223589065220161556

This was an explanation of the potential reason by Joulev
https://discord.com/channels/752553802359505017/752647196419031042/1223667975169638542

@Pacific herring @Vesper Sparrow

I love working with RSC/RSA but things like this really sting.

hence: dont fetch data with server actions. if you want to fetch on the server, use server component like normal, if you want to fetch on the client, use route handlers like how everyone's been doing for ages

server actions are for mutations. they are POST, not GET

Yea so its wrong in every way xD

Yeah that’s a documentation / naming / communication fail IMO

the only places i would fetch with it, is an infinite scroll type situaton.. but thats really it

anyways @Vesper Sparrow mark an answer if your question has been solved :D

It’s not a significant detail until it is and then it’s likely to be very significant and frustrating.