No video
Applying clean architecture to my Next.js project
github.com/web...
00:00 overview
08:10 start of clean architecture talk
📘 T3 Stack Tutorial: 1017897100294....
🤖 SaaS I'm Building: www.icongenera...
▶️ Generate Chapters: ytchaptersgene...
💬 Discord: / discord
🔔 Newsletter: newsletter.web...
📁 GitHub: github.com/web...
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
Пікірлер: 193
Awesome! Really love the part about SST, Docker, and Workflows. Infra is usually being glossed over.
People should throw money at you for this content to be honest.
@shravan2891
8 ай бұрын
Have you thrown already?
@anargyrosstylidis2595
8 ай бұрын
He is one of the main reasons I got my first job as a self taught dev
Wow just the right time. I'm learning Next.js by creating a personal project and this is what I've been looking for.
I am more Angular for Enterprise level architectures, mainly because of its module and integrated DI. For Solid on frontends (or flutter) I do : DataSource (API/DB/Cache) Repository (Data fetching strategy) UseCase (must be a user action) Controller (State management)
@invictuz4803
8 ай бұрын
Is the repository's purpose just to map DTOs to models for the use cases? What else does it do for Data fetching strategy?
@paulwong7224
8 ай бұрын
@@invictuz4803 The repository is the only one that can talk to the database. So that if you change your database, you just need to update the repository. Repository will guarantee output in a certain format but input can be updated if anything db related updates
@BonBaisers
8 ай бұрын
@@invictuz4803 repository is also responsible for the cache management. So it may use local datasource's or remote datasource's. Domain/Core layer may only ask for a refresh as it is a User conceirn but does not know what it means on infrastructure side. As repository is outside the application core, and close to infrastructure, it knows, for example, connectivity status.
i really like videos about this those advanced topics (clean architecture, DDD), would love to see more of it!
I actually leveled up, few months ago I would not understand a thing about what you said. I'm glad that I can follow your videos ❤
You are as knowledgeable as the senior dev I work with. I look at people like you and wonder if I will ever reach this level, I feel I'm too low iq to ever evolve this far.
@WebDevCody
8 ай бұрын
you'll get there
Very nice! I definitely agree dependency injection is the way to go on large apps. Specifically inversion of control. Seems like we've gone full circle on PHP now :D Good times ahead
@BonBaisers
8 ай бұрын
IoC is key on large projects, as technical debts, due to coupling, can quickly become unmanageables. Lazy resolving can have a huge impact on performances. Of course, if you plan to test unit or use TDD, it become mandatory. As an architect, making large apps is also planning for maintenance and refactoring.
when it will come to unit test this approach will show all its might and benefits. It should be sooo easy to mock any dependencies and it will look very clean.
I'm using the app router a lot lately too, i like to store the components (the things that the page depends on as you said) in a _components folder, just so you can properly see the page.tsx and inside each folder you have things separated.
@WebDevCody
8 ай бұрын
yeah I was doing that at one point as well, but now I just dump everything in the same folder unless it gets filled. Having parallel routes also help prevent needing _components
@CadisDiEtrama000
8 ай бұрын
@@WebDevCody Yeah, but correct me if I'm wrong, but I didn't see a case where you had a page folder, and then a component you extracted into that folder. You only had pages in the subfolders... e.g. you didn't have something like app > dashboard > _components , some-page.tsx.
@WebDevCody
8 ай бұрын
@@CadisDiEtrama000 yeah I didn’t have that in this example, I just dump any components at the page directory usually.
@untalentedwebdev
8 ай бұрын
@@WebDevCody parallel routes meaning you just put the components.tsx into the same folder as the page.tsx?
@WebDevCody
8 ай бұрын
@@untalentedwebdev parallel routes involve adding a @routeA @routeB directory where you can split your page into multiple sub components, so imagine a dashboard with 2 charts, each chart could be a parallel route which allows you to colocate your components inside those parallel route directories
This was super helpful and even better that you included the source code for this. Would love to see an example of this using Vertical Slice Architecture using features instead of use cases. Keep up the amazing work!
@nogafouz2174
7 ай бұрын
😀
Great video as always, a request, a video on setting up ci/cd with different envs (dev, stage, prod) from scratch for a react/next project would be total bomb at this point...
This is the way! Funny thing is this is how I do backend code in C#. Been getting in to nextjs and was like I need to organize this lol
Something you might noticed. If we are to add data access to other entities we need to add another data-access file to talk to db specifically for that entity... almost duplicate code. I usually use generics to pass entity type. Thou not sure if it's possible with drizzle api.
If you have the time to spend feel free to do this amount of abstraction, it's only over engineered if you have other priorities / work is paying you to deliver value and other features need to be delivered. 100% there are benefits of this.
Great content! Would you consider making tutorial similar to this?
@superurgmail
7 ай бұрын
Yes! I was thinking the same. Being self-taught, this (in depth clean architecture) is something that is really difficult to find (and make sense of). I'd be happy to pay for a course or comprehensive tutorial on this.
I don't think it is overengineering, especially for large apps. Very nice content!
Congrats for learning and sharing clean code and good practices to the community There somethings that I saw on your code and I would like to point out Careful to not use the entities as object literals. At 19:56 in line 127 you could have used a method for this, .increment() You should allow only methods of an entity to change it's internal state. Avoid setters, using setters you can easily break the internal state by passing an invalid value. Keep the business rules of an entity inside the 'rich methods' Also, there is a miss conception about entities internal state, you have a method validate, that should not exist A entity INSTANCE should be enough to know that that thing has valid state The validations should lie on the constructors, and on the methods, they have the responsability of keeping the valid state, otherwise they should throw So if you got in hands an instance of something, you can trust that thing has a valid state 14:20 yes that belongs to the entity. If you use only internal entity values, ask yourself what are you validating, then name your method like so. That validation could be way more verbose, and you would prefer to abstract that
@WebDevCody
8 ай бұрын
So you call validate at the end of all your methods that mutate entity state basically?
@versaleyoutubevanced8647
8 ай бұрын
@@WebDevCody No, say you have a class (Value Object on this case) that represents a month of the year. One of the internal value is the monthNumber, that has to be a number between 1 to 12. If you wanna set a default value when instantiate, the validation if(monthNumber12) throw should be in the constructor a nextMonth() method should contain some logic like if(this.monthNumber===12) throw It's a change of mindset, you don't post validate the action you performed, you can't even perform the action if it leads to a bad state this way you ensure the instance ALWAYS have a valid internal state, you should never worry about the internal state validity of an instance This is a DDD concept, and I learned it in Portuguese, so I may struggle to translate some terms properly
I do something very similar and love it. I have a seperate components folder for every different route(or page) of my app, like about, home, workouts, dashboard, profile, etc
I do the same thing. I usually use pages directory so I can't colocate files in the pages folder. So I mirror the route structure of pages inside my components/pageComponents directory. This allows me to colocate any related components in the ./Subcomponents folder right next to any component. Also, I just name the component file as index.tsx. That way it picks up the name of the parent folder, which is the name of the component. Super clean
@gadgetboyplaysmc
8 ай бұрын
Do you use Ctrl + P to search your files? I feel like searching index.tsx would be such a pain. You could always search the folder name, sure, but it might return results from the pages folder as well.
Damn you really have this figured out. Any good resources on this topic? The Clean Architecture book went a bit over my head 😅
@WebDevCody
3 ай бұрын
I'm still trying to figure it out after 5 years of using it professionally. There are some aspects to clean architecture I'm rethinking because I find it sometimes adds little benefit with a lot more complexity
Is this a good approach? /src/app/home -> page & layout /src/app/components/home -> components related to home /src/app/services/home -> API services used on home
I would love if you can make a video on how to properly deploy a NextJS app on GCP App Engine. Something that nobody made a proper video on.
I love clean architecture (even in the front with TDD so you don't manually test stuff all the time) I love to couple it with redux too as part of my core. Do you have stuff like that too or videos in preparation around that ? I'd love to see how you tackle it yourself since the few videos I've seen of you are of top quality
Awesome! I think it's better to validate entities using the constructor rather than having the client call a validate method and create another instance instead of modifying the existing entity. I prefer naming the class without using the term "entity." For example, "Item" can be considered as the entity, and "ItemData" can be used to manage data from infrastructure like a database or third-party API.
@WebDevCody
8 ай бұрын
I agree
It's similar to what we do in the .Net projects. Initialy it is slower to get everything together, but in the long run it's much easier to maintain and fix bugs.
I dont really think thats over engineering, you didnt cross the line. It's worth the readability, loved it!
To exapnd on this base video idea, if you added a products table. Would you also need to add a product entity/data-access/use-cases/etc ?
Finally, someone I agree with regarding the ui components dependencies 🤣
thats why i name it as shared instead of components and place the components needed in the app but in a directory based with index.tsx
Love the content cody! Would you guys say tRPC is still a valuable option for the backend? I feel like it gets difficult to manage when the project gets bigger
Great example, however it gets very complicated very quickly... Listen to what I encountered in a not-that-extensive project. How would you go about if you had multiple roles where each role can interact differently with the entities? Specifically what I recently had in a project, lets say we have a User entitiy with 2 different roles, but now we have a use case - if the user is an Admin then he can update their finance settings - where the finance settings are only a few fields of the User entity. Do you now create a separate Admin and User entitiy, or is it just one User (general user) entity? Because, although it's the same table, the "User" role should not have access to most of the attributes in that table. And from what I tried, if we put it all in a single entitiy, it's hard to separate what each role can do. In that same codebase we also had a case which we can maybe translate to your example. Lets say the entitiy for Item can now be created only by admins, but can be viewed and added to their cart by Users. Same question, are those 2 separate Item entities now or just one? On simple examples like what you have shwn it works great, but as more features are required this strongly feels like it would need kind of inheritance if we wanted to be consistent... but then we fall into the pit that is OOP and we kind of lose the beauty of React...
@CadisDiEtrama000
6 ай бұрын
would love a video on something more complex 😁😁
I feel like you shouldn't make setters and just make the variable public unless you need to manipulate what you're going to set it to, AND you don't need to manipulate the return value for the getter (if you have one), I also think that you should use `get X` (actual JS/TS getter instead of `getX` (method) and `set X` (JS/TS setter) instead of `setX` (method).
@Mathes881
8 ай бұрын
Normally, you could just add getters to private fields, although "setters" should be a method that has business logic inside with validation, although fields shouldn't be public to avoid mutation on that object anywhere, only in the methods with logic that needs those fields. For example in the video: Near 10:30, there should be, item.Increment, and inside that method validation and logic that increments.
Great video! You mentioned clean architecture - could you recommend any additional reading materials on this topic? I read 'Clean Code' quite some time ago. I'm guessing many of these concepts are derived from that book, right?
@WebDevCody
8 ай бұрын
Clean code is a decent one if you don’t follow it like gospel. I don’t read too many books honestly, I find just having a conversation with chatgpt the best approach to get past the fluff they often add into books
you should add some unit tests to really highlight the advantages of this approach. Although personally I feel like this is a relic of the old days where unit tests were all the rage. Doing a variable name change/adding a new property for an entity, for example, is gonna be a nightmare. You'll have to change it in so many places to keep it in sync.
@darialyphia
8 ай бұрын
That's why you have mapping from persistence / application / dto layers, so that yo ucan limit the blast radius of this kind of changes. If you don't use clean arch and stuff like that it's actually HARDER to refactor, especially if those changes include business logic. But this comes at the cost of more boilerplate and abstraction layers, so adopting those practices really depends on the project and the team. If the team isn't comfortable with clean arch, it will slow them down significantly and leave a bitter taste in their mouth.
Nothing was mentioned about type definitions (at least at the point I'm at) but I'm noticing most files have type definitions directly in them. So are you defining types exactly where they are needed? or is there any central location of types that are used in multiple locations? Wondering how that fits in with separation of conerns
@WebDevCody
23 күн бұрын
I’d put the types in the same file of the function that owns the type.
@Web Dev Cody here are my thoughts for what they are worth (if worth at all): Your approach goes somewhat on the opposite of what is recommended on next.js app router docs. Next.js has file based routing and so the approach of separating files by some imperative definition of "responsibility/what-it-does" can cause problems with the router and add layers of complexity that could be avoided by following the recommended approach of grouping files by their "domain/feature". @Theo has a take on this that I recommend you giving some thought. As I understand your approach goes in line with what the marked is used to do and have lots of theory behind, but I tend to look to the side that the modern days are pushing us into a different scenario on which grouping files by domain makes more sense on the long run.
@WebDevCody
8 ай бұрын
hot take: where you put files in your project has very little impact on maintainability - consistency is more important. Also, the core of what determines if something is maintainable is the interdepencies of the modules and trying to abstract layers where needed so that refactoring isn't a pain in the future. Additionally, if your team agrees unit testing is important, this also plays a role in how you structure some of your modules. I know you think the next docs are great, but point me to anywhere in the docs where they mention how to add automated testing over your next app - they don't. Take that information as you will, but I take it as a sign of they don't care about testing nor explaining good ways to structure your code to make it easier to test. At work I have a project that groups all files by "type". We have directories with over 200 files of type "Action", 200 files of type "UseCase". It's the last thing I think of when I say "man, this system is complex".
@wesleycoder
8 ай бұрын
@@WebDevCody Not a hot take at all, as I see this is where the market agrees, and I do to. Most teams just decide on which file/folder structure works for them based on their own abstractions and this was and will continue to be what works for most teams. And yes I may be biased towards the docs, but don't want to be bound by it, I'm just trying to understand the intent behind the docs, so I can avoid working against this intent. Also I may be biased about not giving the same value to automated tests as most of the market does, and this may be one of my mistakes. Thanks for expanding on your point of view, this definitely helps me understand the topic better.
@WebDevCody
8 ай бұрын
@@wesleycoder sure thing, also remember I work full time on a project with 500k lines of code and 10 devs working full time for 5 years, so my perspective on “good architecture” is scoped around that. If you are a one man team and don’t care about unit tests, then I think their docs are fine
Good job babe!
Hey Cody. Do you have a video on how to deploy a NextJS application on other platforms like gcp and etc.
@WebDevCody
8 ай бұрын
I've never used GCP, but I'm assuming you could just run it on a VM
can you make a full tutorial using this structure? also, can you share with us an open source github repo using this structure so we can learn from?
Alright I guess I need to make my video defending clean architecture
@WebDevCody
8 ай бұрын
You should
What's your view on using prisma vs drizzle for ORM. Your content is priceless ❤️
@WebDevCody
8 ай бұрын
they are both good, I'm trying to use drizzle for now
Is there a way to implement the new shared/wrapper layout.tsx in a NextJs v14 project but still use the old NextJs "pages" folder instead of "app"?
@WebDevCody
4 ай бұрын
Not sure
I like FSD (Feature Sliced design) approach, which is more clean:)
Is it possible to make it so your server actions have no access to the code inside of the data access directory besides a newed up singleton that conforms to a specific interface? Architecture is nice, when people actually follow it. I think making it so users don't have any access to the data access layer from the server actions is a good way to remind them that they need to follow architectural principles.
@WebDevCody
4 күн бұрын
Maybe a lint rule could do it
I like putting those components related to page.tsx under _components for each directory
So here's my question... say I want to apply clean architecture and have things in modules... like items, users, etc. In your items schema definition, you have a usersId which references the users.id field in the users schema. So this requires importing the users schema from a different module. In a modular file structure approach, how would you import this users.id into your items schema definition?
@WebDevCody
8 ай бұрын
I’m not too sure what you’re asking, but since entities live in the same architecture layer, they can import each other directly if needed
Something on top, you test the business logic far easier this way. You just need to pass mocks as dependencies.
@WebDevCody
8 ай бұрын
yup exactly, so if you're big on unit testing, it helps.
thank you mate i am on the correct path
Great video. Vid request. Can you do a video on controlled and uncontrolled components? This is one of those react concepts I have never really understood.
I am wondering if once you start using SST it makes sense to build your apis directly in api gateway and lambda. It’s marginally more complex but there is way more flexibility and you can easily have them access the AWS services too.
Nice - been doing something similar with my code for years.
This is so underrated!!
Love your content! One thing I've noticed is that your code blocks has some colored stuff indicating where it starts and ends, is that a vscode extension?
@WebDevCody
7 ай бұрын
rainbow indents I think the extension is called
Can you only remove one item at a time from the pantry? Your code looks like if you have 1 apple you can still remove 5 giving you -4 apples?
@WebDevCody
23 күн бұрын
I’d have to check. I haven’t touched this project in a whilw
Hi this is very helpful. Great Content! Would it be okay to ask what theme are you using in your VSCODE and also the fonts? It look so clean.
@WebDevCody
8 ай бұрын
bearded theme and bearded icons
Thanks for the great content! One question about the use cases. I've noticed in every use case you perform authorization check. Does this type of logic generally part of every use case? Also, considering that usually one would also authorize user on a routing level, isn't that redundant? Thanks
@WebDevCody
8 ай бұрын
Ultimately you’ll end up adding some type of authentication or authorization check somehow. I find the code much easier to follow if you keep it redundant and imperative compared to trying to find a cute middleware or decorator pattern which obscures the core business logic of the use case.
Couldn't pay me to write Dto's by hand when developing full stack Typescript when there's tools like tRPC
Having “entities” (classes with methods, etc.) is going towards an OOP approach vs a more FP approach, correct? I find them interesting and seemingly useful, but I haven’t come across them or used them in my own React-based applications yet. I have essentially the “dto” objects passed around in my app (after an adapter/mapper converting BE format to FE format), and then use separate “helper” functions as needed (rather than methods on a class). What are your thoughts on the different approaches?
@WebDevCody
8 ай бұрын
I think clean architecture mainly applies mainly to your backend / database logic. Applying this to react would probably mean using redux or mobx. Keep all logic and state out of your ui components would be the way to apply clean arch to the react layer
@aaronmotacek9343
8 ай бұрын
@@WebDevCody I’ve recently shifted to breaking my react components into a “data handling” sort of layer/wrapper and then a UI/View later, which seems to be a step in the right direction (seems to allow for easier testing, ability to utilize StorybookJS easier, etc., as I can then use just the UI/View component for those things). I’d enjoy a video on that concept (vs having it all within a single component/file, which is the more natural way for a beginner to structure things I think)
Maybe my question is a little dumb but is this approach considered functional programming or object oriented programming?
Nice structure 👌🏼
Hm I dunno about this Cody. If you know from the get-go that you'll need this level of architecture for your logic (DTOs, repositories, entities etc.) I would probably put it in NestJS straight away and have NextJS be a dumb frontend. In any other case, I would start out with some good-enough seperation of concerns in NextJS and just migrate the logic to NestJS if necessary.
should change the title to “applying over engineering to my next.js project”
@WebDevCody
8 ай бұрын
😉
@OA00000
8 ай бұрын
Very good content regardless, is cool to see how even you where uncomfortable with the amount of code/abstractions at the end 😂
@OA00000
8 ай бұрын
imo this kind of things are just madness in any “frontend” project. If you really care and need this level of abstractions and separation of concerns, just have that in a completely separate API and use the endpoints in your frontend instead of talking directly to a DB
can you create a tutorial for tanstack table sir? with some advanced api usage really stuck with it
Everything looks pretty straight forward except the DTO part. It just feels a redundant abstraction upon ORM. The ORM itself is already a DTO. I felt like the DTO part makes more sense if you are doing SQL calls without any ORMs. I actually saw similar pattern when people create a center API entity on top of every API calls. Sometimes it's good, but most of times are really bad. But I do feel your internal struggle when you mentioned the DTO.
@WebDevCody
8 ай бұрын
Yeah I guess converting the drizzle return value to a dto might not be necessary
@doc8527
8 ай бұрын
@@WebDevCody but I think if you want to remove Drizzle later, then the DTO might make the migration easily.
I really appreciate this video and personally learning a good amount from it so thank you. Wouldn't it make more sense to instantiate an initial class that has all the context of different methods and then use that in your actions instead of always importing all the methods into context in each server action? Re: @9:53 ish
@WebDevCody
8 ай бұрын
We do that at work and we ended up with a file with hundreads of methods on it which causes tons of issues with performance when running unit tests over our interactors. Every time jest runs it has to reimport hundreds of modules and it takes like 7 seconds to initialize a test file. This would also apply to performance issues with next, if every route needs an object with hundreds of imported modules, every page will become huge
@paulwong7224
8 ай бұрын
@@WebDevCody YES this is the exact issue with using a ton of classes. I appreciate that you addressed this. Thanks again.
So is this a something that only senior frotend should know or even middle? I want to know your opinion
It might be me doing things wrong. But as far as js/ts goes most of clean architecture concepts will cause you more issues than it would solve. An example would be using entities classes but then you fall into the issue of state serialization, passing entities from server components to client components. A lot of redundant code... Etc
@WebDevCody
8 ай бұрын
I don't think entities should be leaving your business layer into your next code, you should be using a DTO for that. It's the same as if you were invoking an API to get data; you only get back primitives.
This video came at such a perfect time, thank you for making it!. I'm currently refactoring my code to include a data access layer after reading the security blog post from next.js and I was really confused about how to set it all up. At 9:15, I'm a little confused where you pass in the data layer as context in the use cases. That seems to be used with server actions, how would you do this if you're only using api routes with next.js? You were seperating your server action from your business logic, how would you seperate your api from your business logic?
@WebDevCody
8 ай бұрын
in next you'd have your router handlers, and you'd need to invoke your use cases from your router handlers. It's the same deal, take your request body / query / params and pass them as arguments to your use case, and inject any dependencies into the use case from your request handler
@teamvashmmo3218
8 ай бұрын
Thanks so much, that makes sense!@@WebDevCody
Where do you suggest I learn more about this Clean Architecture?
so clean architecture is basically creating layers in your application through abstracting the code?
Any reason to not have a _components folder under each route to keep it clean? I prefer having only the special Next.js files under the actual route and everything else in ignored folders.
@WebDevCody
8 ай бұрын
That works fine. I may try doing that as well
Where can I read more about clean architecture concept?
@WebDevCody
8 ай бұрын
I'd start with the book "clean architecture". chatgpt is really useful as well
Same storing the same components inside components folder... and page depended components inside that page route _components folder
I am a bit lost when it is client and when it is server. For example when creating a new item, the pantry-tracker/src/app/dashboard/_actions /create-item-action.ts is this running on client or server? I am following it till updateItem in src/data-access/items.ts but it is not clear to me. Can you please explain this? Looking good man.
@WebDevCody
8 ай бұрын
server actions run on the server. next abstracts the code by allowing the server action to be invoked via a POST request, and calling the server actions from the client component does an HTTP POST request for you under the hood.
Hey Cody maybe you've answered this in another video but after finishing a pages router project, i have decided to start a new project with T3 and the app router and I have a question. Do you think that trpc is still needed or is there a better way to build endpoints now
@WebDevCody
8 ай бұрын
I still think tRPc is a great solution, but recently I’ve been just using server actions and RSC to fetch data for my pages
@justanotherhero8981
8 ай бұрын
@@WebDevCody I've been working on it the past week and I slowly came to the realization that tRPc is not needed, as what I ended up doing now is using the tRPc queries and mutations inside of the server actions which so I guess why not directly write the code in the server actions.
am i the only one that thinks thats a crazy amount of code to implement something so simple?
@JohnBuildWebsites
8 ай бұрын
No. Desperately rewatching to understand what I missed, but I am still not understanding the benefit, over just using Drizzle and zod on the server.
@WebDevCody
8 ай бұрын
no, that's a normal reaction. Like I said, this is for projects where you might have lots of developers pushing features and modifying existing logic. As the system gets larger (imagine 5 years of code), it's very easy for devs to start copying + pasting logic from one server action into another and then your business logic is duplicated everywhere in your code base. So then when your product owner says "I want to allow decrement to be negative (to act as debt), your team copied and pasted the decrement logic in many different places and now it's a pain to figure out where it all needs to be updated and fixed. Obviously this is a simple example, but at work we have a "CourtCase" entity with over 70 fields, and many of those fields are cross dependent on other fields. So without following this type of pattern, a developer might modify modify a field on and object and saves it to the database then your database might have a bunch of invalid data because no one was actually validating the entities in your project, then when a user tries to load the court case to view details about it everything crashes because your database has invalid data. hard to explain in text but there are good reasons to do this stuff
@geraldseydoux2252
8 ай бұрын
@@WebDevCody Thanks for the detailed explanation, this is the first video I've seen yours so i assumed you were targeting beginners but it seems your audience is more junior developers with some experience.
@h4nto772
8 ай бұрын
@@geraldseydoux2252 he has some extremely good videos for beginners if you scroll through his channel. lately has moved to some little more advanced stuff. anyways whatever your level might be i suggest you to have a look at his channel cause the topics he deals with are a lot and very interesting and his way of teaching is one of the best i have ever seen on youtube (especially his approach of live troubleshooting and analysis).
Hi Im a junior dev who studied C# in the past. This architecture feels extremely familiar with dotnet. Is the "use-case" equivalent to "services" in dotnet?
@WebDevCody
8 ай бұрын
I’m not sure I haven’t used dotnet
@teamvashmmo3218
8 ай бұрын
use case/user story is equivalent to services or domain layer
I notice that you are throwing errors in your use case layer. Where in your code do you catch these?
@WebDevCody
4 күн бұрын
Probably in the server action if I’m using next-safe-actions of zsa
All my projects are build with Nextjs Frontend and nestjs server for backend. How much will you rate this setup?
@WebDevCody
8 ай бұрын
Nest is fine
Have you caved in and started using the /app directory?
@WebDevCody
7 ай бұрын
yeah I've been using it
@FunkyByteAcademy
7 ай бұрын
@@WebDevCody I'm still hardcore on this t3 vibe. Was fiddling with the app router for a few months but just not a fan of the new system designs.
So is the front end and backend both here in one code base?
What if I have 1 component that used on 2 pages only, than what ? Moving to components dir isn't correct, cuz it used in 2 places
@WebDevCody
8 ай бұрын
if it's used in two places, it's a shared component and should live in a shared location, such as src/components. You could also try to co-locate the component if that component is used only in a certain route and maybe one of it's child routes.
Hello! Can you share your vscode profile? Really like your vscode Settings! Thanks very much!
Hey Cody! Could you please provide the names of the icons and theme extensions, if possible? I appreciate the content, man!
@WebDevCody
8 ай бұрын
bearded theme stained blue with bearded icons extensions
Awesome,
Also bro can you make how you handle errors in nextjs
will you show us how to do this in express api?
waiting for devops from you
I never had a real developer job with a team but at college something that always bugs me is.. - if I am a front end dev and need to check if a user account registration was successfully sent to database, or if a user modified something on his account (so rewriting information to database), how can I test this functions and see that was successfully rewritten but without modifying the real database? I have this question because I am working in a project for an apprenticeship services and they use Firebase, atm I am using Firebase emulator to test my functions and anything related to database and even authentication, but how do I test in the real one?
@luishenriqueandradepellizz680
8 ай бұрын
I am asking this because normally a person developing an app is always deleting information from database after writing, vice -versa. Firebase has the emulator, but if a dev is working is a project that was already there and in production, how can you test this things?
@luishenriqueandradepellizz680
8 ай бұрын
Sorry for being stupid, I am just noob
@WebDevCody
8 ай бұрын
I’ve never used firebase or the emulator you are talking about, so I’m not too sure.
@luishenriqueandradepellizz680
8 ай бұрын
@@WebDevCody but could you, one day, make a video about how would a developer test codes that is related to write on database without affecting the mai database that is on production. It is really hard to explain what I am trying to say as English is not my first language Cody. Sorry for taking your time
The last bit feels like overengineering. If it is an enterprise system, it should not be doing the backend in the front anyway :D
@WebDevCody
8 ай бұрын
touché 🤣
Can i know the name of your theme code
Doesn't having components inside the folder make the Next treat it as a page?
@WebDevCody
8 ай бұрын
No, it only cares about specifically named files
Why when you added cheese in a first seconds of your video, your all table including tabs updates? It should update only a row not a all component. Take a look on a profiler it something weird going on there
@WebDevCody
8 ай бұрын
all of the tabs are using the same state with a filter which is why they all updated I think
What theme do you use? And font?
what component libary do you use ?
@alisalimli
8 ай бұрын
probably shadcn ui
@WebDevCody
8 ай бұрын
shadcn ui
@omi.
8 ай бұрын
@@WebDevCody Thanks a lot for this amazing video! Could you please tell me what do you use for displaying charts in a dashboard? Have you tried Tremor and shadcn/ui together?
@bughlinjo9372
8 ай бұрын
@@WebDevCody 👍👌
what's the file icon you use sir?
Could this be applied to DDD as well?
how do you get an online postgress?do you use planetscale?
@WebDevCody
8 ай бұрын
for postgres, I often reach for supabase or railway, for mysql I use planetscale
@UwU-dx5hu
8 ай бұрын
@@WebDevCody thank you😊
Great