After 20k lines my codebases started to become harder to manage. Watched this and decided to give it a go since i also wanted to refactor some parts. After 30h of work and 2 days, i am pleased! Ty
Really helpful when you're facing the exact problem of maintaining a pretty large and complex application .. . And cherry on the cake is that boundary eslint module which I discovered today. Thanks for producing all these excellent videos !
Guys, take a look into FSD methodology (Feature Sliced Design). It uses pretty much the same approaches. Tried to build several project using it, and really loved it.
Since nobody is commenting on your absolute boss-level excalidraw diagrams I will. This came up in my feed and I just came for the diagrams. Organise your code however makes sense for the folks that work on the code. This looks fine, but the real win here is in Excalidraw presenting information.
Hi Kyle, As a beginner and struggling to organize my files since English is my second language where it takes time to think a name of a file or folder, this is a really HUGE help for us
Try the rubber ducky-ChatGPT approach: start by telling it what exactly what your file/variable/funcion does in a few sentences. The more precisely you describe it, the better. You'll either have come up with a good name for it yourself by the time you hit enter or ChatGPT will help you out with that. Then you can ask ChatGPT to refine it for you by asking for variations and explanations for nuance when using other synonyms. I'd say naming things is mostly hard when you don't know how to tackle the problem, but this approach is usually helpful and gets you in the right direction.
You've just described is how Angular has been doing this for years. A textbook example of structuring medium and large-sized Angular applications that scale well. This is the proper way to do it.
I had my Sass files structured this way 10+ years ag. I think this is the setup that everyone gravitates to as the complexity and feature set rises. You start thinking in modules/features first before responsibility.
This is more like a clean architecture, not just like the Angular method. We have core, domain, and infrastructure. It’s very clear and well-explained. The methodology is called feature-first, but it aligns with clean architecture principles.
Actually, I do almost exactly the same in my projects and even wrote a Medium article about it. But I didn't know this ESLint plugin to enforce this rules in my team. Thank you for sharing.
That's it! I use the same structure, the folders have different names, but it's the same idea. In many places, I was treated like a madman by people who wanted to implement clean architecture in the frontend (domain, infra, presentation, etc.). That's crazy, the frontend needs to be simple. And this structure works really well. People who advocate for complexity in frontend architecture talk about business rules and blah blah blah, but if there's any business rule in the frontend, it's wrong; business rules should stay in the backend.
Fantastic! Really important stuff, thanks for covering this Kyle. It's sad and overwhelming as a junior of a super complex codebase that nobody I ask has a competent understanding of any of our apps file structure because it grew too big and is now too costly to refactor without causing massive regression costs.
This is brilliant. I always struggle on how to make whole team follow the rule of our planned folder structure. Eslint boundaries is very useful. Thanks alot. You deserve more than this. If it is possible, I would love to see how you organize and manage role based or attribute based access control along with the feature style folder structure as well
If you're using domain driven design you probably should use a folder structure like this. If you're not, you're just making things harder for yourself and everyone else. A structure like this also helps in making it clear what's generic utility and what's domain/feature specific.
I strongly disagree - in DDD you shold have folder for domain (which contains other folders: usecases, ports (in/out), entities, valueObject, events) and adapters (for infrastructure: inbound/outbound like react/vue/angular views (related to usecases), storage/events provider (eg ngrx), api-services etc. - we not see such structures here.
I would like to see the structure for monorepo that contains backend and frontend logic with a mobile app and additional things like auth interaction with databases and more
perfect timing. I currently have domain driven architecture where all my business logic flows through that specific domain but I should probably extend that to include all the ui too!
Yeah I use a version of this, based on the Nx product structure. Its pretty good, especially to just have a plan that you know straight away where to put everything. But the problem I have is that the shared folder gets really messy still, and components can get lost really easily. I'm thinking about scrapping the shared folder and just having a shared folder or notation in each feature. The problem is that you have a component and then one other section needs to use it, so it has to get moved to the shared folder. For example, I have a library feature, which is basically a blog feed in the app. But then the report page needs to integrate posts into it. And now the blog display functionality has to be moved into shared. When its a little util component its easy to forget it exists. The shared cannot be organised much because if you nest it away you then have to go through every folder to discover if something has been built. It needs to have some extra-namespaced name to really make it clear what it is with no context. But if its cross cutting it has to have a vague name. And as the folder grows its just the same problem coming up again - everything is muddled together and you have to go through every component to find what you need and / or not reinvent the wheel. I don't know what the solution is. Perhaps at some point you just have to start making duplicate wrappers so the component can "live" with the feature, but simply contain the shared component. Or maybe an LLM will step in soon and become a search engine for your project.
Would love to hear the answer, cuz at some point everything becomes so interconnected it moves to global folders. If anyone has a solution, please share
Coming back to this today perhaps it's just not easily solvable with just folder structure. It needs some meta layer over the top, like tagging the folders. And then also some auto wrapping technology which lets you wrap the generic shared components and keep them in the feature folders that need them as wrapped versions with the same name. And then a mini LLM. Why not get some ai involved. It's 2024 right? AI which can direct you to the existing components without having to grow each item in the shared folder.
The real answer to this is that your app architecture needs fixing, not that the folder structure is wrong. You would need to decouple your components in whatever way makes sense for your project
This is very similar to how the team I work on organizes our app's code, we even use the same boundaries eslint rules. One thing that you didn't touch on in the video which would be a good topic to dig deeper into is the "features cannot access other features" boundary rule and showing how this rule forces the use of composition within the app boundary in order to avoid the spaghetti dependency hell between features.
I'd be curious to know how you'd deal with a situation like this: If I have various analytics that I'd like displayed on an admin-panel for my application... Would you do: features/feature1/analytics? Or features/analytics? Because technically there could be analytics shared by multiple features, such as user stats regarding 3 other features.
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
Amazing! Thank you for the charts and diagrams! That ESLint piece is sweet! And yes, I'm using Next.js 14 app router with a newer project that is in the early fun stage. So I'd love to see those specifics 💖
Would be great to see this going a step further and expanding this structure to a pnpm multi package(monorepo) project. Some of those features could be reused across multiple apps if they are extracted into their own package which would have the same recursive folder structure. You would have similar rules for the packages itself.
This is sound advice no matter the framework or language even. Its a lightweight Domain approach(which is frankly just enough DDD lol) and I've been using for nearly a decade. Anyone starting over in Angular world NX tooling has the boundries approach built into the tooling and it works well. I can't tell you how many times I've had to reject a PR from a new joiner because someone editied the rules on imports and thought that was the solution. There really is no better way to manage a large project than by feature. Depending on the framework you may even be able to skip some sub folders and rely on filenames.. Bend it to suit but make sure you try to protect the vertical slicing of features. If you really have to jump across and cant avoid then make a rule for 'api' (or similar name) and explicitally export the limited functionallity. Then you have a known entry point.
In my current job we have been working with a MVCS folder structure, now that we have been working with this project from more than 1 year from the begin, this are getting harder and harder to maintain or add new features, I think this folder structure would make dev experience way easier, for now I will tried it in a online shop project I want to build
Thanks for sharing Kyle. But i was wondering if I need some logic for example of user, the current user id and a product id to create an order. I would have to break the folder structure to access some user logic on the product page or have duplicated code. Do we have a solution for it?
Thank you for this! This is great for smaller projects but for larger ones going with this method would be kind of reinventing Nx monorepos with Domain Driven Design. With those you get extra benefits like: - Being able to add more related apps in 1 project and share dependencies between them (optional) - Using Nx affected to run only the e2e/component level tests that are relevant - Easily keeping the dependency graph correct without circular deps or tight coupling + many more It's always better to use industry standard frameworks instead of reinventing our own.
@@IncomingLegend I used to dislike them too but for large projects they're a godsend. For example my company has a SaaS product that's used by massive clients like Samsung, Mitsubishi, BP and Nasa. We have thousands of e2e tests to ensure that our changes don't break customers pages (these e2e tests need to run on 2 environments: SharePoint SE and SharePoint Online). Without Nx monorepos and Nx affected we have to run the whole test suite every time we want to make a release which takes 8+ hours (imagine the tests fail and we have to fix the issue and rerun too) With Nx monorepos + Nx affected we are about to run only the tests that are related to the part of the product that changed. We can also run the relevant e2e tests automatically on PR creation. There's a reason massive companies like Facebook and Google use monorepos.
I'm extremely waiting for the large project you want to publish on UA-cam, every time I saw your video, I learn a new thing. About 75% of my programming knowledge come from your video just because I learn a little from others before you. I know this is hard to making video for us but I want from you to help us Kyle ❤❤❤❤❤. I hope you succeed more and more in your life.
Everything is clear, but I have one question. However, the features/ folder obviously refers to features. If we want to separate components that we are going to use in for exmpl. Sidebar, HomePage, or other sections that aren't features, where should we place them? Would it be a good idea to have a modules/ folder?
Absolutely love the diagrams and the way you have shown folder structure and user stories in the same example. My only complaint is that you scroll to the left as your complexity increases instead of panning to the right like normal English reading left to right lol. It's literally personally choice and inconsequential so totally ignore this and keep putting out awesome content.
What if you have 2 features that have common util functions but should not be used outside of these 2 features? Would you go for nested features? More specifically my app has 3 top routes, one for the public, one for admin console and one for an organizer console. The organizer console uses today some functions that the admin also uses but never intended for the public routes. I am tempted to copy these few functions to allow them to be modified independently.
very interesting, I'm already defining my folders this way. Global Objects and "business ones". Then I'm adding a "business scenarios" that links everything all together. For example "scenario_userlogin, scenario_cardpayment, ..."
Hexagonal Architecture is my go-to. 3 folders: domain, application and infrastructure. That's it. Business logic and entities in domain. UseCases/Services in application, and DB, API, I/O... in infra. Rinse and repeat for each project
Hey Kyle I really love your work. The requested video is How can we document any project from scratch technical documents for front-end and backend. Thank You
The problem with this structure is that many classes will overlap different features, so now it get complicated to attribute them to a folder. So in large projects, it can get a little messy. I prefer to organize by abstraction level (entities, factories, services, gui, libraries). With the IDE, it is easy to search and find a file (by its name or content).
Just a basic apps/libs/api in a monorepo will do wonders if they are segregated as packages. But they should not set in stone. Folder structures will constantly change according to the need at the time
What happens in situations where you have to reference other features. Let's say you want to delete a user to comply with regulations you would have to delete also products added by that user, so how would you structure that?
I can see the advantages, but it's not one sided either: 1 - Get use mentally to this workflow can take time and is not straight forward based on previous habits; 2 - You need some time to setup your eslintrc file, and to think carefully beforehand about your structure; 3 - Decide how to separate your files and folders. For instance, why you put login in app in the first place? I could see it in either shared or even features, for instance; 4 - If you work iin a team, you will have to talk about that shift, and it might simply get rejected.
Hmm I wrote a big reply about this but its not showing now I came back to edit it. I guess basically, all I wanted to say was, you don't decide where to put it, the app does. The first time you need to use a component in another feature, you refactor it out into the shared folder. It organises itself.
Login refers to the page not to the functions, etc.. Everything in the app folder are the pages in your website, just code to the render the different components
My team started using the Russian doll method 2 years ago, and I'll never go back. Put every file that you create inside a folder of the same name. In each folder, you will only have that file, and then other folders (containing files that you created inside the parent file).
@@MadeInJack It's just one less thing to worry about. The file structure is shaped independently, and it's easy to navigate. We are very explicit with our file naming.
I have a request - I would like to see a project which uses a separate backend - exposed with APIs (like python, go, java or even js) but separate. As backend dev, if I want to build frontend from scratch I would love to learn from a project video. The backend project videos make bare minimum UI, and frontend projects make bare minimum backend, or use full stack framework like next js which doesnt help in making projects if backend is separate. If you have already made a video on this or can give me any reference that will also be good. There are some concepts which are not easy to understand with like - auth, have the frontend, backend state same for an object, how to handle APIs where you need to call multiple apis to achieve a single data feature on frontend.
After 20k lines my codebases started to become harder to manage. Watched this and decided to give it a go since i also wanted to refactor some parts. After 30h of work and 2 days, i am pleased! Ty
Really helpful when you're facing the exact problem of maintaining a pretty large and complex application .. . And cherry on the cake is that boundary eslint module which I discovered today. Thanks for producing all these excellent videos !
Agreed - the eslint plugin config is new to me and 100% helpful - thanks!
Guys, take a look into FSD methodology (Feature Sliced Design). It uses pretty much the same approaches. Tried to build several project using it, and really loved it.
looks good, will give it a try
@@IncomingLegend yeah, and you can adopt it to your needs, and use whatever you like more from it
how about circular dependency?
@@arvi8843 you can setup linter for checking for it too. but usually it is not a problem in case of using FSD
Feature-Driven Development (chatgpt)
Since nobody is commenting on your absolute boss-level excalidraw diagrams I will. This came up in my feed and I just came for the diagrams. Organise your code however makes sense for the folks that work on the code. This looks fine, but the real win here is in Excalidraw presenting information.
^^^^^^^
anyway you can share the excalidraw? or some screenshots
maybe in a quick blodpost
EDIT: nvm! found it in the docs folder in the repo
I'm just about to start a large complex project. Now I'm not worried about the folder structure. This is pure gold 💪
Cody and Kyle are the best web dev tutors on yt
Hi Kyle, As a beginner and struggling to organize my files since English is my second language where it takes time to think a name of a file or folder, this is a really HUGE help for us
Even if English is your primary it is always hard to name files, folders and variables. Might be the hardest part of development to be honest.
Naming things is hard when you're new. It's an acquired skill. You'll get better with time! 😊
Try the rubber ducky-ChatGPT approach: start by telling it what exactly what your file/variable/funcion does in a few sentences. The more precisely you describe it, the better. You'll either have come up with a good name for it yourself by the time you hit enter or ChatGPT will help you out with that. Then you can ask ChatGPT to refine it for you by asking for variations and explanations for nuance when using other synonyms.
I'd say naming things is mostly hard when you don't know how to tackle the problem, but this approach is usually helpful and gets you in the right direction.
You've just described is how Angular has been doing this for years. A textbook example of structuring medium and large-sized Angular applications that scale well. This is the proper way to do it.
Also Django.
I also felt exactly same. I like angular way of organizing files tho
I had my Sass files structured this way 10+ years ag. I think this is the setup that everyone gravitates to as the complexity and feature set rises. You start thinking in modules/features first before responsibility.
This is more like a clean architecture, not just like the Angular method. We have core, domain, and infrastructure. It’s very clear and well-explained.
The methodology is called feature-first, but it aligns with clean architecture principles.
I'd be interested in seeing a NUXT implementation of this. Great Video. Thank you for taking the time to produce it
You can use layers in Nuxt
ُThank you so much Kyle, BTY you're the only youtuber that I watch his video with the normal playback speed :)
i always watch at X1.5, you're a simp
Actually, I do almost exactly the same in my projects and even wrote a Medium article about it. But I didn't know this ESLint plugin to enforce this rules in my team. Thank you for sharing.
That's it! I use the same structure, the folders have different names, but it's the same idea. In many places, I was treated like a madman by people who wanted to implement clean architecture in the frontend (domain, infra, presentation, etc.). That's crazy, the frontend needs to be simple. And this structure works really well. People who advocate for complexity in frontend architecture talk about business rules and blah blah blah, but if there's any business rule in the frontend, it's wrong; business rules should stay in the backend.
Exactly what I wanted to begin my Lead Management System Project ❤
Thnks Kyle....🎉🎉
developing can get really complicated with just one change... thanks for simplifying it!
Fantastic! Really important stuff, thanks for covering this Kyle. It's sad and overwhelming as a junior of a super complex codebase that nobody I ask has a competent understanding of any of our apps file structure because it grew too big and is now too costly to refactor without causing massive regression costs.
TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)
Thank you for this, this improves scalability for my projects. Both web app and game dev
This is brilliant. I always struggle on how to make whole team follow the rule of our planned folder structure. Eslint boundaries is very useful. Thanks alot. You deserve more than this.
If it is possible, I would love to see how you organize and manage role based or attribute based access control along with the feature style folder structure as well
This is like domain driven design in the form of folder structures.
If you're using domain driven design you probably should use a folder structure like this. If you're not, you're just making things harder for yourself and everyone else.
A structure like this also helps in making it clear what's generic utility and what's domain/feature specific.
I strongly disagree - in DDD you shold have folder for domain (which contains other folders: usecases, ports (in/out), entities, valueObject, events) and adapters (for infrastructure: inbound/outbound like react/vue/angular views (related to usecases), storage/events provider (eg ngrx), api-services etc. - we not see such structures here.
I'm sold. Time to spend a week refactoring everything!
Better wait for the next video, youtubers tend to discover the next big best thing minimum on a weekly basis for clicks
This is really PURE GOLD!
Thanks. This seems great. I would also like to see a NextJs version please
Looking Forward to the NextJS Folder Structure. Would be great if you also add role permission handling things folders.
Bro never failed to deliver. Love you man.
I am up for nextjs video
I would like to see the structure for monorepo that contains backend and frontend logic with a mobile app and additional things like auth interaction with databases and more
monorepos suck
@@IncomingLegend agree but needed for big projects, you don't wonna create many repos and manage them separately
I tried feature based folder structure, what i liked the most was the time it saved, which i usually spent solving merge conflict.
Great video. I want to see the next version. With more folders like caching, middleware and all.
perfect timing. I currently have domain driven architecture where all my business logic flows through that specific domain but I should probably extend that to include all the ui too!
This is the type of content I love to see. Thanks for going over practical examples and showing full config. Really insightful
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
Yeah I use a version of this, based on the Nx product structure. Its pretty good, especially to just have a plan that you know straight away where to put everything.
But the problem I have is that the shared folder gets really messy still, and components can get lost really easily.
I'm thinking about scrapping the shared folder and just having a shared folder or notation in each feature.
The problem is that you have a component and then one other section needs to use it, so it has to get moved to the shared folder. For example, I have a library feature, which is basically a blog feed in the app.
But then the report page needs to integrate posts into it. And now the blog display functionality has to be moved into shared.
When its a little util component its easy to forget it exists. The shared cannot be organised much because if you nest it away you then have to go through every folder to discover if something has been built.
It needs to have some extra-namespaced name to really make it clear what it is with no context. But if its cross cutting it has to have a vague name.
And as the folder grows its just the same problem coming up again - everything is muddled together and you have to go through every component to find what you need and / or not reinvent the wheel.
I don't know what the solution is. Perhaps at some point you just have to start making duplicate wrappers so the component can "live" with the feature, but simply contain the shared component. Or maybe an LLM will step in soon and become a search engine for your project.
Would love to hear the answer, cuz at some point everything becomes so interconnected it moves to global folders. If anyone has a solution, please share
@@arinovilyas4986 Commenting so i'm also alerted if someone thinks of it
I have the same thoughts. I think a "shared" folder that exposes functions that would be for a feature, but can be utilized in another, can be placed.
Coming back to this today perhaps it's just not easily solvable with just folder structure. It needs some meta layer over the top, like tagging the folders.
And then also some auto wrapping technology which lets you wrap the generic shared components and keep them in the feature folders that need them as wrapped versions with the same name.
And then a mini LLM. Why not get some ai involved. It's 2024 right? AI which can direct you to the existing components without having to grow each item in the shared folder.
The real answer to this is that your app architecture needs fixing, not that the folder structure is wrong. You would need to decouple your components in whatever way makes sense for your project
This is very similar to how the team I work on organizes our app's code, we even use the same boundaries eslint rules. One thing that you didn't touch on in the video which would be a good topic to dig deeper into is the "features cannot access other features" boundary rule and showing how this rule forces the use of composition within the app boundary in order to avoid the spaghetti dependency hell between features.
Modular setup is what I'm practicing right now.
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
Looking froward to the NextJS Folder Structure video.
Feature Sliced Design is the answer guys. We adapted it at work and 2+ years in it works wonder.
I'd be curious to know how you'd deal with a situation like this:
If I have various analytics that I'd like displayed on an admin-panel for my application... Would you do: features/feature1/analytics? Or features/analytics?
Because technically there could be analytics shared by multiple features, such as user stats regarding 3 other features.
Theo can't be mad this time.
Nice vid 👍
Feels like a demo for eslint boundaries demo and it’s really cool. if I introduce to my team, they might crucified me.
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
Amazing! Thank you for the charts and diagrams! That ESLint piece is sweet! And yes, I'm using Next.js 14 app router with a newer project that is in the early fun stage. So I'd love to see those specifics 💖
I like the features -structure, will like your super long 7 hrs video tutorial to cover that :)
Thanks for including a github link!
Absolutely need a next.js version of this video!!
Brilliant Great explanation. The ESlint is amazing, just what I need. And yes very interested in a specific version of this for NextJS.
Would be great to see this going a step further and expanding this structure to a pnpm multi package(monorepo) project. Some of those features could be reused across multiple apps if they are extracted into their own package which would have the same recursive folder structure. You would have similar rules for the packages itself.
This is sound advice no matter the framework or language even. Its a lightweight Domain approach(which is frankly just enough DDD lol) and I've been using for nearly a decade.
Anyone starting over in Angular world NX tooling has the boundries approach built into the tooling and it works well.
I can't tell you how many times I've had to reject a PR from a new joiner because someone editied the rules on imports and thought that was the solution. There really is no better way to manage a large project than by feature.
Depending on the framework you may even be able to skip some sub folders and rely on filenames.. Bend it to suit but make sure you try to protect the vertical slicing of features. If you really have to jump across and cant avoid then make a rule for 'api' (or similar name) and explicitally export the limited functionallity. Then you have a known entry point.
You're killing it with the unique content ideas as usual! Thanks Kyle
super interesting! Having a good structure to avoid refactoring every time the project grows. Thanks a lot Kyle ❤
Wonderful, thanks a lot for this detailed video.
In my current job we have been working with a MVCS folder structure, now that we have been working with this project from more than 1 year from the begin, this are getting harder and harder to maintain or add new features, I think this folder structure would make dev experience way easier, for now I will tried it in a online shop project I want to build
Thank you Kyle!
Thanks for sharing Kyle. But i was wondering if I need some logic for example of user, the current user id and a product id to create an order. I would have to break the folder structure to access some user logic on the product page or have duplicated code. Do we have a solution for it?
This is nice, going to change the structure of my project. would be nice to see a nextjs setup with this :)
this' what i really need. thanks a lot kyle
Thank you for this!
This is great for smaller projects but for larger ones going with this method would be kind of reinventing Nx monorepos with Domain Driven Design. With those you get extra benefits like:
- Being able to add more related apps in 1 project and share dependencies between them (optional)
- Using Nx affected to run only the e2e/component level tests that are relevant
- Easily keeping the dependency graph correct without circular deps or tight coupling
+ many more
It's always better to use industry standard frameworks instead of reinventing our own.
monorepos suck
@@IncomingLegend I used to dislike them too but for large projects they're a godsend.
For example my company has a SaaS product that's used by massive clients like Samsung, Mitsubishi, BP and Nasa.
We have thousands of e2e tests to ensure that our changes don't break customers pages (these e2e tests need to run on 2 environments: SharePoint SE and SharePoint Online). Without Nx monorepos and Nx affected we have to run the whole test suite every time we want to make a release which takes 8+ hours (imagine the tests fail and we have to fix the issue and rerun too)
With Nx monorepos + Nx affected we are about to run only the tests that are related to the part of the product that changed. We can also run the relevant e2e tests automatically on PR creation.
There's a reason massive companies like Facebook and Google use monorepos.
I'm extremely waiting for the large project you want to publish on UA-cam, every time I saw your video, I learn a new thing. About 75% of my programming knowledge come from your video just because I learn a little from others before you. I know this is hard to making video for us but I want from you to help us Kyle ❤❤❤❤❤. I hope you succeed more and more in your life.
saved the day with this vid
Great video let’s do this for a backend in node and express
😊
thank you for very pro contents about our comunity. and please make the nextjs specific folder structure video.
Super useful !!
That looks amazing!
Great video, thank you
Everything is clear, but I have one question.
However, the features/ folder obviously refers to features. If we want to separate components that we are going to use in for exmpl. Sidebar, HomePage, or other sections that aren't features, where should we place them? Would it be a good idea to have a modules/ folder?
I would *love* to see the next is specific version of this video.
Great explanation!
Absolutely love the diagrams and the way you have shown folder structure and user stories in the same example.
My only complaint is that you scroll to the left as your complexity increases instead of panning to the right like normal English reading left to right lol. It's literally personally choice and inconsequential so totally ignore this and keep putting out awesome content.
What if you have 2 features that have common util functions but should not be used outside of these 2 features? Would you go for nested features?
More specifically my app has 3 top routes, one for the public, one for admin console and one for an organizer console. The organizer console uses today some functions that the admin also uses but never intended for the public routes. I am tempted to copy these few functions to allow them to be modified independently.
The best folder structure, I found
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
@@warrenarnoldmusicoooo Mr snazzy pants
@@warrenarnoldmusic java is not as popular as js lol
very interesting, I'm already defining my folders this way. Global Objects and "business ones". Then I'm adding a "business scenarios" that links everything all together. For example "scenario_userlogin, scenario_cardpayment, ..."
Hexagonal Architecture is my go-to. 3 folders: domain, application and infrastructure. That's it. Business logic and entities in domain. UseCases/Services in application, and DB, API, I/O... in infra. Rinse and repeat for each project
I really like this folder strucutre, very modular !
That's an excellent way to force the developer to follow a certain pattern.
folder structure is the bane of my existance
Hey Kyle I really love your work.
The requested video is How can we document any project from scratch technical documents for front-end and backend.
Thank You
The music of your channel always reminds me of Thin Lizzy for some reason
The problem with this structure is that many classes will overlap different features, so now it get complicated to attribute them to a folder. So in large projects, it can get a little messy. I prefer to organize by abstraction level (entities, factories, services, gui, libraries). With the IDE, it is easy to search and find a file (by its name or content).
Awesome idea, please create a video for NextJs 🙏
Great video! Thank you.
Can I know how you're drawing this red line with your cursor when you're showing the diagram?
How would you apply this to a monorepo where you want to reuse code across multiple applications
Nice awesome file structure ,Beginnergs always worries about it..
Thank you!
My current project got way too big and messy. I'll definitely switch to this folder structure
If you dive into the use-cases architecture approach, you’ll become a 1000x developer!
You do an amazing job!!!!
Just a basic apps/libs/api in a monorepo will do wonders if they are segregated as packages. But they should not set in stone. Folder structures will constantly change according to the need at the time
What happens in situations where you have to reference other features. Let's say you want to delete a user to comply with regulations you would have to delete also products added by that user, so how would you structure that?
That sounds like integration of the features, which would go in the "app" folder somewhere.
what about contexts ? will they have their own directory or be combined with one of the listed ones ?
When I see your videos I feel happy. How do you do it?
Thanks for this, We want NEXT js specific file structure .......
I can see the advantages, but it's not one sided either:
1 - Get use mentally to this workflow can take time and is not straight forward based on previous habits;
2 - You need some time to setup your eslintrc file, and to think carefully beforehand about your structure;
3 - Decide how to separate your files and folders. For instance, why you put login in app in the first place? I could see it in either shared or even features, for instance;
4 - If you work iin a team, you will have to talk about that shift, and it might simply get rejected.
Deciding what parts of the app are features and shared is probably the hardest part
Hmm I wrote a big reply about this but its not showing now I came back to edit it. I guess basically, all I wanted to say was, you don't decide where to put it, the app does. The first time you need to use a component in another feature, you refactor it out into the shared folder. It organises itself.
Login refers to the page not to the functions, etc.. Everything in the app folder are the pages in your website, just code to the render the different components
Let's give it a try!
My team started using the Russian doll method 2 years ago, and I'll never go back. Put every file that you create inside a folder of the same name. In each folder, you will only have that file, and then other folders (containing files that you created inside the parent file).
Sounds horrible tbh? Why is it good?
@@MadeInJack It's just one less thing to worry about. The file structure is shaped independently, and it's easy to navigate. We are very explicit with our file naming.
Kyle got tanned :D. But great content. Thanks for sharing.
Do you lose some of the benefits of the app router in Nextjs?
Ty for Eslint tip
If you have a layout where will you put it?
I have a request - I would like to see a project which uses a separate backend - exposed with APIs (like python, go, java or even js) but separate.
As backend dev, if I want to build frontend from scratch I would love to learn from a project video. The backend project videos make bare minimum UI, and frontend projects make bare minimum backend, or use full stack framework like next js which doesnt help in making projects if backend is separate.
If you have already made a video on this or can give me any reference that will also be good.
There are some concepts which are not easy to understand with like - auth, have the frontend, backend state same for an object, how to handle APIs where you need to call multiple apis to achieve a single data feature on frontend.
In fact, organizing TypeScript files into folders is the most challenging part.
How long have you been in this line of work? Great content, very helpful, greetings from Serbia
woooooooooow man! this is pure gold