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!
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.
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!
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.
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!
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 } )
"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 ♥
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
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.
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
excelent video, like all of yours. keep going!. Now with nextjs15/react19 new cache system, react query ll shine again? or the new unstable_cache/cache will do the magic?
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
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.
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 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 ?
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…
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?
@@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.
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
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.
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?
"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."
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?
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.
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 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?
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.
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.
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
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.
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?
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....
- 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?
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.
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.
@@filipfiser1045 But One time I used redirect in form action but it directly redirect me without clicking on button. Can you provided me a source please. Thanks in advance 😅
Can anyone tell I am using a state management tool like redux and I have a token store in my local storage. Can I get my user details on server side in any way and then can update my states
The server side won't be able to access the client side local storage I don't think, so you'll likely need to either pass whatever data you need from local storage back to next, or better implement some storage that the server can access also (i.e. cookies). If you're only interested in Auth state and are using oauth then next-auth might be ok, I implemented http only cookies myself and just had any client components make a call to get any locally required info.
This is part of the streaming api. It's still experimental. But this is not so important, the important thing is that you want to track the state on the client and initiate a request from the client, which means you must manage the cache and state of requests on the client. This means that you are using React-Query. This means that you have 2 managed caching layers. No options. For static sites, you almost never need to track requests and states; the maximum network interactivity on such sites is a link or a static form, apparently the author makes only such sites.
Moreover, for static sites like a blog, you want to compile the html and put it on a CDN, that is, you do not need a running application per request. You need to make a couple of endpoints for lambda functions or even connect it as an external service without your own backend. So server actions will eat your money by forcing you to use expensive infrastructure. So for many applications this is a very difficult architectural choice.
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
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
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!
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!
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.
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!
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.
Man, you covered so many concepts with practical, real-life examples, Thanks for this 🙏
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()
Ror a long period, I didn't see a really interresting video! thanks a lot! i subscribe and activate notifs!
"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 ♥
really cool! nextjs fetching is just missing a devtools equivalent for easy debugging
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
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
I've just bought your courses thanks to this video. This video is very informative.
Awesome, enjoy!
the best nextjs vids! thanks so much for this man
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.
What a great video bro. Making things clear and understanable
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
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
Can someone tell me how server actions work? A HTTP request is still made to the backend, right?
How do you await fetch in a client component? Can you just make an async client component?
Have you checked out next safe action package - would make a great video.
Yeah looks great, surprised it hasn't become more popular yet
excelent video, like all of yours. keep going!. Now with nextjs15/react19 new cache system, react query ll shine again? or the new unstable_cache/cache will do the magic?
Thanks! We’ll see
Great content!! new insight achieved, thank you !
Can you guide me on how to create a nextjs component library and shuffle their code separately, just like the vite library
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
Great video !
What is a React “feat or feet” app? Mentioned at 4:30 please. Thanks
"Vite"
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.
High quality video, thanks!
Good day, What is your approach to react query as Caching default behaviour is changing in nextjs 15? Wishes 👍
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.
Hey is the code available for testing?
All 3 approaches?
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 ?
really appreciate these indepth videos
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…
Do you mean V14 of next js and app router? I find the need for react-query using v12, quite a bit.
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?
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.
I came in as a skeptic but you convinced me to give it a try
very great explanation! thanks!!
Thank you so much for your greate content ♥ I have one question please, what do you think about using GraphQl instead of prisma ORM ?
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
BTW what to pass to a Suspense key if it should get an array or object? To check if it has been changed?
Is there another way for handling fetching on the server side without using fetch? as its syntax is well, not my favorite.
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.
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?
Really very useful information and good guidance love from India ❤❤
"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."
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?
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.
how to combine ssr with global state
amazing! Thanks :)
What about next safe action with server actions
Will there be another video? ... Why use SvelteKit? :D
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()"
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?
how would you combine nextjs with a .net backend api?
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?
What is trcp I don't know about it
So helpful, thanks! I really like your explanations!
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.
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.
Why not fix the cache?
Hope to see a video in my recommended named "Why I don't use React anymore" someday :)
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
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.
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?
At 11:30 what about client component? There I have to use trpc?
Either pass the data as props to the client component, or you can use tanstack query with server actions (queryFn: () => serverAction()) for example.
@@filipfiser1045 thanks bro I will try it out
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....
thanks. now i know server action. i never used it before.
This is just if you’re using server functions, yes? So if I’m still on Nextjs 13, I should stick with React Query?
How to convert react to pdf?
- 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?
a "feet" app? 4:21 why have I been using React for years, and never heard this term?? i feel dumb.
Kinda reminds me of what Meteor was! But more up to date/standards
put simply you don't use client components, real time data or anything of that sort.
very helpful video, thanks
Quality content.
Awesome content
fantastic
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
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.
I wanna ask can I make button with formaction when user click it will rediect them to another page?
import router from next/navigation , then use router.push(" the url you wnat to go to
")
you can use redirect function from next/navigation. works for client and server components as well as for server actions
@@rajraman987 router only works on client side
@@filipfiser1045 But One time I used redirect in form action but it directly redirect me without clicking on button. Can you provided me a source please. Thanks in advance 😅
Honestly I hate fetch, can you make some video about axios in next js on both client and server?
Can anyone tell I am using a state management tool like redux and I have a token store in my local storage. Can I get my user details on server side in any way and then can update my states
The server side won't be able to access the client side local storage I don't think, so you'll likely need to either pass whatever data you need from local storage back to next, or better implement some storage that the server can access also (i.e. cookies). If you're only interested in Auth state and are using oauth then next-auth might be ok, I implemented http only cookies myself and just had any client components make a call to get any locally required info.
quality content
thank you)
Does there exist a proper implementation of infinite scroll data without using react query prefetching in Next.js server components?
This is part of the streaming api. It's still experimental. But this is not so important, the important thing is that you want to track the state on the client and initiate a request from the client, which means you must manage the cache and state of requests on the client. This means that you are using React-Query. This means that you have 2 managed caching layers. No options.
For static sites, you almost never need to track requests and states; the maximum network interactivity on such sites is a link or a static form, apparently the author makes only such sites.
Moreover, for static sites like a blog, you want to compile the html and put it on a CDN, that is, you do not need a running application per request. You need to make a couple of endpoints for lambda functions or even connect it as an external service without your own backend. So server actions will eat your money by forcing you to use expensive infrastructure. So for many applications this is a very difficult architectural choice.
how about SWR
Does this work outside of Vercel though?
After watching this i appreciate how good laravel is now nextjs is following that methodology
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
I see that react query is useful in react native projects.