Why I don't use React-Query and tRPC in Next.js
Вставка
- Опубліковано 5 тра 2024
- Hi, I'm Wesley. I'm a brand ambassador for Kinde.
👉 NEW React & Next.js Course: bytegrad.com/courses/professi...
👉 Professional JavaScript Course: bytegrad.com/courses/professi...
👉 Professional CSS Course: bytegrad.com/courses/professi...
👉 Discord: all my courses have a private Discord where I actively participate
🔔 Email newsletter (BIG update soon): email.bytegrad.com
⏱️ Timestamps:
0:00 Intro
0:20 Data fetching before React-Query
2:20 Data fetching with React-Query
4:30 Data fetching without React-Query (Next.js)
8:55 GET / Query before tRPC
9:45 GET / Query with tRPC
10:52 GET / Query without tRPC (Next.js)
11:40 POST / Mutation before tRPC
12:25 POST / Mutation with tRPC
13:08 POST / Mutation without tRPC (Server Actions)
18:33 Overview
#webdevelopment #programming #coding #reactjs #nextjs
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.
Waiting for the video overview bro and after that I'll purchase for sure.
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
@@bozzistef querystring
try to use URLs for state management, this problem will be solved
surprised its not clickbait and actually teaching. thanks for the info
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
What a great video bro. Making things clear and understanable
Great content!! new insight achieved, thank you !
High quality video, thanks!
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!
really appreciate these indepth videos
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!
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!
the best nextjs vids! thanks so much for this man
Really very useful information and good guidance love from India ❤❤
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.
really cool! nextjs fetching is just missing a devtools equivalent for easy debugging
"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."
amazing! Thanks :)
Great video !
Thank you so much for your greate content ♥ I have one question please, what do you think about using GraphQl instead of prisma ORM ?
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.
I've just bought your courses thanks to this video. This video is very informative.
Awesome, enjoy!
I came in as a skeptic but you convinced me to give it a try
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
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?
@@user-lk3iq2bv7t 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.
fantastic
thanks. now i know server action. i never used it before.
quality content
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 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()"
Do you mean V14 of next js and app router? I find the need for react-query using v12, quite a bit.
How do you await fetch in a client component? Can you just make an async client component?
BTW what to pass to a Suspense key if it should get an array or object? To check if it has been changed?
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.
Awesome content
Have you checked out next safe action package - would make a great video.
Yeah looks great, surprised it hasn't become more popular yet
Hey is the code available for testing?
All 3 approaches?
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
}
)
Ok but how do you disable caching with nextjs? What if I DONT want to cache things. Maybe its something that updates a lot
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
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?
🔥🔥🔥
Can someone tell me how server actions work? A HTTP request is still made to the backend, right?
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
Will there be another video? ... Why use SvelteKit? :D
how would you combine nextjs with a .net backend api?
This is just if you’re using server functions, yes? So if I’m still on Nextjs 13, I should stick with React Query?
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…
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.
Is there another way for handling fetching on the server side without using fetch? as its syntax is well, not my favorite.
You mentioned that server actions are like POST but can't server actions do a GET too?
Kinda reminds me of what Meteor was! But more up to date/standards
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.
Hope to see a video in my recommended named "Why I don't use React anymore" someday :)
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.
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?
What about next safe action with server actions
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 🛐
How to convert react to pdf?
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?
I love redux-toolkit ❤
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
I see that react query is useful in react native projects.
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....
What is trcp I don't know about it
Raact Query is useful beyonf fetching data. It's allbout about asynchronous operations on the State.
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
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?
Why not fix the cache?
It would be nice if react router loaders were compared too
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
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, 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.
What is a React “feat or feet” app? Mentioned at 4:30 please. Thanks
"Vite"
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.
No way, Vercel team is completely vendor lockin customers through sponsoring such developers to use more and more next js dependencies.
Its a game that everyone western software company plays.
Honestly I hate fetch, can you make some video about axios in next js on both client and server?
Agreed, they are not React/Next, like I wont like nestjs instead of node, they are wraps, not authentic product.
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.
please update the video title by adding "in nextjs"
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.
It’s a pitfall indeed, it seems i missed key in my Suspenses
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.
Angular 17
Not really sure if the change was for the good of bad, only time will tell...
Feet app?
Yeah you don't need the OG, the only robust data fetching solution, the REACT-QUERY 🔥..
As long as you are not making a Todo app 😂😂😂.
React query will stay relevant and no.1 as long as it is about async state management.
a "feet" app? 4:21 why have I been using React for years, and never heard this term?? i feel dumb.
Does this work outside of Vercel though?
how about SWR
It sounds you are saying feet app and i had no idea ehat you meant lol
Haha yeah dont know what happened there
Hey. Thanks for the video. But the name is obvious clickbait. You covered there only the very basic case. Data loading with static cashing. But what will happen if this information becomes user-specific? Plus, let's say, with client-side updates.
revalidatePath/revalidateTag are not the best options there, as they affect not only client-side router cache, but also server-side cashe (I mean Next.js Full route cache). The best approach there will still be using client-side async state managers like SWR/React-Query/etc. With initial server-side loading using RSC we update client-side cache and operate with it.
but in next js when you fetch data its fetched twice ==== the same as react
im not react dev just i like to comment
I believe it's caused by Strict Mode but it works perfectly on production and you can also disable it if you want.
This behavior only happens in development mode, because React run several things twice, but in production everything works "normal".
put simply you don't use client components, real time data or anything of that sort.
Great now you are vender locked
Aren’t you anyway locked when you decided to use next ?
React query is great, Next.js and trpc is literal garbage (has place in personal projects), why would you want your BE written with TS for a real project.. ??? Next.js is such a convoluted mess it makes me sick.
Maybe just littlebit slower next time? 😂