The ONE Next.js Feature I Won't Use
Vložit
- čas přidán 25. 11. 2023
- Server Actions are most of all just super convenient - at least in their most basic usage. It's great to have them as an option, though I think most of the time, you're better off using something else.
-- my links
Discord: / discord
GitHub: github.com/joschan21 - Věda a technologie
I constantly hear people (read: Theo/T3) talking about how nice it is to not have to think about where the boundary between client and server is and I just cannot agree. It’s about the only real boundary we still have to deal with in web development and blurring the line only hides the boundary until you have to debug some random bug in the form. Every time I’ve played server actions I just find myself thinking “but tRPC did this better!”
That's why php was invented because of that very reason. I think we are getting back from the start 😅
Yes I agree , but u can build upon the primitive give by next . tRPC is unnecessary bloated , I build a type safe interface between sever action which was less complex to execute and set up.U need a boundary between sever and client , I agree , but the boundary should feel very light . This was RSC and sever actions
Your videos are absolutely fantastic! I was wondering if you could create a video specifically diving into the intricacies of designing API patterns for production. Your effort is truly appreciated! Thanks a bunch!
Totally agree!
I’m also not sold into server actions yet.
There are some specific use cases where I use it, but in most cases I’m still avoiding them.
Yea you nailed it here with all the points you mentioned. I guess the biggest fan of server actions is Vercel 😆 Although it's kinda cool to quickly build something.
This is awesome, I was literally working on server actions and thought to myself, "Hmm, I wonder if Josh has a video on this?" So, I pull up CZcams and what do you know, I see 'Posted 2 hours ago' on my feed. Great content, keep it up!
Really practical take on the subject, without getting hyped up. Appreciate it!
I'm using server actions at the moment, namely to create small wrappers around my tRPC routes to obfuscate the actual backend API location(s) (maybe multiple) and prevent any prying within network requests. They're really quite handy for that!
curious use case, are you building like a highly secure product ?
@@akshatsethi6384 not really but the API itself isn't public except for this apps consumption so no need to expose it's data sources. Just good security practice imo, akin to keeping a pg/mysql connection string hidden away to prevent unwanted attempts of attacks
But what’s a point in this? Sounds like overkill
i don't consider server actions to be type-safe because the form data doesn't contain type information. with tRPC + zod you're always aware of the requirements, the data that gets passed, and the returned values.
Thank you for just getting to the point. Very underrated nowadays
Deine Videos sind echt gut und helfen mir sehr. Weiter so!
Another issue is that if we need to create a mobile application, there would be no defined routes and api's which would have to be recoded with the entire logic again. I think with the server actions, its something that we have to be really mindful of a lot of questions and really know the project exactly to actually use this. IMO, the convenience of Server Actions comes at a lot of cost. Atleast for now.
extract the main logic in a reuseable function and call it in server action and api endpoint
@@ahmedivy IMO still not as clean as I would prefer. Imaging you would have to create the API later, you would have to go through the code, refactor it to be called from the single function and then create the single function, ensure everything is tested ( provided you have written tests etc )
@@sankalpsingha if you know that your logic is going to complex, you should have to create a data access layer from start, as nextjs released a blog some weeks ago explaining that. If you have a proper data access layer it would be easy to just call the function in api and server action
@@ahmedivytrue. I think there should be highlight on that point as well when everyone is speaking about server actions.
For loading state and error can we not use react query with server actions to get the same TRPC kind behaviour
Great info Josh 🎉😊
I built my first portfolio website without any backend stuff, just animated pretty looking pages at first. Then, I wanted to implement a guest book that visitors can login with Google and leave a message that I will store in the mongodb but didn't wanna prepare all backend stuff even if in the next/APIs. That's the only case this server actions worked for me on my first try. I just created 2 more components with a server function and that's it. However, I'm building a Turkish dictionary website using tRPC that helps me to write typesafe and quick backend for my frontend. As you've shown in the video, the useMutation hook lets me to handle loading and error states easily. So, can't agree with you more in this video 😅
You’re right. Btw what if you want to build more advanced forms with complicated validation using react hook form? It forces you to build whole form using „use client”
You can still use server actions in client components but you need to put the server action function in a separate file
The whole page doesn't need to be "use client". It can stay server-side. You can use useFormState in your server action in your form. And only a form with a button is a seperate client component.
But I agree, I am not a fan of creating a separate client component files each time.
Yes, I am trying to use server action and useQuery in the client component to replace trpc. In theory, this is possible and provides native type safety, but I need to add a lot of wrappers, hydration, etc. And most importantly, I cannot find a reasonable way to handle server action errors because they are server-side errors.
Server actions are not what I thought. Last month I decided to move a project I work on to server actions from trpc. I used similar methods to trpc structure and I’ve been able to call these typesafe methods from both client and server components and middleware. Everything worked fine “most of the time” except early call errors, or confusion between client, server, and also middleware. Finally I came to conclusion that building an api with server actions is far from ideal. because abstractions and “magic” get cumbersome eventually. Like you said, that line between client and server disolves at some point, you are not even sure why some functions work and some don’t. For example I still don’t know if functions placed in “use server” file should work in layout.tsx or server components. The thing is it works but I don’t know if it’s intended behavior.
Now I brought back trpc and using server actions for httponly cookies or similar stuff where server actions shine. Even server actions would have more capabilities in future, I think keeping it minimal is good for you sanity.
server components can be called in client components but only if they are passed as children or as props, so you can't just import them.
Example:
❌
import ServerComponent from ...
export function Layout () {
return
}
✅
export function Layout({children}){
return {children}
}
export function Page(){
return
What a great reflexion . thanks for sharing
@@automioai many devs, even experienced ones, have similar misunderstandings when it comes to Context hooks too. They think it'll make every component down the tree trigger a rerender. But actually as long as you pass via children, it won't
i really like server actions for 2 reasons:
First: i normally request my data from a different backend that is connected to my database. the client will neither see the adress of that server nor has anything to do with it, which gives an additional layer of security.
Second: I sometimes do some computation steps on my nextjs backend. for example organizing the retrieved json in different chunks to send multiple request to multiple endpoints. using server actions means the client does not need to compute anything itself and can concentrate on rendering the UI. Also i normally do some computation after receiving the information from the other backend, like error handling. these computations steps are not done on the client but rather on a server with way better performance.
just because the server address isn't in your client code, doesn't make it more secure...somewhere the front end needs to know where to connect to
@@alastairtheduke the frontent connects to the nextjs backend via server action and the server action itself connects to my golang backend. So the frontend does not know the golang backend.
Yup, I went through the same form action debugging / figuring out how next decided to do this lol
Yeah, this is definitely going to spark a huge debate. As of now, I’m hesitant to use as well since I want total control of the URI. When things go wrong, we all look at network tab and I’m not sure seeing all these magic urls would help in debugging. Maybe someone will figure out a clean way of using them.
I'm so confused. I started learning web development 2 months ago and I am puzzled as to the path I should take for fetching and handling data!? I'm thinking server actions with tanstack react query.. Could anyone advise?
Something I don't understand is how you can know that this will function correctly across rolling deployments. What does the network request for this even look like? How can it stay consistent in the second deploy?
Totally agree!. Fantastic Video!
the server side part of server side rendering isn't really meant to replace the backend.
I actually just use server actions to call my actual backend, I just hate useEffects
server action with trpc is nice. you ship less js and have data access layer. i just hate that i need to convert from formdata to object
As you mentioned if you are just building a web app and you don't need to worry about creating APIs server actions are good.
Pretty much. I tried creating a service that hits server actions in a separate file. The calls are quick and they render very well. The whole point was to make it easy to use and manageable. I had run into some odd flow issues with the code that an API would have handled much better.
It makes me wonder what Vercel is on about with all this. Colocating front and backend code plays with the mind.
I'm gonna stick with trpc I think. I just spent too long learning it to give it up now
One thing I have to disagree: if you use Server Actions inside of the React Query, then all loading states / refetching etc. are handled by default.
The whole works magic and I never had any problems with it. Don't really understand why people complain about it that much.
Fast, small MVP💥 totally agree.
Even if in company we don't need to learn trpc, because as you said You need to know about api architecture. and trpc sucks if you want to share your api outside your app
Please make video on "user agent" in next js app directory I want to detect user device type and render component based on user device type let I have to components one for mobile device and second for desktop device so what i want i want to detect user device on server side and render component based on user device type so to I do that in next js 13 please make video on this topic
or . . . just use remix.
I tried it, still not work well. I still use react-query instead
I really like server actions. Love to not have to create API endpoints for my tasks
I love server actions anyway 😍
Good one👍🏻
TRPC is just so awesome
Its called enforcing conventions and style guides.
With proper code reviews there is little room to get confused.
I do agree that if you are a new dev then yeah...focus on more common tech.
thank god for remix
And getting loading states are very easy in Remix then this kind of getting loading states in nextjs
server action is just good enough for a POC, more like lab product only.
I do not agree , trpc is an unnecessary abstraction , I written a code that does similar as trpc in sever actions using few lines and lower bundle size . My teams like it more as it fit there own needs , building on primitive enable to build custom experience which no package can compete with .
Seriously this is server actions?
Remix is doing this since 2 years
but remix isn't a vc backed company that invests in hype and takes the whole framework to a venderlock point. so this one is a lot shinier.
Trust me real companies just don't use app directory they still use PAGES even if they start a brand new project
Your loss. I'm using them and it's great.
Can we get a rails tutorial sometimes. Nextjs ain't getting us jobs josh.
I prefer less magic. I want to be able to see the parts of the machine instead of just relying on the blackbox that just does things.
Until you start drowning in those parts of the machine...
While JS Mastery encourage this, you discourage,... I think there's been a war between you and him
ithink they are trying to get attention from php users or other serverside web language to use nextjs, in the end developers will transform their app into rest api for better devwlopment cycle later
❤❤
We got what we dont need 💀☠️....
For me it's all about moving all the potential security risks to the server. :)
What risks?
Frontend getting weirder and weirder
next.js is backend framework and forever was AFAIK
I'm literally watching this as I write a server action for the company I work for.
I have to argue with the approach your going for in this video... your tackling the "why are you learning web dev, to get a job?", a lot of us learn web dev, to do better web dev either at home or at work, the approach of "I'm learning Next.js just so I can be hired" is kinda meh, especially the fact that most companies don't check you on higher level frameworks like Next on more focusing on seeing if you understand principles and important concepts of the web.
second of all, you should understand why we have server actions, it didn't came to replace doing traditional API's, it came to replace the hustle of building a full internal API service, when you have one client, e.g. your website. and you want to keep the logic encapsulated and not exposed, in addition it gives you type safety all the way.
lastly, you push heavily trpc in other videos, even though its contradicting with the "learn proper api design" your going for, because trpc does nothing in the traditional way...
I like your content very much, but you have to undersrtand that each tech or framework just supposed to be a tool to tackle different problems, and posting a video that pushes people away from server actions just because the line of server and client seems blurry to you seems kinda irresponsible...
also when React came out it had a lot of backlash because it did things differently and people were not used to it, and look at React now...
same thing about the new Next approach which tackles the native API and moves a lot of behaviors' to the server.
So, you recommend to use like NestJS for the backend (so we have better api and can expose it) and keep NextJS with server actions for the frontend ?
@@ghostlexly NextJS by definition is a backend framework, so no this is not what I recommend.
I recommend to move as much logic to the server, and if it's easy/fast for your infra to do it via server actions so use them.
Hello @Joshtriedcoding, I am a business owner and would love to work with you on one of my projects. I have sent you an Email, would be happy to hear from you.