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
I know my original folder structure video was awful but this was the key point I wanted to make. Grouping should always be by feature, NOT by technology. “Separation of concerns” was a lie
It looks like we need a UseCases/Application Layer in our frontend app (thanks, Uncle Bob), where all domains come together. This might be considered our "features," but we shouldn't group them by domain names like product, users, etc.-that would be misleading. Instead, we need to structure them based on business intentions, making sure that every grouping clearly reflects what the system is actually doing, such as createProduct, manageOrders, handleUserRegistration, and so on.
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 !
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.
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.
So weird that alot of OOP languages and the people who teach them never mention this paradigm. I was on a few channels trying to engage on peoples thoughts on folder hierarchy which is so important as a basis of code but also could be looked at from a security viewpoint aswell, found that many people didnt have much input. Definitely gold. Interested to learn more. Especially front end versus back end, any thoughts on where this would fall under the django structure or just as simple as under a "js" folder, which is where I put my js code 🙈 ?
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.
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.
Okay This video has been living rent free in my mind since it dropped. I think I am going to refactor my work project this way and see how I like it. I am pretty much done with coding the project so if I don't like it I wont have to deal much with it anymore will come back later on and give my feedback on the structure.
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
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.
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.
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.
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.
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!
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.
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 💖
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 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
We use a monorepo structure for our client projects. It’s really convenient to have smaller projects where the api/db/app is all under the same repo for sharing configs and simple referencing. This was super easy for web apps, mobile apps were more tricky until we started using external services for our backend like Convex. I’m optimistic something like tanstack will be a game changer for us
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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
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.
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
I'd put all the global folders also in a folder "global" (or I'd like to call it "essentials" because "e" sorts before "f" of "features" (or "core")) so that features are not somewhere in the middle of the shared-folders. I also don't create a subfolder if it will only contain 1 (or 2) elements. so I would not "users\server\db\users.ts" with "users" and "users\server" empty. if the only part of the users feature is the db schema, then it's fine to have a single file in a folder with a single level. In game dev I also realized in my last project that it is sometimes hard to go "feature based" all the way down. at some point inside the feature structure it starts to make sense to say: "okay, I have a materials folder here, since this single feature has multiple materials" even though in general a "materials" folder would be named after content instead of feature and thus forbidden. so, yeah a bit of pragmatism does not hurt 🙂
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.
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.
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
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
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, ..."
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.
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?
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
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).
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.
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.
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.
Interesting approach, I don't think it's perfect, but thank you for clearly sharing with visuals tools and a comparison! I thought it was interesting how next (or a page router) effects this setup, perhaps as a project like this scales, an API would be more preferential for some features and perhaps you should be breaking into a monorepo. Hope that's helpful comment feedback✌
I'm assuming if you have a monorepo where apps/web has a features folder, it's ok to import from packages/backend, packages/types, and so forth? I guess in one use case using convex, you have to use a `convex` folder so you can co-locate that kind
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
I know my original folder structure video was awful but this was the key point I wanted to make. Grouping should always be by feature, NOT by technology.
“Separation of concerns” was a lie
It looks like we need a UseCases/Application Layer in our frontend app (thanks, Uncle Bob), where all domains come together. This might be considered our "features," but we shouldn't group them by domain names like product, users, etc.-that would be misleading. Instead, we need to structure them based on business intentions, making sure that every grouping clearly reflects what the system is actually doing, such as createProduct, manageOrders, handleUserRegistration, and so on.
Couldn't you still say that this is "separation of concerns", but your concern is features, and not the technologies? :)
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!
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
@@Froggie92 I noticed this too, I learnt on figma hated that so much, this seems way more dope
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)
I'm just about to start a large complex project. Now I'm not worried about the folder structure. This is pure gold 💪
So weird that alot of OOP languages and the people who teach them never mention this paradigm. I was on a few channels trying to engage on peoples thoughts on folder hierarchy which is so important as a basis of code but also could be looked at from a security viewpoint aswell, found that many people didnt have much input. Definitely gold. Interested to learn more. Especially front end versus back end, any thoughts on where this would fall under the django structure or just as simple as under a "js" folder, which is where I put my js code 🙈 ?
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.
@@tengun I seem to remember similarities please explain
Cody and Kyle are the best web dev tutors on yt
Wes Bos is good to did a bunch of his courses
@@sndselecta he's horrible
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.
ُ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
Okay This video has been living rent free in my mind since it dropped. I think I am going to refactor my work project this way and see how I like it. I am pretty much done with coding the project so if I don't like it I wont have to deal much with it anymore will come back later on and give my feedback on the structure.
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
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
Exactly what I wanted to begin my Lead Management System Project ❤
Thnks Kyle....🎉🎉
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.
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.
Thank you for this, this improves scalability for my projects. Both web app and game dev
TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)
developing can get really complicated with just one change... thanks for simplifying it!
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.
Bro never failed to deliver. Love you man.
I am up for nextjs video
Overtime I realised the same. Proposed it to colleagues and they liked it too
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
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.
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!
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
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.
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.
This is the type of content I love to see. Thanks for going over practical examples and showing full config. Really insightful
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.
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 💖
Brilliant Great explanation. The ESlint is amazing, just what I need. And yes very interested in a specific version of this for NextJS.
This is really PURE GOLD!
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.
Feature Sliced Design is the answer guys. We adapted it at work and 2+ years in it works wonder.
Theo can't be mad this time.
Nice vid 👍
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
We use a monorepo structure for our client projects. It’s really convenient to have smaller projects where the api/db/app is all under the same repo for sharing configs and simple referencing.
This was super easy for web apps, mobile apps were more tricky until we started using external services for our backend like Convex. I’m optimistic something like tanstack will be a game changer for us
I like the features -structure, will like your super long 7 hrs video tutorial to cover that :)
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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!
Modular setup is what I'm practicing right now.
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
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.
Looking froward to the NextJS Folder Structure video.
Feels like a demo for eslint boundaries demo and it’s really cool. if I introduce to my team, they might crucified me.
Thanks for including a github link!
this' what i really need. thanks a lot kyle
Absolutely need a next.js version of this video!!
This is nice, going to change the structure of my project. would be nice to see a nextjs setup with this :)
I would *love* to see the next is specific version of this video.
Wonderful, thanks a lot for this detailed video.
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
saved the day with this vid
Great video let’s do this for a backend in node and express
😊
Great video, thank you
I'd put all the global folders also in a folder "global" (or I'd like to call it "essentials" because "e" sorts before "f" of "features" (or "core")) so that features are not somewhere in the middle of the shared-folders.
I also don't create a subfolder if it will only contain 1 (or 2) elements. so I would not "users\server\db\users.ts" with "users" and "users\server" empty. if the only part of the users feature is the db schema, then it's fine to have a single file in a folder with a single level.
In game dev I also realized in my last project that it is sometimes hard to go "feature based" all the way down. at some point inside the feature structure it starts to make sense to say: "okay, I have a materials folder here, since this single feature has multiple materials" even though in general a "materials" folder would be named after content instead of feature and thus forbidden.
so, yeah a bit of pragmatism does not hurt 🙂
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.
thank you for very pro contents about our comunity. and please make the nextjs specific folder structure video.
I really like this folder strucutre, very modular !
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.
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
Awesome idea, please create a video for NextJs 🙏
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
Love your content!
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, ..."
Great explanation!
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
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.
Super useful !!
Ty for Eslint tip
That looks amazing!
You're killing it with the unique content ideas as usual! Thanks Kyle
Kyle got tanned :D. But great content. Thanks for sharing.
Thank you!
My current project got way too big and messy. I'll definitely switch to this folder structure
Let's give it a try!
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?
The music of your channel always reminds me of Thin Lizzy for some reason
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
folder structure is the bane of my existance
It reminds me of the module organization of angular or nestjs👍
When I see your videos I feel happy. How do you do it?
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).
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.
Remix Feature Folders by Jacob Paris is a good read.
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.
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.
It's a take on Vertical Slice Architecture, haven't seen or thought about it for web before though.
Interesting approach, I don't think it's perfect, but thank you for clearly sharing with visuals tools and a comparison!
I thought it was interesting how next (or a page router) effects this setup, perhaps as a project like this scales, an API would be more preferential for some features and perhaps you should be breaking into a monorepo. Hope that's helpful comment feedback✌
NextJs setup please ☺️❤️
That's an excellent way to force the developer to follow a certain pattern.
super interesting! Having a good structure to avoid refactoring every time the project grows. Thanks a lot Kyle ❤
Thanks for this, We want NEXT js specific file structure .......
You do an amazing job!!!!
Nice awesome file structure ,Beginnergs always worries about it..
Great video! Thank you.
Can I know how you're drawing this red line with your cursor when you're showing the diagram?
It will be great if you made another video for nextjs folder structure
waiting for it
I'm assuming if you have a monorepo where apps/web has a features folder, it's ok to import from packages/backend, packages/types, and so forth? I guess in one use case using convex, you have to use a `convex` folder so you can co-locate that kind