It definitely works, and we can build nice things with it, but I still think that the classic axios or tan-stack request is easier and predictable to use.
Don't mindlessly follow your framework du jour's way of handling state mutations. It's healthy to keep these isolated. I've switched from Vue to React and kept my API server as is. If you intertwine mutations deeply inside Next.js server actions you will have a hard time adapting to new requirements.
> If you intertwine ... deeply inside ... you will have a hard time adapting to new requirements
This is true of REST as well and more about code organization. Actions are often in their own directory and reusable, much like a business logic function you might call from a REST handler
Technically, they are a React thing[1], but Next has the best implementation. You'll still need classic client-server request patterns in most applications, but server components and actions mean you can skip having to maintain a REST API for a lot of basic things too. It also means users cannot access data via an (undocumented) API, which can be a pro or con as a developer, depending on perspective.
The idea of skipping maintaining a REST API is cool, but it only works (in a normal project) for some specific use cases; most of the time, having a regular endpoint in a REST API is more accessible to implement.
I am saying there are use cases for server actions and some perks, but the future is still with classic requests to endpoints, and "server actions" are more a tool than a standard.
In general, I agree,
I have two cases where mixing server and client is a good idea.
1— When you have a heavy NPM package, and you are using just a small portion of it, for example, charts libraries, if you render the HTML in the server, you can send only the HTML to the client instead of sending the entire package and waiting for a client to do the rendering.
2- SEO
Middleware is still fully supported when self-hosting. I agree that it would be helpful to have a Node.js route level middleware primitive. This primitive, for "global" middleware, intentionally has a limited runtime.
Hey Lee - I tried setting up a self hosted POC today and it looks pretty tricky:
* The shared cache loader is left to the user to implement (instead of say, just pass a Redis URL)
* The revalidate XYZ doesn't seem to work with Cloudfront etc
* The image lambda is left to the user
* The Cache-Control header isn't correct
I'd be curious to hear where you find client-side fetching libraries like Tanstack Query and friends easier. Probably the biggest downside of React Actions right now is that they're still new, and not as well adopted in the ecosystem as the established libraries like SWR / Tanstack / etc. So it's a bit harder to find example and tutorials in comparison.
13 comments
[ 2.8 ms ] story [ 44.0 ms ] threadThis is true of REST as well and more about code organization. Actions are often in their own directory and reusable, much like a business logic function you might call from a REST handler
[1] https://react.dev/reference/rsc/server-actions
https://nextjs.org/docs/app/building-your-application/deploy...
https://nextjs.org/docs/app/building-your-application/deploy...