Server - client communication
Unanswered
Asiatic Lion posted this in #help-forum
Asiatic LionOP
I've read the documentation and it seems to me that these are the patterns recommended for communicating between the client and server to fetch/mutate data:
- fetch in server components: just call an async function
- fetch in client components: create an API endpoint and call it in a useEffect and store it in a useState or use react-query and similar tools
- mutations in client components: server actions
My question is: is this correct? If so, why isn't there a single way to do this?
- fetch in server components: just call an async function
- fetch in client components: create an API endpoint and call it in a useEffect and store it in a useState or use react-query and similar tools
- mutations in client components: server actions
My question is: is this correct? If so, why isn't there a single way to do this?
11 Replies
Asiatic LionOP
These patterns are wildly different and they are more difficult to reason about and organize vs something like a tRPC API where everything goes in and out the same way. Where you can have middleware, validation, etc all in the same place.
Why isn't there something like: always use server actions that:
- in fetch server components just get called as a function
- in client components: get converted to RPC calls and can be configured to run in parallel and via HTTP GET method and can be cached
Why isn't there something like: always use server actions that:
- in fetch server components just get called as a function
- in client components: get converted to RPC calls and can be configured to run in parallel and via HTTP GET method and can be cached
Yup, you are absolutely correct.
Server actions can't run in parallel, so api routes have to be used.
Server actions can't run in parallel, so api routes have to be used.
Because the functions which you execute on server probably won't be executed the same way on client.
On server, you can create a function like
But you can't execute the same way on client, as access needs to be limited.
I never had a usecase where I had to execute a use server function in server
On server, you can create a function like
async function dbOperation(query){
return sql(query);
}But you can't execute the same way on client, as access needs to be limited.
I never had a usecase where I had to execute a use server function in server
Asiatic LionOP
What's wrong with always writing server actions with validation and authorization? Take for example a server action that fetches posts based on some filters (and filters based on what the current user can see and validates the inputs).
You could theoretically use the same function to show a list of posts in a server component (where you get filters from e.g. query Params) and also reuse that same function in a select drop-down where the user can select a post (client component)
You could theoretically use the same function to show a list of posts in a server component (where you get filters from e.g. query Params) and also reuse that same function in a select drop-down where the user can select a post (client component)
That's what you would do in a SPA, no? The only difference is that you'd inline the call to SSR in a server component.
Sorry, forgot to reply ^
server actions should not be used for data fetching
Asiatic LionOP
No I know. I meant in my dream world.
use api route, which would execute a function to get the list of posts.
Asiatic LionOP
Like a proposed solution
Yes this is correct. You can also fetch using server action to simplify things.
This is partially what server action does. Requests are converted into RPC calls. The only thing thats missing is that it can't yet run in a parallel via GET method. But it can be cached.
Anay recommended that server actions should not be used for data fetching only because it can't be run in parallel and also the fact that it sends a POST method. But if you dont care about those you can use it as a data fetching method.
get converted to RPC calls and can be configured to run in parallel and via HTTP GET method and can be cached
This is partially what server action does. Requests are converted into RPC calls. The only thing thats missing is that it can't yet run in a parallel via GET method. But it can be cached.
What's wrong with always writing server actions with validation and authorization?Nothing wrong with that
You could theoretically use the same function to show a list of posts in a server component (where you get filters from e.g. query Params) and also reuse that same function in a select drop-down where the user can select a post (client component)Yes you could.
Anay recommended that server actions should not be used for data fetching only because it can't be run in parallel and also the fact that it sends a POST method. But if you dont care about those you can use it as a data fetching method.