My Professional React & Next.js course is out now! Find it here: bytegrad.com/courses/professional-react-nextjs -- this is the #1 resource to master the latest React & Next.js, my absolute best work.
Hey, you are one of the few youtubers I have subscribed and I rarely comment on videos, I just want to say that please keep uploading videos and do not be discouraged in any way... Your videos are relevant and easy to understand. Thanks!
i'd prefer react-query + trpc or react-query+server-actions(yes it's possible). I love react query. because it's reduces state management complexity and usage of useEffect , also caching and handling loading states are so easy.
If you write proper next13+ code, you don't need any state management, or useEffects in 95% of cases. Just manage state with urls. Also next does caching really well and on the server side, which is usually preferable.
@@sohhamm I did something similar a couple of months ago when I had to implement a searching and filtering feature in a project, but managing the state like this its a new mental model, I can easily see that is not a perfect solution to manage a global state. A see it as 'You might not need a global state' but not as a replacement for the current libraries we have.
Good video. I still think it depends on the use case. Let's say you're building a sports betting site, and your page needs to be live fed (normally through polling). ReactQuery (or traditional client side fetching) is your best option. RQ also refetches when you go away and come back to the site which is harder to do with Nextjs as you physically need to revalidate the route. So I think this is a great solution for when you have content that may or may not change and you don't want to make it strictly static but you'll no doubt encounter scenarios where tradicional client side requests are of good use. Regardless, well explained, was very informative!
You describe everything so clearly and include caveats as well, which is so helpful. I am new to NextJS and am seeing the benefits of Server Components. Thanks for the great video.
"If you do client side fetching [...] after a user action, for example, an infinite scroll [...] in that case, you may still want to use react query" You cannot imagine how much time I spend to make sure server actions were not appropriate for client side fetching. Holy cow. THANK YOU ♥
A tutorial on how to apply correct caching in a nextjs project would be very helpful. I struggle with that a lot which page should be static and which one should be dynamic, when to use the no_store() in queries and when to not use it, etc. Your videos are really helpful, Thanks!
Hi, I rarely comment on tech videos. Just wanted to compliment you on this. It's very clearly thought through, simply and logically demonstrated. Many thanks.
Very good video, keep up the great work! I faced this dilemma when starting my latest project, in which I intended to use RSCs. I was constantly going back and forth between Server Actions and tRPC. Ultimately I stuck with tRPC and I think there are still valid reasons to use it: 1. Built-in validation with Zod 2. Simple integration with React-Hook-Form 3. Using it in Next 14 pretty much disables full route caching of UI and of API requests by default, which is exactly how Next should behave in my opinion. That aggressive level of caching should be opt-in 4. You import one object and get access to all route definitions 5. We still get optional caching in client components 6. You can expose your API to other clients. Of course you can achieve all of those things with Server Components too. Actually they even provide even more, as you can cache full API routes, which may be useful. However, it seemed like implementing them on the level that I require would simply be inconvenient, at least in their current state. If some wrapper for Zod comes in with support for typed FormData, then I think it’ll be the good time to switch
A very good summary. I'd add to that - server actions must always be functions and cannot be grouped or namespaced, meaning you can't really organize them properly and have to resort to weird naming patterns to avoid naming conflicts.
When working on a very large project, React Query is still necessary because in large applications, data fetching isn't typically handled directly within components. Instead, server actions are utilized. Additionally, Next.js does not cache API calls made within server actions, at least not as far as I know. If I'm mistaken, please feel free to correct me
Coming from C++ and old-school web dev I love the new Next.JS. I know enough about computer science that I can really take advantage of these features and actually get thing done that work in real browsers.
react query is also cached, along with the paths. And on client you can have dynamic data, optimistic updates, etc so in a web app you'd still want to use it. On a site for sure not
9:32 we have a separate backend and I set up code generation that generates fetch functions with the correct types from the same openapi spec that generates the backend routes and types. It's quite a nice way to work. I'm not a huge fan of having nextjs do things like interact with the db etc, that's much easier to structure and test in a dedicated backend (we use nestjs).
@@Disorrder I'm sure they are both testable yeah. It's a lot cleaner IMO to have the backend as a separate REST API though. It's a lot easier to hire for and to get good quality output when it's a known technology and pattern. We can have our backend guys move over to this project and carry on working with exactly the same patterns as they would use on our angular frontend or spa react apps.
@@TanAhmed-n4p if you mean it should be the same thing as a dedicated backend, in my opinion it really isn't for larger more complex projects. App router is great, and server actions are awesome, but I prefer to use them to complement dedicated backend(s). For small apps where I just wanted to do a little crud or hit some external third party APIs I wouldn't also spin up my own backend and would just rely on app router though. Many things have tried to claim you can do away with dedicated backends (firebase, lambda, etc) for large projects, but they haven't done it yet.
Thanks for the insights. In my experience, like you said, there’re always edge cases that require trpc, but the moment I implement a trpc call to fetch the same object, I have to duplicate the code from my server component’s fetch call (input validation, prisma call, etc). Also having both server calls and trpc makes things hard to find, so I always end up implementing everything in trpc.
Next provides a way to revalidate. If you're using fetch() there's an additional attribute `next` inside where you can add {revalidate: time} Eg: fetch(...., next: { revalidate: 10 // revalidates in 10secs } )
The downsides you listed are the same reasons we moved away from this format in PHP, Rails, and so many others. Server Side Actions are acceptable if you are only ever going to use your data in that one web app. But why not spend more time creating an API layer that will unlock future growth? Separation of concerns and all that? What happened to mobile-first design principles? This isn't just UI media breakpoints. It is designing sites that can work well with limited or even no connection. In this example, a job site, I sure would want to be able to browse and save jobs on my phone.
@@gaiusjcaesar09 I used Expo. It's okay, but it's crazy Vercel just pretends mobile doesn't exist and everyone goes along with it as if mobile isn't the vast majority of users.
- How do you decide which component to use as server component versus as client component? - How much do you put in your layout versus the page in this app?
Great tutorial! However, it would be helpful if you could also cover how to invalidate the cache in Next.js. In software development, it's crucial to remember that overfetching is often preferable to underfetching for better application performance and user experience. Looking forward to more insightful content from you!
That's not always true, it really depends on where your audience is. If you're serving African countries data tends to be very expensive so other mechanisms might be of use
They way to do it is creating a custom nextjs api endpoint and importing revalidateTag from next/cache. Once you figure it out the nextjs cache is great.
In what scenario would you use a vite app over a nextjs app? It seems like nextjs is just for serverside rendering but it is hard to tell these days because it is so biased on the web. My thinking is next.js is for side projects where vite is for production apps with multiple developers. What are your thoughts?
I love the idea of server actions, especially to make database requests etc. But if I have a database with personal data, I need to protect the server action from being called. That is why I am frustrated at the moment. I am using server actions for such database queries. However, whatever I do, I cannot protect the server function from being accessed from anyone from the client side. The function is in a folder utils alongside app. The can use it from client side but so can anyone! I have looked everywhere, but I cannot seem to find how to handle that…
give a tutorial video of this project, i really like the user interface of it and would like to explore how you build this application each component part looking very neat.
The biggest problem is the part you skimmed over, the revalidatepath part. Let’s say you use server actions to mutate some data. Then you want to update some list to reflect that change. Now if you want to call revalidatePath in your server action, that function is not asynchronous. This means if you have some loading UI it will not track the status of revaluation. So what ends up happening is the data gets mutated, loading UI goes away and it still takes a second before the list gets updated. This is sort of the opposite of an optimistic update. Next.js is nice, but it has long ways to go.
18:08 You mention how we can use clients outside of Next.js with tRPC. Could you still use tRPC endpoints on a Swift app for example though? I mean if I used Next.js API routes then I can definitely use that but I'm not sure about using tRPC outside the same project. I believe this is possible within a monorepo/Turborepo if you have a Next.js app with tRPC endpoints/procedures, and then a React Native app could consume those tRPC endpoints/procedures.
You can use the tRPC API endpoints just like you would use any other API routes. However tRPC has its own conventions (instead of RESTful and/or OpenAPI conventions) on how to call functions and what format is returned. I’d probably prefer either using React Native if that’s workable in your context or abstract out the data retrieval logic from the API logic so you can create a dedicated RESTful API for mobile with API routes. For the first option I’d look into T3 Turbo as a (very good) starting point. You could also look into tRPC OpenAPI or perhaps there’s a codegen plugin for Swift. I’d shy away from the first option because the tRPC conventions are still there and it is therefore not very readable for non-tRPC users. Also in my experience the user app will deviate from the web API sooner rather than later so building out a separate API while being able to reuse a large parts of the shared data retrieval and business logic feels like a worthwhile investment even when it might not directly pay for itself in the short term.
tRPC is the same HTTP backend, there is no problem to use it from any client that can parse http and json. You just need to understand request and response formats and have a library for that. But it works seamlessly on any typescript environments. If you're using another language on client, you'd prolly better to use REST or graphQL API
I think I am missing something about tRCP (never used it) It feels like just abstraction layer on top of my app, I still need to manually update all the types or trcp can make a fetch based on my routes provided to API and figure what the type should be based on response ?
"So good! Compact and clear. Throughout the entire video, I was thinking, 'Hmm... Yeah, that's all true, but there's a big downside you didn't talk about.' And then, in the last minute, you also clarified on this 😂👍 (I'm talking about the usability in external apps). Thank you for the nice video! Until it's possible to use the full power of Next.js built-in solutions in RN and so on, I completely agree with you; there is no more reason to use React Query or TRPC."
What's your opinion of NextJS and Graphql? As now we have server components, server functions, routes, and the BE and FE are working closely, do you believe it's still makes sense the extra setups Graphql requires to get it's advantages like api documentation?
I've been toying with a similar setup, and here's my $.02: Lots of overhead when compared to a server action. The main benefit of using a separate backend is that it's not coupled so tightly to the next app. That is useful if your project ever needs a different consumer, either a different app, public API, or Mobile app.
Nice video. But how we are supposed to fetch the list, if it is based on user's search? Should it be client fetched and make the entire list as client component?
You just pass your Search (client) component inside server component and then you can use ({ searchParams }: { searchParams?: { query?: string }}) in your server component to get params and then fetch needed data based on user's search, but don't forget use debounce to circumvent overloading
if you refresh the page, it will request again right? then the concept would be same like using state management like zustand then? just need to avoid useless render page and store data temporarily on zustand?
I don't understand why using type unknown is better than specifying the typeam I because in the server action, you verify the schema and the data type. What I am not seeing well at this?
its nice that it caches but i dont like that you cant control it. I have RQ update the cache after doing Put or Delete calls to my product cart so the front end doesnt need to re-get the cart. I dont see how next would use the result of the PUT call to store for future GET calls?
But doesn't React Query do stale while revalidating while an async server component in next.js merely just caches without the revalidation part? I could be wrong
I wouldn't say caching is the sole reason someone would use React-Query for. It also abstracts common necessary variables like isLoading and Error, which needing to handle that in comparison to a hook that already does that for you with the bonus that it has caching, I don't see a reason why someone would not use it just because NextJS has caching. Unless it would conflict with NextJS caching, but would it?
Nextjs doesnt work with optimistic actions. when someone changes a fetched data and you optimisticly update it. after leaving the page.js and coming back to it. it uses the cached old version not the optimistcly updated data so then you have to refetch the whole updated data instead of caching the optimistcly updated one.
i got into problem with just using server components and server actions, everything was fine until I had to do error handling. instead of just fetching an error amd showing them, I'd probably have to wrap the components with error boundary and lose the custom error handling mechanism for each components or page withiut having to spam error boundary on every componebets. Or am I doing it wrong ? Another problem I got was having an onClick handler in a component and I cannot make it a server component anymore. I could try with URL modifications but that was not a page and was a component, so soon I had to use useEffect or react query alternatives anyway. And its not the issue, the issue is now trying to mimick similar loading and error state as you did with error boundaries. It just became a headache to me. This example is probably an easier ones and works best I agree, but when you go one level complex and complex again, it just starts to be a headache imo. Then on top of that try modals with app router and error handling or routing and data cache invalidations with server actions (invalidating a client component fetchers) does anyone have any experience or bootstrap modal of these on how to model these and create the best structure to handle them?
Do you guys even measure your crud response times in dev tools? I have implemented todo using react server actions in 5 different ways and I can't get pass 350 ms latency on a turbo simple todo, ever, meanwhile with tanstack query im below 100ms....
Okay, what if i have very huge amount of data? Is ISR still can be solution? I think next js caching good for only static data, good for landing page data but not for dashboard apps where you have more than 2000 page data. It becomes a joke to make 2000 pages on build time. So, unfortunately, we still must use client side caching like react query or redux
you can actually generate 2000 pages with ease. But yeah I agree, its mentioned in react-query, it benifits the most when you want to fetch alot of client/user sided queries. In the end developers gets the option to balence when we want to render on server/client.
Within a server component, what do you use when calling anything other than fetch to an http endpoint? Does the server side data-cache only work for fetch calls? What tool or method would you use to make a direct sql call to get the information you need for a server component?
What the server caches is the jsx component that it's returned. Not the fetch call, it caches the data that is used in the jsx boiler plate. So you can use any orm, not just prisma. There are others orm that allow direct sql call.
@@vahankaramyan7561 yes it has. but it has both, nextjs have different types of caching mechanism and it'll try to use the best mechanism for the specific situation.
@@vahankaramyan7561yeah it caches both components and data, it also caches routes on the front-end. Can cause headaches invalidating the cache but once you get it it's pretty nice. Any fetch requests will be cached and you can invalidate them via tags so any dependent components won't hit the cache.
so for simple apps next js is good. but when app is growing nextjs caching is not that good enough and you have scalling issues with amount of API growing.. No nextjs in my life for sure
the goal using trpc instead server actions is the option to set private and public routes, for example in t3(theo stack) nextauth is integrated greatly and you can use this trpc mutation with loged users
You can even say it adds an additional layer of security within your app. Most of the time you will not work with devs specialized on Next JS and by providing an extra layer like TRPC, on top of the current benefits, you protect your application from accidentally calling server only functions in the client. TRPC is not mandatory, you can always add a parser between your functions, or follow the NextJS best practices, but a well set up TRPC project actually enforces the good practices
Comment unrelated. I love this comment so much which I ready earlier in some other video. Someone made this comment which was going in my mind too, he said "I believe 100% whatever this guy says" and I cannot agree enough 🤣 I believe in Wesley supremacy 🛐
While I completely agree that NextJS tools have come a long way, there are still many things that it can't do better than these tools. For a simple dashboard, obviously framework native tools easier and cleaner, but when your product needs cache invalidation or route groups requiring API tokens, React Query and tRPC does it better. There isn't a feeling more daunting than realizing that your janky custom workarounds are standard in a package that simplifies your workflow.
Alright plz give a reply for this scenario. You are using custom server and you need to validate the user to fetch api on sc by attaching token on header for authorization. How do you validate user in client and server components. Don't want to use any pkg like nextauth.
Honestly, it's like everyone's ditching Next.js for Vite these days. Next.js kinda tries to be a jack-of-all-trades, bundling everything together-it's like they went overboard with the whole abstraction thing.
I enjoyed watching this video but chasing the latest shiny thing is not sustainable. If you want to cache calls, just set the appropriate header. If you want to return more records in one call, implement paging. I believe a better approach is to use the platform and learn the concepts, instead of installing yet another dependency and refactoring a whole project. As for server side rendering, I don't imagine it'll ever be competitive as an enterprise solution. We've been there and tried that.
My Professional React & Next.js course is out now! Find it here: bytegrad.com/courses/professional-react-nextjs -- this is the #1 resource to master the latest React & Next.js, my absolute best work.
I have learned this course, it is the best best best best course about react and next . very clear, useful, thanks so much
Hey, you are one of the few youtubers I have subscribed and I rarely comment on videos, I just want to say that please keep uploading videos and do not be discouraged in any way... Your videos are relevant and easy to understand. Thanks!
Thanks, appreciate it!
+1 - You have an amazing way of explaining things. Got me started with full-stack next projects
surprised its not clickbait and actually teaching. thanks for the info
i'd prefer react-query + trpc or react-query+server-actions(yes it's possible). I love react query. because it's reduces state management complexity and usage of useEffect , also caching and handling loading states are so easy.
If you write proper next13+ code, you don't need any state management, or useEffects in 95% of cases. Just manage state with urls. Also next does caching really well and on the server side, which is usually preferable.
@@samuelwittlinger7790 what do you mean by handling the state with urls?
@@samuelwittlinger7790 I just saw a video about it, forget it . I've used that approach before but for searching - filtering
try to use URLs for state management, this problem will be solved
@@sohhamm I did something similar a couple of months ago when I had to implement a searching and filtering feature in a project, but managing the state like this its a new mental model, I can easily see that is not a perfect solution to manage a global state. A see it as 'You might not need a global state' but not as a replacement for the current libraries we have.
Good video. I still think it depends on the use case. Let's say you're building a sports betting site, and your page needs to be live fed (normally through polling). ReactQuery (or traditional client side fetching) is your best option. RQ also refetches when you go away and come back to the site which is harder to do with Nextjs as you physically need to revalidate the route. So I think this is a great solution for when you have content that may or may not change and you don't want to make it strictly static but you'll no doubt encounter scenarios where tradicional client side requests are of good use. Regardless, well explained, was very informative!
You describe everything so clearly and include caveats as well, which is so helpful. I am new to NextJS and am seeing the benefits of Server Components. Thanks for the great video.
Glad it was helpful!
"If you do client side fetching [...] after a user action, for example, an infinite scroll [...] in that case, you may still want to use react query"
You cannot imagine how much time I spend to make sure server actions were not appropriate for client side fetching.
Holy cow.
THANK YOU ♥
A tutorial on how to apply correct caching in a nextjs project would be very helpful. I struggle with that a lot which page should be static and which one should be dynamic, when to use the no_store() in queries and when to not use it, etc. Your videos are really helpful, Thanks!
Hi, I rarely comment on tech videos. Just wanted to compliment you on this. It's very clearly thought through, simply and logically demonstrated. Many thanks.
Very good video, keep up the great work!
I faced this dilemma when starting my latest project, in which I intended to use RSCs. I was constantly going back and forth between Server Actions and tRPC. Ultimately I stuck with tRPC and I think there are still valid reasons to use it:
1. Built-in validation with Zod
2. Simple integration with React-Hook-Form
3. Using it in Next 14 pretty much disables full route caching of UI and of API requests by default, which is exactly how Next should behave in my opinion. That aggressive level of caching should be opt-in
4. You import one object and get access to all route definitions
5. We still get optional caching in client components
6. You can expose your API to other clients.
Of course you can achieve all of those things with Server Components too. Actually they even provide even more, as you can cache full API routes, which may be useful. However, it seemed like implementing them on the level that I require would simply be inconvenient, at least in their current state.
If some wrapper for Zod comes in with support for typed FormData, then I think it’ll be the good time to switch
A very good summary. I'd add to that - server actions must always be functions and cannot be grouped or namespaced, meaning you can't really organize them properly and have to resort to weird naming patterns to avoid naming conflicts.
Wow, that's awesome!
Ty, I didn't really pay attention that these were cached
When working on a very large project, React Query is still necessary because in large applications, data fetching isn't typically handled directly within components. Instead, server actions are utilized. Additionally, Next.js does not cache API calls made within server actions, at least not as far as I know. If I'm mistaken, please feel free to correct me
Man, you covered so many concepts with practical, real-life examples, Thanks for this 🙏
really cool! nextjs fetching is just missing a devtools equivalent for easy debugging
Coming from C++ and old-school web dev I love the new Next.JS. I know enough about computer science that I can really take advantage of these features and actually get thing done that work in real browsers.
react query is also cached, along with the paths. And on client you can have dynamic data, optimistic updates, etc so in a web app you'd still want to use it. On a site for sure not
9:32 we have a separate backend and I set up code generation that generates fetch functions with the correct types from the same openapi spec that generates the backend routes and types. It's quite a nice way to work.
I'm not a huge fan of having nextjs do things like interact with the db etc, that's much easier to structure and test in a dedicated backend (we use nestjs).
we do the exact same thing!
I think you can test both trpc and next backend easily as well as separate REST API
@@Disorrder I'm sure they are both testable yeah. It's a lot cleaner IMO to have the backend as a separate REST API though. It's a lot easier to hire for and to get good quality output when it's a known technology and pattern. We can have our backend guys move over to this project and carry on working with exactly the same patterns as they would use on our angular frontend or spa react apps.
@@buzz1ebee do you use next.js app router? it should be the same thing surely?
@@TanAhmed-n4p if you mean it should be the same thing as a dedicated backend, in my opinion it really isn't for larger more complex projects.
App router is great, and server actions are awesome, but I prefer to use them to complement dedicated backend(s). For small apps where I just wanted to do a little crud or hit some external third party APIs I wouldn't also spin up my own backend and would just rely on app router though.
Many things have tried to claim you can do away with dedicated backends (firebase, lambda, etc) for large projects, but they haven't done it yet.
Thanks for the insights. In my experience, like you said, there’re always edge cases that require trpc, but the moment I implement a trpc call to fetch the same object, I have to duplicate the code from my server component’s fetch call (input validation, prisma call, etc). Also having both server calls and trpc makes things hard to find, so I always end up implementing everything in trpc.
How could you revalidate the NextJs cache? Automatic caching is good but we should have ability to manage the cache life time also
Next provides a way to revalidate. If you're using fetch() there's an additional attribute `next` inside where you can add {revalidate: time}
Eg: fetch(....,
next: {
revalidate: 10 // revalidates in 10secs
}
)
literally revalidateTag("yourroute") and in client components could use router.refresh()
The downsides you listed are the same reasons we moved away from this format in PHP, Rails, and so many others.
Server Side Actions are acceptable if you are only ever going to use your data in that one web app.
But why not spend more time creating an API layer that will unlock future growth? Separation of concerns and all that?
What happened to mobile-first design principles? This isn't just UI media breakpoints. It is designing sites that can work well with limited or even no connection.
In this example, a job site, I sure would want to be able to browse and save jobs on my phone.
I came in as a skeptic but you convinced me to give it a try
Good video. Sucks Vercel hates React Native so much.
Expo brother. Expo. It's not so bad nowadays.
@@gaiusjcaesar09 I used Expo. It's okay, but it's crazy Vercel just pretends mobile doesn't exist and everyone goes along with it as if mobile isn't the vast majority of users.
- How do you decide which component to use as server component versus as client component?
- How much do you put in your layout versus the page in this app?
put simply you don't use client components, real time data or anything of that sort.
Hope to see a video in my recommended named "Why I don't use React anymore" someday :)
Ok but how do you disable caching with nextjs? What if I DONT want to cache things. Maybe its something that updates a lot
just you can't, nextjs does not allow this
check next js 15 release
@@johannes.evol. yup
the best nextjs vids! thanks so much for this man
Great tutorial! However, it would be helpful if you could also cover how to invalidate the cache in Next.js. In software development, it's crucial to remember that overfetching is often preferable to underfetching for better application performance and user experience. Looking forward to more insightful content from you!
That's not always true, it really depends on where your audience is. If you're serving African countries data tends to be very expensive so other mechanisms might be of use
They way to do it is creating a custom nextjs api endpoint and importing revalidateTag from next/cache. Once you figure it out the nextjs cache is great.
Ror a long period, I didn't see a really interresting video! thanks a lot! i subscribe and activate notifs!
The t3 stack make all this perfect.
I agree. tRPC+react-query can live on RSC. Only when to invalidate is using "router.refresh()", not "await utils.dotdotdot.invalidate()"
I've just bought your courses thanks to this video. This video is very informative.
Awesome, enjoy!
What a great video bro. Making things clear and understanable
In what scenario would you use a vite app over a nextjs app? It seems like nextjs is just for serverside rendering but it is hard to tell these days because it is so biased on the web. My thinking is next.js is for side projects where vite is for production apps with multiple developers. What are your thoughts?
very great explanation! thanks!!
really appreciate these indepth videos
Great content!! new insight achieved, thank you !
Have you checked out next safe action package - would make a great video.
Yeah looks great, surprised it hasn't become more popular yet
I love the idea of server actions, especially to make database requests etc. But if I have a database with personal data, I need to protect the server action from being called.
That is why I am frustrated at the moment. I am using server actions for such database queries. However, whatever I do, I cannot protect the server function from being accessed from anyone from the client side. The function is in a folder utils alongside app. The can use it from client side but so can anyone! I have looked everywhere, but I cannot seem to find how to handle that…
give a tutorial video of this project, i really like the user interface of it and would like to explore how you build this application each component part looking very neat.
High quality video, thanks!
The biggest problem is the part you skimmed over, the revalidatepath part. Let’s say you use server actions to mutate some data. Then you want to update some list to reflect that change. Now if you want to call revalidatePath in your server action, that function is not asynchronous. This means if you have some loading UI it will not track the status of revaluation. So what ends up happening is the data gets mutated, loading UI goes away and it still takes a second before the list gets updated. This is sort of the opposite of an optimistic update. Next.js is nice, but it has long ways to go.
Can someone tell me how server actions work? A HTTP request is still made to the backend, right?
Great video !
thanks. now i know server action. i never used it before.
18:08 You mention how we can use clients outside of Next.js with tRPC. Could you still use tRPC endpoints on a Swift app for example though? I mean if I used Next.js API routes then I can definitely use that but I'm not sure about using tRPC outside the same project.
I believe this is possible within a monorepo/Turborepo if you have a Next.js app with tRPC endpoints/procedures, and then a React Native app could consume those tRPC endpoints/procedures.
There is a lib called trpc-openapi which creates REST endpoints for you trpc procedures
You can use the tRPC API endpoints just like you would use any other API routes. However tRPC has its own conventions (instead of RESTful and/or OpenAPI conventions) on how to call functions and what format is returned.
I’d probably prefer either using React Native if that’s workable in your context or abstract out the data retrieval logic from the API logic so you can create a dedicated RESTful API for mobile with API routes. For the first option I’d look into T3 Turbo as a (very good) starting point.
You could also look into tRPC OpenAPI or perhaps there’s a codegen plugin for Swift. I’d shy away from the first option because the tRPC conventions are still there and it is therefore not very readable for non-tRPC users. Also in my experience the user app will deviate from the web API sooner rather than later so building out a separate API while being able to reuse a large parts of the shared data retrieval and business logic feels like a worthwhile investment even when it might not directly pay for itself in the short term.
tRPC is the same HTTP backend, there is no problem to use it from any client that can parse http and json. You just need to understand request and response formats and have a library for that. But it works seamlessly on any typescript environments. If you're using another language on client, you'd prolly better to use REST or graphQL API
I think I am missing something about tRCP (never used it) It feels like just abstraction layer on top of my app, I still need to manually update all the types or trcp can make a fetch based on my routes provided to API and figure what the type should be based on response ?
Thank you so much for your greate content ♥ I have one question please, what do you think about using GraphQl instead of prisma ORM ?
"So good! Compact and clear. Throughout the entire video, I was thinking, 'Hmm... Yeah, that's all true, but there's a big downside you didn't talk about.' And then, in the last minute, you also clarified on this 😂👍 (I'm talking about the usability in external apps). Thank you for the nice video! Until it's possible to use the full power of Next.js built-in solutions in RN and so on, I completely agree with you; there is no more reason to use React Query or TRPC."
What's your opinion of NextJS and Graphql? As now we have server components, server functions, routes, and the BE and FE are working closely, do you believe it's still makes sense the extra setups Graphql requires to get it's advantages like api documentation?
I've been toying with a similar setup, and here's my $.02: Lots of overhead when compared to a server action. The main benefit of using a separate backend is that it's not coupled so tightly to the next app. That is useful if your project ever needs a different consumer, either a different app, public API, or Mobile app.
I believe graphql is not needed now. Server got its role back.
So helpful, thanks! I really like your explanations!
Do you mean V14 of next js and app router? I find the need for react-query using v12, quite a bit.
Hey is the code available for testing?
All 3 approaches?
Nice video. But how we are supposed to fetch the list, if it is based on user's search? Should it be client fetched and make the entire list as client component?
You just pass your Search (client) component inside server component and then you can use ({ searchParams }: { searchParams?: { query?: string }}) in your server component to get params and then fetch needed data based on user's search, but don't forget use debounce to circumvent overloading
if you refresh the page, it will request again right?
then the concept would be same like using state management like zustand then? just need to avoid useless render page and store data temporarily on zustand?
amazing! Thanks :)
Really very useful information and good guidance love from India ❤❤
After watching this i appreciate how good laravel is now nextjs is following that methodology
I don't understand why using type unknown is better than specifying the typeam I because in the server action, you verify the schema and the data type. What I am not seeing well at this?
Good day, What is your approach to react query as Caching default behaviour is changing in nextjs 15? Wishes 👍
BTW what to pass to a Suspense key if it should get an array or object? To check if it has been changed?
its nice that it caches but i dont like that you cant control it.
I have RQ update the cache after doing Put or Delete calls to my product cart so the front end doesnt need to re-get the cart.
I dont see how next would use the result of the PUT call to store for future GET calls?
But doesn't React Query do stale while revalidating while an async server component in next.js merely just caches without the revalidation part? I could be wrong
Kinda reminds me of what Meteor was! But more up to date/standards
I wouldn't say caching is the sole reason someone would use React-Query for. It also abstracts common necessary variables like isLoading and Error, which needing to handle that in comparison to a hook that already does that for you with the bonus that it has caching, I don't see a reason why someone would not use it just because NextJS has caching. Unless it would conflict with NextJS caching, but would it?
Can you guide me on how to create a nextjs component library and shuffle their code separately, just like the vite library
How do you await fetch in a client component? Can you just make an async client component?
Nextjs doesnt work with optimistic actions. when someone changes a fetched data and you optimisticly update it. after leaving the page.js and coming back to it. it uses the cached old version not the optimistcly updated data so then you have to refetch the whole updated data instead of caching the optimistcly updated one.
Is there another way for handling fetching on the server side without using fetch? as its syntax is well, not my favorite.
i got into problem with just using server components and server actions, everything was fine until I had to do error handling. instead of just fetching an error amd showing them, I'd probably have to wrap the components with error boundary and lose the custom error handling mechanism for each components or page withiut having to spam error boundary on every componebets. Or am I doing it wrong ?
Another problem I got was having an onClick handler in a component and I cannot make it a server component anymore. I could try with URL modifications but that was not a page and was a component, so soon I had to use useEffect or react query alternatives anyway. And its not the issue, the issue is now trying to mimick similar loading and error state as you did with error boundaries.
It just became a headache to me.
This example is probably an easier ones and works best I agree, but when you go one level complex and complex again, it just starts to be a headache imo.
Then on top of that try modals with app router and error handling or routing and data cache invalidations with server actions (invalidating a client component fetchers)
does anyone have any experience or bootstrap modal of these on how to model these and create the best structure to handle them?
This is just if you’re using server functions, yes? So if I’m still on Nextjs 13, I should stick with React Query?
Do you guys even measure your crud response times in dev tools? I have implemented todo using react server actions in 5 different ways and I can't get pass 350 ms latency on a turbo simple todo, ever, meanwhile with tanstack query im below 100ms....
very helpful video, thanks
Will there be another video? ... Why use SvelteKit? :D
Okay, what if i have very huge amount of data? Is ISR still can be solution? I think next js caching good for only static data, good for landing page data but not for dashboard apps where you have more than 2000 page data. It becomes a joke to make 2000 pages on build time. So, unfortunately, we still must use client side caching like react query or redux
If you have a lot of data, using client side caching is ok, dropping next.js is even better idea - because it will make stuff worse.
you can actually generate 2000 pages with ease. But yeah I agree, its mentioned in react-query, it benifits the most when you want to fetch alot of client/user sided queries. In the end developers gets the option to balence when we want to render on server/client.
Within a server component, what do you use when calling anything other than fetch to an http endpoint? Does the server side data-cache only work for fetch calls? What tool or method would you use to make a direct sql call to get the information you need for a server component?
What the server caches is the jsx component that it's returned. Not the fetch call, it caches the data that is used in the jsx boiler plate. So you can use any orm, not just prisma. There are others orm that allow direct sql call.
@@EduarteBDO as I know Nextjs has a data cache that stores fetched data, correct me if I'm wront
@@vahankaramyan7561 yes it has. but it has both, nextjs have different types of caching mechanism and it'll try to use the best mechanism for the specific situation.
@@vahankaramyan7561yeah it caches both components and data, it also caches routes on the front-end. Can cause headaches invalidating the cache but once you get it it's pretty nice.
Any fetch requests will be cached and you can invalidate them via tags so any dependent components won't hit the cache.
What is a React “feat or feet” app? Mentioned at 4:30 please. Thanks
"Vite"
quality content
so for simple apps next js is good. but when app is growing nextjs caching is not that good enough and you have scalling issues with amount of API growing.. No nextjs in my life for sure
the goal using trpc instead server actions is the option to set private and public routes, for example in t3(theo stack) nextauth is integrated greatly and you can use this trpc mutation with loged users
You can even say it adds an additional layer of security within your app. Most of the time you will not work with devs specialized on Next JS and by providing an extra layer like TRPC, on top of the current benefits, you protect your application from accidentally calling server only functions in the client. TRPC is not mandatory, you can always add a parser between your functions, or follow the NextJS best practices, but a well set up TRPC project actually enforces the good practices
Honestly I hate fetch, can you make some video about axios in next js on both client and server?
Awesome content
fantastic
What about next safe action with server actions
It would be nice if react router loaders were compared too
I see that react query is useful in react native projects.
how would you combine nextjs with a .net backend api?
Comment unrelated.
I love this comment so much which I ready earlier in some other video. Someone made this comment which was going in my mind too, he said "I believe 100% whatever this guy says" and I cannot agree enough 🤣
I believe in Wesley supremacy 🛐
Agreed, they are not React/Next, like I wont like nestjs instead of node, they are wraps, not authentic product.
Quality content.
Raact Query is useful beyonf fetching data. It's allbout about asynchronous operations on the State.
please update the video title by adding "in nextjs"
While I completely agree that NextJS tools have come a long way, there are still many things that it can't do better than these tools. For a simple dashboard, obviously framework native tools easier and cleaner, but when your product needs cache invalidation or route groups requiring API tokens, React Query and tRPC does it better. There isn't a feeling more daunting than realizing that your janky custom workarounds are standard in a package that simplifies your workflow.
🔥🔥🔥
Not really sure if the change was for the good of bad, only time will tell...
Alright plz give a reply for this scenario. You are using custom server and you need to validate the user to fetch api on sc by attaching token on header for authorization. How do you validate user in client and server components. Don't want to use any pkg like nextauth.
You can get request headers using function "headers" or cookies from next/headers in server components, then make a call to the server.
@@filipfiser1045 if it's the case of token storing in localstorage how to do that?
you can try with axios interceptors mate, maybe you like it
@@naylord5 yup thats how im going
thank you)
Honestly, it's like everyone's ditching Next.js for Vite these days. Next.js kinda tries to be a jack-of-all-trades, bundling everything together-it's like they went overboard with the whole abstraction thing.
how to combine ssr with global state
I enjoyed watching this video but chasing the latest shiny thing is not sustainable. If you want to cache calls, just set the appropriate header. If you want to return more records in one call, implement paging. I believe a better approach is to use the platform and learn the concepts, instead of installing yet another dependency and refactoring a whole project. As for server side rendering, I don't imagine it'll ever be competitive as an enterprise solution. We've been there and tried that.
It’s a pitfall indeed, it seems i missed key in my Suspenses