Is it Next.js server actions the future? | Hacker News Reader

Is it Next.js server actions the future?

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.

View on HN

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.

[1] https://react.dev/reference/rsc/server-actions

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.

Next JS is a limited case by definition, for people who want server side rendering React, it offers the best DX by a wide margin

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.

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

I don't think anything involving Next.js is the future. The framework is overly complicated and very hard to self host.

Hey there, what issue are you having self-hosting Next.js?

https://nextjs.org/docs/app/building-your-application/deploy...

Middleware can only use a subset of NodeJS APIs https://github.com/vercel/next.js/discussions/46722

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.

https://nextjs.org/docs/app/building-your-application/deploy...

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 think coupling client and server is not the future

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

Reply on news.ycombinator.com