Server actions (revalidateTag/revalidatePath) vs traditional SPA data fetching
Unanswered
Palomino posted this in #help-forum
PalominoOP
I might be wrong but since revalidatePath/revalidateTag causes a rerender of the whole route on the server, isn't slower than the traditional spa where it only fetches the json data and nothing else?
139 Replies
revalidate tag does not rerender the entire route
if it did there wouldnt be much point of the the separation of those functions 😉
Cimarrón Uruguayo
revalidate path does
They both invalidate the caches so the routes have to be rerendered after they refetch the data
I believe
@Palomino They both invalidate the caches so the routes have to be rerendered after they refetch the data
you arent thinking deep enough. The docs cannot explain every possible scenario, and use top level fetches in pages as the example
additionally, ISR addresses a significant portion.
so how much it re-renders is fully dependent on how well you create your branch/leaf structure
PalominoOP
ISR involves rerendering the routes at some interval or when the caches are invalidated which revalidateTag/Path does
you may choose to trigger ISR at an interval
but it itself has no concept of an interval
@DirtyCajunRice | AppDir you may choose to trigger ISR at an interval
PalominoOP
Yeah thats what I mean
then… what is the question lol
PalominoOP
ISR doesn't help make revalidateTag/path more efficient
if you fetch in a server component that is nested, and you invalidate that tag, your page is only going to rerender that component
i do it in many components across many sites.
@DirtyCajunRice | AppDir if you fetch in a server component that is nested, and you invalidate that tag, your page is only going to rerender that component
PalominoOP
Wouldn't it need to rerender the whole route on the server to make a new entry for the Full Route Cache? (for static routes)
@Palomino Wouldn't it need to rerender the whole route on the server to make a new entry for the Full Route Cache? (for static routes)
If i was building a static site i wouldnt be using nextjs
the primary benefit of nextjs is SSR.
PalominoOP
SSR involves static routes
and static rendering
ok ill let you argue with someone else. i came in here to answer your question not debate nonsense
PalominoOP
You didn't answer my question of why it is not slower than just getting pure json data
For example, it would need to rerender the whole route because it needs to be sent to the client no?
revalidateTag/Path invalidates the Router cache so all the RSC Payload is gone
client = call for everyone every time. cache is scoped to user.
server = call for everyone 1 time. cache is scoped to application.
server = call for everyone 1 time. cache is scoped to application.
if SPA stood for single person app yes it would be faster. But as a single page app, it is slower by scale.
@DirtyCajunRice | AppDir client = call for everyone every time. cache is scoped to user.
server = call for everyone 1 time. cache is scoped to application.
PalominoOP
RevalidateTag/Path would invalidate the cache
PalominoOP
I'm listening but I think you are giving me the wrong info tbh
you arent listening at all
you have already decided what you think is right
and are dismissing literally everything else that doesnt fit what you have decided
PalominoOP
Tell me where I'm wrong
at the beginning
if you have a page. and that page has data. and that data is cached for 1 day.
and 100 people go to it
it renders very quickly
except for the first person
then revalidate is called
the first person it is slow again
then it is fast for everyone again
because the cache is server side
revalidating has nothing to do with the client
the client gets a changed result, but is not the target
PalominoOP
What if the data is personalised?
what does that matter
PalominoOP
There is only the first person and no other person
the point of the cache is for subsequent calls
if you are going to show them new data every time why are you caching to begin with
PalominoOP
Right you wouldn't even need to call revalidatePath/Tag
But it is still slower than the tradtional spa?
what are you talking about
how is it slower if you arent using it
are you conflating server fetching with server actions? they are not the same thing
PalominoOP
So if you aren't caching data, the route uses dynamic rendering. Every time a user wants to create a new item, you would use a server action to create the item and then send back the new data.
well
depends
you can do it multiple ways.
the benefit of a server action in that specific case is the privacy of access to the data
creating a new todo means storing something in a database which the client shouldnt have access to.
PalominoOP
So you would use a server action then?
to click create? yep. i wouldnt cache tho
not if the entire premise is live data
PalominoOP
For example, I'm thinking about a user's todo. It is static data until they create/delete/update a todo
it is not faster to be pure json.
PalominoOP
Why not?
because the user may look at their todos more than once ever in their life without modifying their todos
PalominoOP
Yes that makes sense
Original message was deleted
this has literally nothing to do with the conversation.
and you are going to immediately make it veer off track
Cimarrón Uruguayo
ok
to open and shut that irrelevant door, that would still be server side. He is trying to grasp why calling server at all is better than client.
Cimarrón Uruguayo
i was under the assumption that we were thinking about server side calls
@DirtyCajunRice | AppDir to click create? yep. i wouldnt cache tho
Cimarrón Uruguayo
from here
this thread alone may have used all the patience i have for the day
PalominoOP
Server actions by itself would be slower than just getting json data but I guess the caching nextjs does makes everything else faster
@Palomino Server actions by itself would be slower than just getting json data but I guess the caching nextjs does makes everything else faster
you shouldnt be using server actions just to get json data in the first place
thats not what they are for
PalominoOP
I know, they receive RSC payload when they renreder the server components but if it could just get json data while keeping the benefit of the caching on the serverside, it would be faster
Cimarrón Uruguayo
RSC payload is irrelevant here
@Palomino traditionally, what you do is
With a server action, you basically mitigate this, and return the data directly in the same step
fetch
your JSON data from the frontend and have an api handler that returns this dataWith a server action, you basically mitigate this, and return the data directly in the same step
there is no separation of "fetching" and "providing" if that makes sense
Cimarrón Uruguayo
damn 💔
if you are just fetching data it should be done directly in a server compnent
no server action needed
at all
Cimarrón Uruguayo
OK
let me clarify
sorry
include a database in there
still no
@DirtyCajunRice | AppDir what
PalominoOP
What don't you understand?
you still fetch it in a server component,
@Palomino What don't you understand?
How that sentence had any relevance or accuracy at all
@DirtyCajunRice | AppDir you still fetch it in a server component,
Cimarrón Uruguayo
no as in, in an SPA you'd have the api handler GET() call db.get(
query
) and return (json data), and on the client side return the fetched jsonwhereas with server action you don't need fetch
just call db.get directly
and use that data
at least that's my understanding of use case
you are calling post
just like with an api route
Cimarrón Uruguayo
ok i give up i should actually leave
my bad
@Cimarrón Uruguayo ok i give up i should actually leave
server actions are simply purpose built slimmed down and isolated route handlers.
Cimarrón Uruguayo
yeah sorry my bad
with the caviat that they are meant for MUTATION based api calls
PalominoOP
Server actions (revalidatePath):
1. client makes request to server
2. update DB
3. invalidate cache
4. Turn server components to RSC Payload
5. Respond with RSC to client
yes?
1. client makes request to server
2. update DB
3. invalidate cache
4. Turn server components to RSC Payload
5. Respond with RSC to client
yes?
4 and 5 are wrong
and for extreme clarity, 2 and 3 arent server actions either
they are just things you may call in one
PalominoOP
Ok what is your version?
its not my version
its just how they work
PalominoOP
Like give me your step by step of how server actions work
PalominoOP
I have read it
It doesn't say
Can you specify?
section
@DirtyCajunRice | AppDir Click to see attachment
PalominoOP
This isn't relevant?
@Palomino This isn't relevant?
re word this or my patience is gone and someone else can baby step you through this.
@DirtyCajunRice | AppDir re word this or my patience is gone and someone else can baby step you through this.
PalominoOP
This isn't relevant.
Ill leave you with a thought. When you want to learn something, its smarter ask questions than make statements, as argumentative, stubborn, and ignorant of the topic all at once wont get many people to help you.