We need more videos like this, coding tutorials are everywhere but no one is teaching architecture specific to a framework, i usually struggle to decide what goes where, great video
Hey, I am also using supabase right now and I also like it. I just dont know how to how to use types properly. Currently I just take the return type of my data access functions. Also I am not sure how to deal with joins. Should I create functions and types? For example: getApplicationsWithProfile and the Type ApplicationWithProfile.
Your style of teaching is extremely helpful. I would love to see how you would approach having the "backend" aspect be decoupled from NextJS. For instance, when using a shared backend across multiple applications. I imagine the only difference would be that the business layer would be an external api, which then handles the persistence and database layers. Unless I'm missing something.
Helpful video. I split along the same lines. This is honestly why the nextjs paradigm feels off to me because you can end up mixing your code into a spaghetti pile. But hey, as long as we get rid of the spinners 😂
Great video! I've been thinking about how I could use clean architecture in NextJS. You even touched upon a few concepts from Domain Driven Design in there. Cheers!
Hi, I use a very similar structure, except for some projects that I want to advance quickly, I unify the business layer with the persistence layer, but the separation of the view/controller layer is always there, it is super important. I communicate them with DAO objects.
Really liked this. I feel Nextjs is overly complicated for the apps that I'm working on currently, so I'm sticking with bun + vite, which is very fast and stable. So hope you do some content for that too :)
This is how we learned to build NodeJS apps a few years ago in the bootcamp I attended. You actually made me realize how I incorporated some of it into NextJS haha. I do the rate-limit part in the global middleware and the Auth + user Input checks within the server actions. I treat the server actions like a small middleware that checks if everything is correct before passing the data down to the business layer. My use-cases/business layer is basically also a persistence layer, but it's actually a good idea to separate them. It seems much more maintainable and scalable for larger projects, though it might be overkill for smaller ones.. I'll definitely give it a shot and refactor some of my projects.
Hii Cody, I like this architecture type, everything gets way cleaner and its kinda looks like a backend architecture with Controller and Services, I love it ! I have one question, inside the data-access & uses-cases files do we need to put « use server » ? Or maybe import server-only ? I thought it was necessary 🤔 (even tho I don’t know the difference between both of them lmao)
@@WebDevCody Oh I got it, I see now, so by default these use-cases and data-access are rendered on server. + it’s not related to next so another reason to not add these « use server ». Thank you so much ! 🙏
Amazing!! can you add a second part to the video how you decide what files should have try, catch ? what files shouldn't have it and just throw errors ? how toast work with actions ? and maybe a user auth with custom jwt and not using clerk ? also, how can we use webhooks with this architecture? and 3rd party integrations.
Your work is exceptional. I am inspired by your videos and the fresh insights I gain from them. It makes me wonder if there's something new I may have overlooked. It would be great if you start adding unit tests as well. Keep up the great work.
Is it wrong that I'm using server actions with tanstack query? Specifically for interactive components where user input is required, because I love the success and error workflow that it provides. For get requests I just call server actions in server components in 99.9% of cases.
I don't think next recommends using server actions for fetching data. server actions were specifically created for form submissions. If you start using them for fetching data, you may see issues where doing multiple queries in your UI will result in a waterfall because server actions can only run sequentially. I do think server actions are highly coupled with RSC, so if you use server actions, you should probably be using RSC and calling revalidatePath to force your UI to refresh. If all you're looking for is a better success /.error workflow, maybe checkout that ZSA I mentioned.
Hey there, great video! Glad to see that we have a very similar approach. I've been trying to figure out myself when fetching data in server components. I've been checking if the user is authenticated before fetching, but here's what I'm thinking: if the page is protected and the user has to be authenticated for the page and the component to render, the fetch call will never be made by an unauthenticated user, right? So, it's automatically protected. But i still do it anyway.
The loader approach I mentioned can be useful, maybe even make an authenticatedLoader helper which verifies the user is logged in so you don’t have to keep fetching the user and validating it every time
Next.js reccomends having a data-access layer where you make the checks for accessing the data. In your way of architecting your apps I assume that's the "data-access" folder, does that include checks for auth and authorization at all? Or you're trusting the layer above it to do those checks? why if i call (by accident) one of the exported functions from the "data-access" folder directly?
I’m trusting the layer above (use case) will check authorization, just like I trust the action validated a user is authenticated. I’ve seen some people put authorization checks in the data access layer,but that feels less maintainable to me imo
@@WebDevCody But the problem is it won't go through the above layer (use case) if someone called the exported function form data access layer directly. This way there won't be any checks of use case layer going on. How do we solve this ?
I understand this abstracts/separates the 3 layers but could you just handle all of your business logic by chaining another zsa procedure say to check the group and pass it as context to the action etc ? I'm guessing this is inconvenient if you want to get group/role for other purposes/areas in the app?
In the past, you would have recommended to do dependency injection on the use-cases or business logic so that it's not dependent on any external libraries (in this case drizzle-orm). Would you say injecting dependencies is just more cumbersome now and you're okay to have your business logic tied to the database repository functions or would you still dependency inject? I'm asking because I'm having the same issue
I don’t think dep injection is useful. I honestly think it was written in the context of having to compile modules and hook them together. If all your code is owned in the same code base, it adds little value (other than mocking maybe?), but adds indirection. I’d honestly avoid it.
@@WebDevCody I was thinking about it a bit more and reading more about DDDD and my updated thoughts on this is... I guess it really makes more sense in the context of using classes. Cuz dependency inject individual drizzle-orm functions is very cumbersome and leads to being feeling overwhelmed, but I would assume if injecting a whole repository class that might make more sense? Open to your thoughts. I'm leaning towards trying a whole DDDD approach right now (but not strict adherence and adapting when it makes sense) but I think the drawback of that is just a lot of code to maintain. But at the same time, writing it like how almost all nextjs projects are right now, is also making me a bit overwhelmed since things aren't very organized and mentally it's starting to get overwhelming.
@@WebDevCody So I'm thinking of using more classes in my nextjs app for domain entities and repositories etc. One thing I'm afraid of is that these classes potentially making nextjs take longer to load since I'm loading more code I'm not using, and I think that's probably a legit concern, but for now, using functions only when the codebase starts to grow and there are more entities and a bit more complexity ends up with the complexity being managed in my mind rather than the code... open to your thoughts though
I have a question regarding server actions. So as far as I understand it you're using server actions mostly for writing to the database (which is logical since they are all POST requests). What I don't understand is how do I handle errors if the post request fails and doesn't get pushed to the database. Even in your demonstration where you get the post and you await for it to be published there was no form of error handling (as far as I could tell). Also I had a project where I lazily used server actions for everything (including fetching stuff from db) and while it was working there's gotta be some negative consequences right? The way you do it by fetching directly in the server components seems better and is the right way AFAIK.
I use use form hook on all my forms for client side validation errors. If the backend throws an error I use a hook called useServerAction and ZSA which sets state of is error true when the backend throws any errors
Great video! Question - with this kind of separation, how can you implement a transactional business logic? For example if you have 2 use cases A and B, that you will need to call them both as an atomic action, how will you do that in this architecture where you abstracted the implementation of calling to db?
personally you shouldn't be invoking 2 use cases as separate things, you should combine them into one. If you need transactions, I'd say just make a single persistence method which does the transactions you need. Pass whatever data into your persistence method and let it figure out how to do the transactions. For example, transferFunds(userAId, userBId, amount), this could all be abstracted behind a single persistence method.
I'm wondering what about the Dependency Injection. Let's consider the simple use case of having option to connect different DBs. Let's say at the start I will need to use Drizzle, but later I need to switch to Postgress. In such a scenario, I would create a class that takes different DBs and provides simple methods for updating, querying or deleting. Then I could use that class in Persistence layer and provide another abstraction with the methods usch us updateGroupById, etc. Would that class be in the persistence layer or where would you guys put that?
That’s an adapter which if following clean architecture should be injected into your use cases. I’m specifically avoiding that in my project because I find it provides zero real benefits at the cost of a harder to understand code base. It helps in regards to unit testing, but we also have jest.mock which achieves the same thing. Refactoring individual persistence methods like I’m doing to connect to different databases isn’t hard to do since I’m using typescript anyway.
If you actually implement testing in your app, you're implementing a similar structure shown in the video out of necessity. In fact, this is exactly how I'm developing in Next.js
amazing video Cody! I always struggle on how to organize code in Nextjs apps when using server actions so this is great. You mentioned in the end using server actions vs react-query/more traditional data fetching APIs. How's your perspective on those trade-offs so far? What if you add Convex in the mix as well?
if you're using convex, you don't need server actions. I enjoy server actions if you're just doing a standard next.js application. If you think you'll have a use-case of external people needing your data, then you probably should just make a rest api to begin with and use a better framework for rest apis instead of next.js. (such as nest.js, hono, etc). The rest api experience in next.js feels like an after thought.
@@WebDevCody If we are using a separate backend like Nest for handling authentication, how can we authenticate users on Next.js and manage things like token rotation and fetching authorized API data in (RSC)?
@@imkir4n you should be able to just hit a login endpoint on your nest.js endpoint which could set a cookie with a top level domain set. Assuming your api and next application are sharing the same top level domain, that cookie will be sent on any request to your domain (including both your api and next.js application). Then you'd need to use that cookie in your next.js application and invoke your api to get the user session in your RSC calls. If you want to prevent hitting your api on every single request, that's when you'd probably just want to use some type of encrypted cookie and both your api and next.js application knows how to decrypt to get the user id of the session. idk if that answers it.
@@WebDevCody If it’s possible, please make a video covering these topics: lacking content for the next app router with a separate backend, which follows good practice.
@@imkir4n The thing is, /login endpoint should not return tokens as a response json, but a cookie instead. The one who set and manage auth and refresh cookie token should be your backend team. On your frontend, you just need to set `credentials: include` on the fetch function (`withCredentials: true` on Axios), you don't need to think about token or where to store it at all. When Frontend hit an authenticated API, the backend should check the cookie token (and do some token rotation when the auth token is expired for example) before proceeding to the API actual business process
So I’m referring to using drizzle’s transaction functionality. I really like the pattern you demonstrate but not sure how to use multiple use cases and/or date access function calls under one transaction in a clean re-usable way, if that makes sense
Hello devCody , this video really helps me For next video , can you explain error handling with drizzle orm ? I am using drizzle orm and postgres-js , and sometimes when i enter duplicate data on unique fields , wow new error and i don't know how to handle it
In the use case, you should probably be handling errors, so you should be catching errors from the persistence layer and running other business logic when things go wrong. For example, if you try to insert a record and there is a duplicate, you can either throw an error back to the user so they can change their input, or you could force overwrite the record, it all depends on your business rules.
Is there a way to download all your knowledge, asking for a friend.... that friend is me... i am that friend I once had to replace my firebase with cloudinary cuz it was freaking slow, and was glad i abstracted, cuz all i had to fo was a few tweaks and write the query once
@@WebDevCody In my current setup, I'm just rawdoging trpc with drizzle directly in the procedures, it works great and I don't really have to isolate stuff that much, I don't know man, maybe I haven't made anything that complicated to realize the benefits of this but to me, this is severely excessive 😅. Although, I do aggree with the entities pattern, taht shit is a life saver for both client and server side validation 💯
Hey, does anyone have experience using this architecture with Supabase? I'm not sure how to use proper types. I just don't understand how Supabase wants us to create types. I also have a question about joins. Should I create data access functions like getApplicationsWithProfile, or should I call two functions when I need an application and a profile separately?
You could have a single method which joins the profiles and returns all the data if you need that performance boost. Doing two function calls isn’t too bad
Instead of calling multiple use cases direcly inside your server components you might want to do it from a single controller instead :-) But great video.
RIP the beard (though shall be missed 🧔♂)............... also just wanted to know if you have a common component just for a particular section of files/folders how do you handle that? add it in common components or make a common components directory for that section itself?
if it's something you know you'll be using in many pages, I'd say a top level components directory. If it's something only used 2-3 places only on a single page, I'd co-locate it in a _components directory in that route
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
We need more videos like this, coding tutorials are everywhere but no one is teaching architecture specific to a framework, i usually struggle to decide what goes where, great video
mythical beast: clean shaved cody
Lmaoooooooo I’m going to call him this from now on
Cody your videos are incredible. The one where you show how to make contributions to open sourced projects in my favorite.
I’m loving Supabase right now. The business layer fits in really well with Postgres functions and edge functions.
Hey, I am also using supabase right now and I also like it. I just dont know how to how to use types properly. Currently I just take the return type of my data access functions. Also I am not sure how to deal with joins. Should I create functions and types? For example: getApplicationsWithProfile and the Type ApplicationWithProfile.
Thank you Cody! I’ve been developing in Nextjs for a while but seeing the perspective from a senior developer is unbelievably valuable
i love cody but does he really count as senior? i don't know.
I'm junior all day every day baby
@@Yusuf-ok5rk true, not really sure. kinda assumed haha
Good to see you back babe! Love ya! Great job
Are you too related somehow? 😅
@@juliocesarbenavente9590 it's his wife
@@juliocesarbenavente9590 she's his gf I guess
@@juliocesarbenavente9590his wife, dope ass relationship. Shout out to Cody for being the 🐐
Hello Mrs. Cody
Colocation makes the most sense. I don't know why I didn't think to apply this to server actions. Great video.
I knew something was wrong with how I was coding but didn't know what it was, this video is what I needed - ty!
Your style of teaching is extremely helpful.
I would love to see how you would approach having the "backend" aspect be decoupled from NextJS. For instance, when using a shared backend across multiple applications. I imagine the only difference would be that the business layer would be an external api, which then handles the persistence and database layers. Unless I'm missing something.
I think that’s a good assumption, the actions could call your api
16:50 100% agree at my work there is a component folder with hundreds of files in it and I know for a fact at least 10% aren’t even being used
Helpful video. I split along the same lines. This is honestly why the nextjs paradigm feels off to me because you can end up mixing your code into a spaghetti pile. But hey, as long as we get rid of the spinners 😂
I never thought of using Server actions in this fashion, I always thought that it was for forms
Great video! I've been thinking about how I could use clean architecture in NextJS. You even touched upon a few concepts from Domain Driven Design in there. Cheers!
Yea! I think your the only person talking about this topic in Nextjs community
Hi, I use a very similar structure, except for some projects that I want to advance quickly, I unify the business layer with the persistence layer, but the separation of the view/controller layer is always there, it is super important. I communicate them with DAO objects.
Really liked this. I feel Nextjs is overly complicated for the apps that I'm working on currently, so I'm sticking with bun + vite, which is very fast and stable. So hope you do some content for that too :)
This is how we learned to build NodeJS apps a few years ago in the bootcamp I attended. You actually made me realize how I incorporated some of it into NextJS haha.
I do the rate-limit part in the global middleware and the Auth + user Input checks within the server actions. I treat the server actions like a small middleware that checks if everything is correct before passing the data down to the business layer.
My use-cases/business layer is basically also a persistence layer, but it's actually a good idea to separate them. It seems much more maintainable and scalable for larger projects, though it might be overkill for smaller ones.. I'll definitely give it a shot and refactor some of my projects.
16:45 would you also recommend co-locating your unit-tests? So your unit tests would be in the same directory as the function that it is testing.
unit test yes, e2e tests, probably no
Hii Cody, I like this architecture type, everything gets way cleaner and its kinda looks like a backend architecture with Controller and Services, I love it !
I have one question, inside the data-access & uses-cases files do we need to put « use server » ? Or maybe import server-only ? I thought it was necessary 🤔 (even tho I don’t know the difference between both of them lmao)
I wouldn’t add any react or next related things inside of either. Those should only live in actions or loaders
@@WebDevCody Oh I got it, I see now, so by default these use-cases and data-access are rendered on server. + it’s not related to next so another reason to not add these « use server ». Thank you so much ! 🙏
Amazing!!
can you add a second part to the video how you decide what files should have try, catch ? what files shouldn't have it and just throw errors ?
how toast work with actions ? and maybe a user auth with custom jwt and not using clerk ?
also, how can we use webhooks with this architecture? and 3rd party integrations.
The way you write server actions is very similar to how actions/queries/mutations are written in convex, interesting 👍
I think trpc inspired a lot of things, same with react query
Your work is exceptional. I am inspired by your videos and the fresh insights I gain from them. It makes me wonder if there's something new I may have overlooked. It would be great if you start adding unit tests as well. Keep up the great work.
Thanks man
Is it wrong that I'm using server actions with tanstack query? Specifically for interactive components where user input is required, because I love the success and error workflow that it provides. For get requests I just call server actions in server components in 99.9% of cases.
I don't think next recommends using server actions for fetching data. server actions were specifically created for form submissions. If you start using them for fetching data, you may see issues where doing multiple queries in your UI will result in a waterfall because server actions can only run sequentially. I do think server actions are highly coupled with RSC, so if you use server actions, you should probably be using RSC and calling revalidatePath to force your UI to refresh. If all you're looking for is a better success /.error workflow, maybe checkout that ZSA I mentioned.
this is useful stuff. Thanks for the video, cody!
Valuable content 🙏 Thanks for sharing
Thanks Cody! This is so useful!
should there also be services after use cases ? Use cases will call diffrent services and the services will call the data access
Hey there, great video! Glad to see that we have a very similar approach. I've been trying to figure out myself when fetching data in server components. I've been checking if the user is authenticated before fetching, but here's what I'm thinking: if the page is protected and the user has to be authenticated for the page and the component to render, the fetch call will never be made by an unauthenticated user, right? So, it's automatically protected. But i still do it anyway.
The loader approach I mentioned can be useful, maybe even make an authenticatedLoader helper which verifies the user is logged in so you don’t have to keep fetching the user and validating it every time
Would love to see github repo of this, it's hard for me to comprehend the structure just by looking at the video
Great stuff. Can you link to the safe server action package
Cool vid, would like to see more on the entities and maybe services, ie would payment service be similar to db repository?
Hey ! What is your visual studio theme ? It looks gorgeous :)
Bearded theme stained blue
Welcome back brother
Next.js reccomends having a data-access layer where you make the checks for accessing the data. In your way of architecting your apps I assume that's the "data-access" folder, does that include checks for auth and authorization at all? Or you're trusting the layer above it to do those checks? why if i call (by accident) one of the exported functions from the "data-access" folder directly?
I’m trusting the layer above (use case) will check authorization, just like I trust the action validated a user is authenticated. I’ve seen some people put authorization checks in the data access layer,but that feels less maintainable to me imo
@@WebDevCody But the problem is it won't go through the above layer (use case) if someone called the exported function form data access layer directly. This way there won't be any checks of use case layer going on. How do we solve this ?
What kind of keyboard you rocking? Sounds immaculate.
Klack.app
I understand this abstracts/separates the 3 layers but could you just handle all of your business logic by chaining another zsa procedure say to check the group and pass it as context to the action etc ? I'm guessing this is inconvenient if you want to get group/role for other purposes/areas in the app?
That is an option, but I guess I wouldn’t want my business logic coupled to zsa
In the past, you would have recommended to do dependency injection on the use-cases or business logic so that it's not dependent on any external libraries (in this case drizzle-orm). Would you say injecting dependencies is just more cumbersome now and you're okay to have your business logic tied to the database repository functions or would you still dependency inject? I'm asking because I'm having the same issue
I don’t think dep injection is useful. I honestly think it was written in the context of having to compile modules and hook them together. If all your code is owned in the same code base, it adds little value (other than mocking maybe?), but adds indirection. I’d honestly avoid it.
@@WebDevCody I was thinking about it a bit more and reading more about DDDD and my updated thoughts on this is... I guess it really makes more sense in the context of using classes. Cuz dependency inject individual drizzle-orm functions is very cumbersome and leads to being feeling overwhelmed, but I would assume if injecting a whole repository class that might make more sense? Open to your thoughts. I'm leaning towards trying a whole DDDD approach right now (but not strict adherence and adapting when it makes sense) but I think the drawback of that is just a lot of code to maintain. But at the same time, writing it like how almost all nextjs projects are right now, is also making me a bit overwhelmed since things aren't very organized and mentally it's starting to get overwhelming.
@@WebDevCody So I'm thinking of using more classes in my nextjs app for domain entities and repositories etc. One thing I'm afraid of is that these classes potentially making nextjs take longer to load since I'm loading more code I'm not using, and I think that's probably a legit concern, but for now, using functions only when the codebase starts to grow and there are more entities and a bit more complexity ends up with the complexity being managed in my mind rather than the code... open to your thoughts though
I have a question regarding server actions. So as far as I understand it you're using server actions mostly for writing to the database (which is logical since they are all POST requests). What I don't understand is how do I handle errors if the post request fails and doesn't get pushed to the database. Even in your demonstration where you get the post and you await for it to be published there was no form of error handling (as far as I could tell). Also I had a project where I lazily used server actions for everything (including fetching stuff from db) and while it was working there's gotta be some negative consequences right? The way you do it by fetching directly in the server components seems better and is the right way AFAIK.
I use use form hook on all my forms for client side validation errors. If the backend throws an error I use a hook called useServerAction and ZSA which sets state of is error true when the backend throws any errors
Great video!
Question - with this kind of separation, how can you implement a transactional business logic?
For example if you have 2 use cases A and B, that you will need to call them both as an atomic action, how will you do that in this architecture where you abstracted the implementation of calling to db?
personally you shouldn't be invoking 2 use cases as separate things, you should combine them into one. If you need transactions, I'd say just make a single persistence method which does the transactions you need. Pass whatever data into your persistence method and let it figure out how to do the transactions. For example, transferFunds(userAId, userBId, amount), this could all be abstracted behind a single persistence method.
I'm wondering what about the Dependency Injection. Let's consider the simple use case of having option to connect different DBs. Let's say at the start I will need to use Drizzle, but later I need to switch to Postgress. In such a scenario, I would create a class that takes different DBs and provides simple methods for updating, querying or deleting. Then I could use that class in Persistence layer and provide another abstraction with the methods usch us updateGroupById, etc. Would that class be in the persistence layer or where would you guys put that?
That’s an adapter which if following clean architecture should be injected into your use cases. I’m specifically avoiding that in my project because I find it provides zero real benefits at the cost of a harder to understand code base. It helps in regards to unit testing, but we also have jest.mock which achieves the same thing. Refactoring individual persistence methods like I’m doing to connect to different databases isn’t hard to do since I’m using typescript anyway.
A question, say you have a usecase where you'll need to perform a db transaction involving multiple tables, how should this be implemented?
Good question. I’ll make a video on it
If you actually implement testing in your app, you're implementing a similar structure shown in the video out of necessity. In fact, this is exactly how I'm developing in Next.js
you mean unit testing in particular right? Yes, if you're trying to unit test and mock out function calls, then this approach can help a lot.
@@WebDevCody yep, exactly
Is it possible to teach yourself Clean Architecture? I remember trying to read the book and everything went straight over my head lol.
Just maintain a project for some time and youll come to it naturally😅
Honestly his diagram with the circles is a better outline of what you need to do compared to reading the book
amazing video Cody! I always struggle on how to organize code in Nextjs apps when using server actions so this is great.
You mentioned in the end using server actions vs react-query/more traditional data fetching APIs. How's your perspective on those trade-offs so far? What if you add Convex in the mix as well?
if you're using convex, you don't need server actions. I enjoy server actions if you're just doing a standard next.js application. If you think you'll have a use-case of external people needing your data, then you probably should just make a rest api to begin with and use a better framework for rest apis instead of next.js. (such as nest.js, hono, etc). The rest api experience in next.js feels like an after thought.
@@WebDevCody If we are using a separate backend like Nest for handling authentication, how can we authenticate users on Next.js and manage things like token rotation and fetching authorized API data in (RSC)?
@@imkir4n you should be able to just hit a login endpoint on your nest.js endpoint which could set a cookie with a top level domain set. Assuming your api and next application are sharing the same top level domain, that cookie will be sent on any request to your domain (including both your api and next.js application). Then you'd need to use that cookie in your next.js application and invoke your api to get the user session in your RSC calls. If you want to prevent hitting your api on every single request, that's when you'd probably just want to use some type of encrypted cookie and both your api and next.js application knows how to decrypt to get the user id of the session.
idk if that answers it.
@@WebDevCody If it’s possible, please make a video covering these topics: lacking content for the next app router with a separate backend, which follows good practice.
@@imkir4n The thing is, /login endpoint should not return tokens as a response json, but a cookie instead. The one who set and manage auth and refresh cookie token should be your backend team.
On your frontend, you just need to set `credentials: include` on the fetch function (`withCredentials: true` on Axios), you don't need to think about token or where to store it at all.
When Frontend hit an authenticated API, the backend should check the cookie token (and do some token rotation when the auth token is expired for example) before proceeding to the API actual business process
This is very very very helpful, thanks!
How does the architecture change when using external APIs instead of the built-in Next.js API routes?
You wouldn’t do this in that case, your external api should imo.
How do you handle transactions if you have multiple data access calls? Like how do you keep things still de-coupled?
I'm not sure what you are asking, this is what I'm doing in this video. I have 2 functions which both make separate drizzle queries.
So I’m referring to using drizzle’s transaction functionality. I really like the pattern you demonstrate but not sure how to use multiple use cases and/or date access function calls under one transaction in a clean re-usable way, if that makes sense
Basically your data access function calls use the database object directly, but don’t accept a transaction object if it was under a transaction
What if i already have a backend service, should i just remove the usecase and repository layer and call the backend api directly?
The use base and repo layer are specifically for wrapping your backend logic
I'm gonna try
what is your vscode theme name?
Amazing Video 😊
Do we need react query for nextjs projects?
if you're using server actions and RSC, probably not really.
What about the loading state? How do you handle that?
Suspense with skeleton loaders
Can you give me the example repo
What is the text editor on 0:22?
Insanely informative! Thank you! So, for example, if I were using Tanstack/React Query, I would house that logic on the persistence layer right?
no, react query is a presentation layer concern.
Hey! Nice video! Can you Tello me the name of the theme? Please!!
what is the theme? i would like to know!
Hello devCody , this video really helps me
For next video , can you explain error handling with drizzle orm ?
I am using drizzle orm and postgres-js , and sometimes when i enter duplicate data on unique fields , wow new error and i don't know how to handle it
In the use case, you should probably be handling errors, so you should be catching errors from the persistence layer and running other business logic when things go wrong. For example, if you try to insert a record and there is a duplicate, you can either throw an error back to the user so they can change their input, or you could force overwrite the record, it all depends on your business rules.
🔥
zsa > next-safe-actions?
Which theme is that
Did you stop using Convex?
no I still use it for one of my side projects
awesome
Is there a way to download all your knowledge, asking for a friend.... that friend is me... i am that friend
I once had to replace my firebase with cloudinary cuz it was freaking slow, and was glad i abstracted, cuz all i had to fo was a few tweaks and write the query once
This approach is great, but how the hell do you get anything done with all that mental overhead 😵?
What part do you feel is overhead? Action calls a use case, use case calls persistence method. That’s basically it
@@WebDevCody In my current setup, I'm just rawdoging trpc with drizzle directly in the procedures, it works great and I don't really have to isolate stuff that much, I don't know man, maybe I haven't made anything that complicated to realize the benefits of this but to me, this is severely excessive 😅. Although, I do aggree with the entities pattern, taht shit is a life saver for both client and server side validation 💯
what keyboard do you use god cody?
mac book keyboard, sound effects using klack.app
@@WebDevCody that keyboard sounds neat. thank you god cody
Hey, does anyone have experience using this architecture with Supabase? I'm not sure how to use proper types. I just don't understand how Supabase wants us to create types.
I also have a question about joins. Should I create data access functions like getApplicationsWithProfile, or should I call two functions when I need an application and a profile separately?
You could have a single method which joins the profiles and returns all the data if you need that performance boost. Doing two function calls isn’t too bad
Instead of calling multiple use cases direcly inside your server components you might want to do it from a single controller instead :-) But great video.
Can u make a tutorial on t3 with sst ion...
I haven't really used t3 in a while now
@@WebDevCody will be a good exercise if you consider it
how about using ddd
could you explain how much different DDD would be over what I showed here?
RIP the beard (though shall be missed 🧔♂)............... also just wanted to know if you have a common component just for a particular section of files/folders how do you handle that? add it in common components or make a common components directory for that section itself?
if it's something you know you'll be using in many pages, I'd say a top level components directory. If it's something only used 2-3 places only on a single page, I'd co-locate it in a _components directory in that route
Bro what did you say you can do to SQL ?? 😂 13:01
🤣
老师 很牛逼
A real stuff! Text a lot
the keyboard click sounds are just horrendous 😵💫
You’re the first person who said they don’t like it 🤔
@@WebDevCody i was listening with ear buds😅
Dad, why did you shave 😭
So that people trust my advice less
22 year old Cody
🤣
the problem with architectures is that people tend to fall into mental masturbation about it and overcomplicate things into hard to maintain state
I agree, which is why I don’t fully follow clean arch. I use it more as a guideline
Where is your beard?
gone until I get lazy again
Bro you looking -10 year from your age😂
the power of never going out in the sun
Dislike the vid because you didn't upgrade those extensions and the line wasn't straight