NextJS Server Actions vs Traditional API
Can someone explain the benefit of using RSC data fetching/server actions as opposed to a traditional API (GraphQL, tRPC, REST)?
It seems that traditional “API” functionality such as middleware, external consumers, etc. is not something that can be done with server actions. To me, this seems like a bit of a step backwards in the context of a web app.
Are server actions intended to serve a different role entirely? I’m primarily a backend dev, so the concept of not having a traditional backend/API layer is still new to me. Thanks in advance!
It seems that traditional “API” functionality such as middleware, external consumers, etc. is not something that can be done with server actions. To me, this seems like a bit of a step backwards in the context of a web app.
Are server actions intended to serve a different role entirely? I’m primarily a backend dev, so the concept of not having a traditional backend/API layer is still new to me. Thanks in advance!
23 Replies
if you figure it out. let me know 🙂
I think I understand where you're coming from.
First of all, I would say productivity. An API is usually way too complex for what a lot of apps need to do. Why write a whole API layer if all you want is a simple crud? It's way easier to just have a function (server action) that provides you with an endpoint and does what it has to do.
And about the RSC, I haven't studied much about them yet, but from what I gathered, it's about avoiding JavaScript mutation on the client.
If you have tried coding in React, you know how managing states can be quite painful sometimes, which happens because the client has to wait for the server's response to update the state of a component.
But now, if you have both in the server, from what I understand, you won't have to deal with side effects.
yes, basically php with good developer experience
How is it better?
It’s not really avoiding it though. It just prevents it
Like not allowed. Not doing it differently
Tldr:
- RSC avoids managing states since it's all on the server.
- Server Actions delete the need to implement a whole API all the time
I haven't used php, but just looking at the code gives me a headache.
Now I find React to be the cleanest code structure I've ever worked with
IMO it looks remarkably similar
But less confusing since it’s easy to understand what code runs where
but on the technical side of it.. I don't really know since I don't know much about php
that's a fair point
Fair enough
I don't think we're walking backwards, I think we're looking at history and improving from what we've learned
i def feel like its backwards
Dan Abramov (or however its spelled) was even saying 'yeah its like php but now ttheres no page refresh'
and like.... sure. but surely it couldnt have taken over a decade of development to get to 'no page refresh when submitting a form'
and IMO its worse because RSCs and server actions introduce a whole set of new problems that havent really been solved yet. RSC's are gunna confuse the crap out of new devs (which everyone is right now because nobody is used to components running on server). its very difficult to answer the question 'where does this code run?' and i think thats gunna lead to a lot of confusion at best and security problems at worst
also we now have tools like react query / trpc that solve a lot more problems than just running typesafe apis. these tools also help with caching, managing loading states, validation, etc
to me server actions are like someone saying 'heres a brand new and exciting child's bike'. im never gunna use it. my apps have (for the most part) outgrown it
thats just my 2 cents tho
So it sounds like server actions would be well-suited for something like progressive enhancement, but are not intended to replace the API layer?
this video jkust came out and i agree with pretty much everything he says here (and i disagree with theo)
Jack Herrington
YouTube
Did RSCs Really Turn React Into PHP?
👉Code: https://github.com/jherr/rscs-vs-php/tree/main/rust
👉 I'm a host on the React Round-Up podcast: https://devchat.tv/podcasts/react-round-up
👉 Don't forget to subscribe to this channel for more updates: https://bit.ly/2E7drfJ
👉 Discord server signup: https://discord.gg/ddMZFtTDa5
👉 VS Code theme and font? Night Wolf [black] and Operator Mo...
(there is a TL;DR at 17:33)
im not really sure what you mean by progressive enhancement
Kinda, it is supposed to replace the API layer if you don't need an API layer
My company works with a lot of mid sized apps and we cut the development time in more than half by eliminating the API in our latest project, and since then, there hasn't been a single time in which anyone said "damn, how I miss fetching from an external Java API"
Now, you wouldn't want to replace the API if your company has lots of apps that consume from that API. There are cases and cases
@deforestor that's super cool, would you mind sharing how you all handle middleware type stuff (authentication, logging, etc) in server actions? That seems like it would be tedious calling the same functions over and over with each server action...
I'm gonna be real with you, we started the project with T3, which has NextAuth pre-configured, so all I had to do is get a Google OAuth token and call the Google Provider given by NextAuth
@deforestor Thinking in terms of tRPC context, though, I understand how you can get the session in context and effectively check subsequent requests for "authed" users via middleware. How is that done in server actions? Do you just manually write an "if authed" statement at the beginning on each action? That seems tedious.
I haven't done anything like that, but Next has a server side session function, so I assume you could write a wrapper, or maybe have your own way to do it with roles. But I think just doing an
if (!session) return should be fine?
But yeah, I can't answer any deeper than that. If I had to implement that, I'd just have a function that checks for the roles, but there's probably a better way, so I'll let someone else answer that
Word, that's along the lines of what I was thinking. I appreciate the help!
Just watched this and I gotta say, I agree with Jack on this one. I don't think best practices for /app have been established and I have a gut hunch that going full /app dir this early on is going to lead to a lot of refactoring.
my biggest thing is just that tools like trpc already solve these problems and dont introduce a ton of other weirdness
i also think that its very strange that server components / server actions came out and were still 'figuring out' the right way to use them. that sounds to me like the designers just didnt think that far ahead and wrote a bunch of stuff hoping it was useful. this stuff was invented, not discovered. there should be a recommended way of dealing with common problems (at least to start)
Well said.