This was fantastic. A shit ton of golden knowledge nobody talks about. Please create more of these best practices for more advanced developers. Great job!
Brilliant quote. "If your app is mostly server components, it's really a site, not an app". Yes! I have no idea why React and NextJS reposition themselves as static site frameworks (becoming less convenient for SPAs). But I have no doubts that competitors won't miss a chance to fill the niche.
What do you mean they're less convenient for SPA? You can do a SPA just as easily as before literally all the extra logic needed is a SINGLE 'use client'
@@makl-the-oracle "use client" is incompatible with metadata in RSC. In older NextJS you could have getServerSideProps / getStaticProps AND metadata at the same time. With app router and RSC it's no longer possible (for no technical reason). So you have to split your pages in 2 components, each of them, to workaround a framework limitation. Just one example of inconvenience and SPA having a 2nd class support, there're more issues.
Bro, you said do the validation in the frontend and once everything is good to go, send to server. So you can lower the expenses via server overhead. That's bad. Frontend (client-side code, that is) can easily be manipulated and/or bypassed. My point is: You don't want either client-side or server-side validations. You always want BOTH. While client-side validations can be bypassed by bad actors, they are still good to be used because of the immediate feedback they provide + less server overhead when used by good actors. Then server-side validations are redunandant if used b good actors but a last defense against bad actors. These are not exclusive to one another. They are not a matter of preference not good/bad practice. You should never choose one over the other, no matter each. You should always HAVE BOTH. And btw, about server actions: 1. they CAN be type-safe 2. they are simple functions (meaning you can extract them and use them as 'a module', meaning you can always switch onto a new stack, meaning they are in fact agnostic, if one knows how to wrap them into a 'library interface'). 'Server components are there so hydrate the client, nothing more.' They are there to increase speed and security, speed due to the server handing over html files (at the expense of some added server overhead, granted) and security due to the fact that you run most of the important code, on the server, away from bad actors, these are only getting html files. God, you're so biased towards tRPC, it's unbelieable. Disclaimer: I use tRPC myself and I love it. But your take against nextjs is invalid.
I've been out of the loop for quite a while now in regards with Next.js and alternative solutions. If you can share the input and output types between the two, and even have superjson in-between, I would assume so.
I wanna ask you. Actually i am frontend. This year i want to be backend dev. Do you have any idea what things i have to learn to became backend dev? I just know i have to learn mongodb, ts, redis, expres, node, sequalize(because my backend dev company usually use that). What the other things i have to learn?.
Just focus on learning the stack your company uses. Build a few projects so that you get a better understanding of how every piece works. Since you're already a part of the company, talk with your manager and see if it's possible to gradually take on back-end responsibilities. From there, you'll learn everything you need.
It's great. I wouldn't recommend scaffolding it with next-auth, but, other than that, whatever floats your boat. Personally, I'm not a fan of ORMs. For instance, Prisma's performance isn't the best; that's why I prefer query builders, such as Kysely. Not only do you get the best performance, but you also learn SQL, which is a crucial skill to have.
@@lucas-barake Oh really, I love the integration with NextAuth, why don't you like it ? As for ORMs, yeah SQL is a must have but its also cool to have the full type-safety and the easier way to communicate with the DB. I can get it though.
@@CyBeRTeCk_ NextAuth's documentation is lacking, and it ties your authentication to Next.js exclusively. For instance, when I had to develop a React Native application, unfortunately, it simply wasn't possible to integrate NextAuth with it. The adapters are also subpar. If you want to include relations in the session, you need to perform an additional query instead of modifying the base query. As a result, you end up hitting your database twice as much. While it may suffice if your application is relatively basic (you don't need fine-grained control of the authentication) or you want it to be the authoritative authentication source for your Next.js app exclusively, I would advise against it otherwise.
@@lucas-barake Ok yes I get it, that is bad for applications that scales because of the cost the requests multiplication it does. I can understand it and it is not for multiple applications using the same back-end. Thanks for sharing your back-end experience to the NextJS community which is most front-end and fullstack devs !
You're heating up your server with a form validation? Gotta love these frontend guys. Validation should be done both on frontend and backend so that server better be "heating up" otherwise you're gonna post soon how you got hacked. Doing tRPC in NextJS just because, some day, you might need to use a different backend server seems like over-optimization. tRPC IS NOT a must in NExtJS guys, don't listen to this guy, he's just trying to explain to hymself why he's still using tRPC for a blog and not server components like everyone else. AGAIN: do not validate data just on the client like he says (3:50). Terrible advice from a novice. Anyway, you did not provide a single valid reason why one would use tRPC in NextJS apart from, maybe, when your project requires multiple apps with shared types - other than that, you're just presenting us how highly complicated your project is.
This was fantastic. A shit ton of golden knowledge nobody talks about. Please create more of these best practices for more advanced developers. Great job!
Thank you!
this little demo really solidify the move of TRPC is superior to Server actions
this is crazy helpful. going to use this pattern for an upcoming large project. please keep making content like this!!
More to come!
Brilliant quote. "If your app is mostly server components, it's really a site, not an app". Yes! I have no idea why React and NextJS reposition themselves as static site frameworks (becoming less convenient for SPAs). But I have no doubts that competitors won't miss a chance to fill the niche.
What do you mean they're less convenient for SPA? You can do a SPA just as easily as before literally all the extra logic needed is a SINGLE 'use client'
@@makl-the-oracle "use client" is incompatible with metadata in RSC. In older NextJS you could have getServerSideProps / getStaticProps AND metadata at the same time. With app router and RSC it's no longer possible (for no technical reason). So you have to split your pages in 2 components, each of them, to workaround a framework limitation. Just one example of inconvenience and SPA having a 2nd class support, there're more issues.
Oh boy! i just learnt server actions and here is something better
just one word, amazing!!
this is quality content. thank you
Bro, you said do the validation in the frontend and once everything is good to go, send to server. So you can lower the expenses via server overhead.
That's bad. Frontend (client-side code, that is) can easily be manipulated and/or bypassed. My point is:
You don't want either client-side or server-side validations. You always want BOTH.
While client-side validations can be bypassed by bad actors, they are still good to be used because of the immediate feedback they provide + less server overhead when used by good actors.
Then server-side validations are redunandant if used b good actors but a last defense against bad actors.
These are not exclusive to one another. They are not a matter of preference not good/bad practice. You should never choose one over the other, no matter each. You should always HAVE BOTH.
And btw, about server actions: 1. they CAN be type-safe 2. they are simple functions (meaning you can extract them and use them as 'a module', meaning you can always switch onto a new stack, meaning they are in fact agnostic, if one knows how to wrap them into a 'library interface').
'Server components are there so hydrate the client, nothing more.' They are there to increase speed and security, speed due to the server handing over html files (at the expense of some added server overhead, granted) and security due to the fact that you run most of the important code, on the server, away from bad actors, these are only getting html files. God, you're so biased towards tRPC, it's unbelieable.
Disclaimer: I use tRPC myself and I love it. But your take against nextjs is invalid.
Maybe a stupid question here, but wouldn't a server action connected to React Query (or SWR) solve the exact same problem?
I've been out of the loop for quite a while now in regards with Next.js and alternative solutions. If you can share the input and output types between the two, and even have superjson in-between, I would assume so.
thank god
Please make a full app Nextjs TRPC tutorial
Coming soon
I wanna ask you. Actually i am frontend. This year i want to be backend dev. Do you have any idea what things i have to learn to became backend dev? I just know i have to learn mongodb, ts, redis, expres, node, sequalize(because my backend dev company usually use that). What the other things i have to learn?.
Just focus on learning the stack your company uses. Build a few projects so that you get a better understanding of how every piece works. Since you're already a part of the company, talk with your manager and see if it's possible to gradually take on back-end responsibilities.
From there, you'll learn everything you need.
@@lucas-barake thank you for your response🙂.
What do you think of the T3 App stack made on top of NextJ
S and tRPC ?
It's great. I wouldn't recommend scaffolding it with next-auth, but, other than that, whatever floats your boat.
Personally, I'm not a fan of ORMs. For instance, Prisma's performance isn't the best; that's why I prefer query builders, such as Kysely. Not only do you get the best performance, but you also learn SQL, which is a crucial skill to have.
@@lucas-barake Oh really, I love the integration with NextAuth, why don't you like it ?
As for ORMs, yeah SQL is a must have but its also cool to have the full type-safety and the easier way to communicate with the DB.
I can get it though.
@@CyBeRTeCk_ NextAuth's documentation is lacking, and it ties your authentication to Next.js exclusively.
For instance, when I had to develop a React Native application, unfortunately, it simply wasn't possible to integrate NextAuth with it.
The adapters are also subpar. If you want to include relations in the session, you need to perform an additional query instead of modifying the base query. As a result, you end up hitting your database twice as much.
While it may suffice if your application is relatively basic (you don't need fine-grained control of the authentication) or you want it to be the authoritative authentication source for your Next.js app exclusively, I would advise against it otherwise.
@@lucas-barake Ok yes I get it, that is bad for applications that scales because of the cost the requests multiplication it does.
I can understand it and it is not for multiple applications using the same back-end.
Thanks for sharing your back-end experience to the NextJS community which is most front-end and fullstack devs !
@@lucas-barake So what is your favourite way of authentication? By the way, this video is probably one of the videos I have learned the most from.
Can you create t3 app router tutorial?
Coming soon
@@lucas-barake please...
naaaaaaa
I prefer Server Actions
You're heating up your server with a form validation? Gotta love these frontend guys. Validation should be done both on frontend and backend so that server better be "heating up" otherwise you're gonna post soon how you got hacked. Doing tRPC in NextJS just because, some day, you might need to use a different backend server seems like over-optimization. tRPC IS NOT a must in NExtJS guys, don't listen to this guy, he's just trying to explain to hymself why he's still using tRPC for a blog and not server components like everyone else. AGAIN: do not validate data just on the client like he says (3:50). Terrible advice from a novice. Anyway, you did not provide a single valid reason why one would use tRPC in NextJS apart from, maybe, when your project requires multiple apps with shared types - other than that, you're just presenting us how highly complicated your project is.
I think you should rewatch, he mentioned several times about using, for any given form, same zod validator on both the frontend and the server.
Obnoxious subtitles. So unbelievably distracting.
Sorry for that. Fortunately, it lasts only a minute or so.