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.
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 !
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.
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.
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.
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.
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
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 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.
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 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.
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.
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
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 think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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 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.
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?
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.
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'm extremely waiting for the large project you want to publish on RUclips, 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.
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?
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 💖
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
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.
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, ..."
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).
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.
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
What if you have product card component that has list of users that bought the product (from users feature). What to do in this example? Is product feature allowed to import from users?
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
This is great! I would love to institute this in all of my projects, old and new. {dumb question coming . . } What is the best method in doing so, without this become a big project itself?
While I can appreciate how this might work in some situations, there are cases where it won't fit. For example, I'm building an app that uses Convex for the DB. Granted I'm still relatively new to it, but unless I'm mistaken all of its files need to live in the premade "convex" folder because of how Convex auto-generates some files. The schema is all in a single file, and access to queries, mutations, etc. is based directly on where their definition files live inside of that "convex" folder. If anyone knows if spreading them across feature folders like you show here is doable (safely!) with Convex, please describe how, but I'm pretty sure that it won't work.
Hey, Kyle what does "lib" mean in your file structure? I feel it is more like vast term. I prefer create global folders like 'hooks' - plain and simple and super straightforward. You mentioned formatters are going under 'lib'. Hmm, why not under "utils"? Utils mean some useful functions, isn't it? Idk, I feel like I love creating global api layer under api folder. Where I separate things like /userApi, /productsApi and there in each folder I can have structure like this userUrls.ts, userTypes, userQuery, userMSW, userMock (last to for doing Mock Service Workers, to work offline or to reuse those in Storybook & tests, not sure MSW is going to work in Next.js but in SPA it works). API layer helps me easier to think of server state. This api layer must be UI agnostic, just plain methods/react-query hooks, so doing no popups or whatever, if such things needed, use callbacks.
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.
How does this structure address circular dependency. For example, user needs products list and vice versa? Wouldn't they be importing from one another thus circular dependency?
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
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? :)
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!
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.
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.
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.
ُ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.
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'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
Overtime I realised the same. Proposed it to colleagues and they liked it too
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
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.
I tried feature based folder structure, what i liked the most was the time it saved, which i usually spent solving merge conflict.
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.
Thanks. This seems great. I would also like to see a NextJs version please
Exactly what I wanted to begin my Lead Management System Project ❤
Thnks Kyle....🎉🎉
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'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
TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)
Feels like a demo for eslint boundaries demo and it’s really cool. if I introduce to my team, they might crucified me.
This is really PURE GOLD!
Looking Forward to the NextJS Folder Structure. Would be great if you also add role permission handling things folders.
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.
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.
Feature Sliced Design is the answer guys. We adapted it at work and 2+ years in it works wonder.
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
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!
Thank you for this, this improves scalability for my projects. Both web app and game dev
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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
Great video. I want to see the next version. With more folders like caching, middleware and all.
Looking froward to the NextJS Folder Structure video.
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.
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?
Bro never failed to deliver. Love you man.
I am up for nextjs video
This is the type of content I love to see. Thanks for going over practical examples and showing full config. Really insightful
Modular setup is what I'm practicing right now.
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
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.
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?
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
Absolutely need a next.js version of this video!!
I like the features -structure, will like your super long 7 hrs video tutorial to cover that :)
I would *love* to see the next is specific version of this video.
I'm extremely waiting for the large project you want to publish on RUclips, 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.
This is nice, going to change the structure of my project. would be nice to see a nextjs setup with this :)
Brilliant Great explanation. The ESlint is amazing, just what I need. And yes very interested in a specific version of this for NextJS.
Thanks for including a github link!
Theo can't be mad this time.
Nice vid 👍
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.
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 💖
You're killing it with the unique content ideas as usual! Thanks Kyle
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 🙏
That's an excellent way to force the developer to follow a certain pattern.
Great video let’s do this for a backend in node and express
😊
How would you apply this to a monorepo where you want to reuse code across multiple applications
what about contexts ? will they have their own directory or be combined with one of the listed ones ?
My current project got way too big and messy. I'll definitely switch to this folder structure
Great video! Thank you.
Can I know how you're drawing this red line with your cursor when you're showing the diagram?
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.
When I see your videos I feel happy. How do you do it?
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, ..."
Do you lose some of the benefits of the app router in Nextjs?
this' what i really need. thanks a lot kyle
Love your content!
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).
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.
If you have a layout where will you put it?
Wonderful, thanks a lot for this detailed video.
saved the day with this vid
I prefer to keep all 100k lines of code in just 1 file. No folder structure needed if there are no folders.
It has the added bonus of having my morning coffee and putting in a load of laundry while I wait for my IDE to load.
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
Can this be made recursive? like - the 'products' feature could have a 'features' folder within it that defines features for the products features
What if you have product card component that has list of users that bought the product (from users feature).
What to do in this example?
Is product feature allowed to import from users?
I'm thinking you'll need to use other techniques like composition and handle the integration logic at the "app" level.
thank you for very pro contents about our comunity. and please make the nextjs specific folder structure video.
The music of your channel always reminds me of Thin Lizzy for some reason
That looks amazing!
I really like this folder strucutre, very modular !
Thank you Kyle!
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
If you block features from importing each other, how would you deal with database foreign keys and other cross feature references in your code?
This is great! I would love to institute this in all of my projects, old and new. {dumb question coming . . } What is the best method in doing so, without this become a big project itself?
what do you put in the /lib directory? and what goes in the /data directory?
While I can appreciate how this might work in some situations, there are cases where it won't fit. For example, I'm building an app that uses Convex for the DB. Granted I'm still relatively new to it, but unless I'm mistaken all of its files need to live in the premade "convex" folder because of how Convex auto-generates some files. The schema is all in a single file, and access to queries, mutations, etc. is based directly on where their definition files live inside of that "convex" folder. If anyone knows if spreading them across feature folders like you show here is doable (safely!) with Convex, please describe how, but I'm pretty sure that it won't work.
folder structure is the bane of my existance
Hey, Kyle what does "lib" mean in your file structure? I feel it is more like vast term. I prefer create global folders like 'hooks' - plain and simple and super straightforward.
You mentioned formatters are going under 'lib'. Hmm, why not under "utils"? Utils mean some useful functions, isn't it?
Idk, I feel like I love creating global api layer under api folder. Where I separate things like /userApi, /productsApi and there in each folder I can have structure like this userUrls.ts, userTypes, userQuery, userMSW, userMock (last to for doing Mock Service Workers, to work offline or to reuse those in Storybook & tests, not sure MSW is going to work in Next.js but in SPA it works).
API layer helps me easier to think of server state. This api layer must be UI agnostic, just plain methods/react-query hooks, so doing no popups or whatever, if such things needed, use callbacks.
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.
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
if the folder name should consist of 2 words, what do you use? camel case, dash or underscore?
Thanks very much,
what about the types for each feature? should they be at each feature folder or all of them should be at a global separated folder ?
How does this structure address circular dependency. For example, user needs products list and vice versa? Wouldn't they be importing from one another thus circular dependency?
I am having trouble with the capture function which doesn’t seem to work for the features
It's a take on Vertical Slice Architecture, haven't seen or thought about it for web before though.