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.
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 !
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
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.
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.
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.
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.
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.
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
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.
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 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.
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, ..."
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.
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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.
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.
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
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?
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?
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✌
n00b question: what if you have a feature that shows all the products that a user has liked? In this example, would you put that in the user folder or the product folder?
Say you have an orders feature, and in the OrdersGrid file you wanted to show the user that placed it with a user component that shows their name and picture. If features are restricted from other features, how can you do that? If you make that user component a global that makes it confusing for maintenance as down the road if i forget id go to the user feature folder to try to find it. Great video, just curious how youd deal with a common use case like this.
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?
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?
How we can manage the global state of the application, particularly if we’re using Redux Toolkit. lets say I follow this style, where should I create Feature specific slices and `store.js` files? Also, would it be possible for you to create a dedicated video on state management?
Nice way of structuring folders! But i have a question, you have globally shared components, but in real projects some of these components only belong to certain pages, so it would be nice to have one more folder like pages or modules, where you will store everything related to this particular page, like hooks, components etc and there you will use different features from features folder, am i thinking the right way?
That is something you can do. I tend to find that pages that become complex enough to need all that extra stuff sometime can just become their own feature, but that isn't always the case. If you find you have a few components/hooks you need for just one page I would recommend either just putting them all in the same page file if they aren't too complex or creating a separate _components/_hooks/_etc folders at the level of the page in your app folder. This would require you to modify the ESLint config, though.
Features not being able to import each other is too restrictive... What if i'm creating an app as complex as Figma... Then i would need certain Features to be able to interact with other Features...
I would argue that it's still good for reusability and avoiding reliance between functionality that are quite different. What could be added is another layer above the features layer, with a primary function of bundling different features together. So, in practice your page will be a composition of different features and 'widgets' or whatever you want to call it, that are just more complex composition of features underneath.
Not at all. If a feature needs to import another feature. That part is no longer a feature, but a shared component and it needs to be generalized and moved to a shared components folder. The rules are pretty simple - A component is only used in a feature|page. It goes in that folder - A component is used between features. It goes to the shared folder.
@@paragateoslo I agree with you to a certain extent. I'd like to emphasize the fact that shared components should remain featureless like a UI kit (alerts, inputs, menus etc...) or maybe a library dependency whereas feature folders should mainly reflect points of entry (pages). If a component is truly using multiple features then I think it should be split into the feature-specific logic and featureless (technical) then in each feature reference the reusable technical part and redefine (for the lack of a better word) the same feature. Surely, the main complaint would be that this goes against DRY but at least you guarantee feature relative independence.
@@bejalal17 Oh yes. When I say moved to a shared folder. I don't mean take that component straight as it is from the feature folder. You identify the parts that are shared, refactor out that out as feature free reusable component that is put in the shared folder. A shared component should NEVER contain entity/feature/page related code. It should be agnostic.
Uncle Bob was actually telling the software engineers a decade ago about "The Clean Architecture" Edit: I didn't know that eslint can do that. Thank you Kyle for showing this feature of eslint
@@Shuyinz Not precisely. Clean architecture can be created using feature-based approaches, although it is not clearly defined, as Uncle Bob points out. He even claims that the architecture's layers do not remain in four levels, but rather more or less (mentioned in his article), but the dependency rules are always applied to the layers. In other words, dependency rules say higher-level layers should not depend on lower-level layers. Clean architecture has two basic goals: 1. Separation of concerns. 2. Dependency Rules.
tl;dr code locality is good 😃 On the web app my team created and maintains, we structure things by scope at the top level, then by type underneath that. We use Nx, so everything is under either apps/ or libs/. But under libs/: - A "shared" scope is at the top for anything used across features. - Everything else is a feature level scope just named whatever the feature is - Underneath those, we group types of files together: ui/, feature/, data/, utils/, etc.
That would be a sort of refactoring. Costs unnecessary time and you need to change the imports everywhere every time. Sure, for small projects you don't really need the folder structure shown in the video but it's a good practice to have any kind of structure so you don't have to change everything all the time
it's like the vertical slice architecture right? and if you cold make a video about nextjs 15 and with react 19 both with best practices it would be sick
I highly suggest that instead of features folder, you name it modules folder. Features folder should be reserved for features objects, pieces of functionality that you extract out of main module for better clarity and separation of logic. Once your objects/modules become big and contain more subdomains, you extract each subdomain onto it's own feature, especially if it has it's own state. There is nothing more horrifying than seeing a module with multiple features crammed in it, all containing their own state. Result, an object with 1000 private properties and names spanning two screens.
Let's say I've a function getUsers() in features/users I want to use that in features/blogs, and let's say I want to use getUsers() function. How I do that? Eslint won't allow to import from other features? Move that function to top level? only a single function on top level while rest in feature folder? This is confusing me.
Can u make a video about the difference between folder structure and a System Design for example MVC is this any related with the folder structure? Please like to up this
My question is, why does a frontend project need a database folder? Frontend doesn't access db directly, it talks with backend via the api, so I feel like db folder is of no use.
The example was a NextJS app, which is more 'fullstack'. As well as your frontend code, you are also writing server code executed on a node server that is providing the API and access to the DB.
You can take this one step further. Try grouping by an action your user can perform. So, instead of having a folder called products, have "increase product price", where you could keep together things related particulary to that action, like a popup component, some dtos to interact with api, some service injected to call the api, constants. All these things that are dedicated for that action. This is even more cohesive than having together in a products/data folder some dtos ProductSaveRequest, ProductListItemResponse, IncreaseProductPriceForm etc. (all represent products, but do not work together, they are dedicated to specific tasks). I have discovered this idea before, but just recently started to get it and try it. It's really nice, you might wanna think about it :)
In theory this sounds great in practice it is not. This approach requires constant planning and paying attention to what goes to which feature folder. For one-man or small to mid-sized projects it is doable. For large scale projects with a lot of people this devolves quite fast into bloody mess. Do not try it if that is the case.
I try to make something similar... been calling it (in my head) a "fractal folder structure" (because you know, fractals...) My rule is almost what you described, but allowing for further nesting when needed. (not sure how you would handle it there) Like productsForFoo, productsForBar would each be able to replicate the products structure. The further nested, the "less impact" it can have, so someone more junior can work on it. But as it is needed "higher", then I refactor (aka move to a common shared space) and I know that the closer to root, the more impact it can have... so someone more senior and/or more people reviewing the changes. Didn't know about that eslint plugin, but not sure how it would handle "recursive" folders. Actually, I always go for making refactoring easier, so I can make a productsForFoo.ts first, if needed I rename to productsForFoo/index.ts, creating a folder and an index (no need to refactor imports), then move things on that file to adjacent files/folders as needed.
Das mit Servern von Amazon ist aber an sich egal. Das ist halt ein Cloud Provider, davon gibt es aber viele und auch einige in der größere. Eigene Server in den Größen sind einfach nicht sinnvoll. Bei so einem Cloud Provider kann man halt innerhalb von wenigen Momenten mehr Kapazitäten dazu buchen bzw. starten um mehr load gleichzeitig abzuarbeiten.
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.
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!
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.
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.
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)
This is the type of content I love to see. Thanks for going over practical examples and showing full config. Really insightful
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.
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.
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....🎉🎉
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.
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
developing can get really complicated with just one change... thanks for simplifying it!
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.
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 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
TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)
You're killing it with the unique content ideas as usual! Thanks Kyle
Couldn't have been released at a more right on time. Thanks 👍🏽
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.
Modular setup is what I'm practicing right now.
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
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, ..."
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.
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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.
Theo can't be mad this time.
Nice vid 👍
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.
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
Great video. I want to see the next version. With more folders like caching, middleware and all.
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?
Great explanation!
I have a sneaking suspicion this will help me a lot! Thank you so much for this. I didn't know that Linting tools could this.
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?
I really like this folder strucutre, very modular !
That looks amazing!
Kyle got tanned :D. But great content. Thanks for sharing.
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
It's a take on Vertical Slice Architecture, haven't seen or thought about it for web before though.
Ty for Eslint tip
Bro never failed to deliver. Love you man.
I am up for nextjs video
Great video! Thank you.
Can I know how you're drawing this red line with your cursor when you're showing the diagram?
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✌
n00b question: what if you have a feature that shows all the products that a user has liked? In this example, would you put that in the user folder or the product folder?
Remix Feature Folders by Jacob Paris is a good read.
Let's give it a try!
So you saying you found modular system in 2024 :) Great work dude.
what about contexts ? will they have their own directory or be combined with one of the listed ones ?
That's an excellent way to force the developer to follow a certain pattern.
When I see your videos I feel happy. How do you do it?
Hey Kyle, here's a question - why don't you simply use the Nx Workspace, instead of reinventing the wheel? :)
Can this be made recursive? like - the 'products' feature could have a 'features' folder within it that defines features for the products features
It reminds me of the module organization of angular or nestjs👍
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
If you dive into the use-cases architecture approach, you’ll become a 1000x developer!
Say you have an orders feature, and in the OrdersGrid file you wanted to show the user that placed it with a user component that shows their name and picture. If features are restricted from other features, how can you do that? If you make that user component a global that makes it confusing for maintenance as down the road if i forget id go to the user feature folder to try to find it.
Great video, just curious how youd deal with a common use case like this.
Yep he didn't address circular dependency or relations between features.
if the folder name should consist of 2 words, what do you use? camel case, dash or underscore?
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 think it would be a lot harder to implement i18n to this folder structure
Nice awesome file structure ,Beginnergs always worries about it..
You do an amazing job!!!!
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?
How we can manage the global state of the application, particularly if we’re using Redux Toolkit. lets say I follow this style, where should I create Feature specific slices and `store.js` files? Also, would it be possible for you to create a dedicated video on state management?
Nice way of structuring folders! But i have a question, you have globally shared components, but in real projects some of these components only belong to certain pages, so it would be nice to have one more folder like pages or modules, where you will store everything related to this particular page, like hooks, components etc and there you will use different features from features folder, am i thinking the right way?
That is something you can do. I tend to find that pages that become complex enough to need all that extra stuff sometime can just become their own feature, but that isn't always the case. If you find you have a few components/hooks you need for just one page I would recommend either just putting them all in the same page file if they aren't too complex or creating a separate _components/_hooks/_etc folders at the level of the page in your app folder. This would require you to modify the ESLint config, though.
@@WebDevSimplified sounds reasonable, will try it!
Great video. Would you be open to share your thoughts on a better structure for TypeScript-based Node.js folder structures? Maybe another video?
Features not being able to import each other is too restrictive... What if i'm creating an app as complex as Figma... Then i would need certain Features to be able to interact with other Features...
Check out feature slice design architecture
I would argue that it's still good for reusability and avoiding reliance between functionality that are quite different. What could be added is another layer above the features layer, with a primary function of bundling different features together. So, in practice your page will be a composition of different features and 'widgets' or whatever you want to call it, that are just more complex composition of features underneath.
Not at all. If a feature needs to import another feature. That part is no longer a feature, but a shared component and it needs to be generalized and moved to a shared components folder. The rules are pretty simple
- A component is only used in a feature|page. It goes in that folder
- A component is used between features. It goes to the shared folder.
@@paragateoslo I agree with you to a certain extent. I'd like to emphasize the fact that shared components should remain featureless like a UI kit (alerts, inputs, menus etc...) or maybe a library dependency whereas feature folders should mainly reflect points of entry (pages). If a component is truly using multiple features then I think it should be split into the feature-specific logic and featureless (technical) then in each feature reference the reusable technical part and redefine (for the lack of a better word) the same feature. Surely, the main complaint would be that this goes against DRY but at least you guarantee feature relative independence.
@@bejalal17 Oh yes. When I say moved to a shared folder. I don't mean take that component straight as it is from the feature folder. You identify the parts that are shared, refactor out that out as feature free reusable component that is put in the shared folder.
A shared component should NEVER contain entity/feature/page related code. It should be agnostic.
Uncle Bob was actually telling the software engineers a decade ago about "The Clean Architecture"
Edit: I didn't know that eslint can do that. Thank you Kyle for showing this feature of eslint
Great reference, thanks for the mention!
So the clean architecture is feature based architecture Kyle is showing us?
@@NaourassDerouichi You are most welcome 😁
@@Shuyinz
Not precisely. Clean architecture can be created using feature-based approaches, although it is not clearly defined, as Uncle Bob points out. He even claims that the architecture's layers do not remain in four levels, but rather more or less (mentioned in his article), but the dependency rules are always applied to the layers. In other words, dependency rules say higher-level layers should not depend on lower-level layers.
Clean architecture has two basic goals: 1. Separation of concerns. 2. Dependency Rules.
meh
tl;dr code locality is good 😃
On the web app my team created and maintains, we structure things by scope at the top level, then by type underneath that. We use Nx, so everything is under either apps/ or libs/. But under libs/:
- A "shared" scope is at the top for anything used across features.
- Everything else is a feature level scope just named whatever the feature is
- Underneath those, we group types of files together: ui/, feature/, data/, utils/, etc.
100% more productive is a bold claim. Nice overview of how you like to structure a project tho. Structure is all about common sense.
Looks like the light version of Feature Sliced Design pattern
This project structure is very commonly used in angular.
Angular works with modules and each module is a feature.
This reminds me with Django and their modules.
woooooooooow man! this is pure gold
oh, what about starting flat and just making folders when it seems counterproductive to not have them? Kinda always works out for me.
That would be a sort of refactoring. Costs unnecessary time and you need to change the imports everywhere every time. Sure, for small projects you don't really need the folder structure shown in the video but it's a good practice to have any kind of structure so you don't have to change everything all the time
it's like the vertical slice architecture right? and if you cold make a video about nextjs 15 and with react 19 both with best practices it would be sick
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
What about collocation of components with _components folder just in the place it is being used ?
How would you apply this to a monorepo where you want to reuse code across multiple applications
And how you make the relations in drizzle if you can’t import the table outside
I highly suggest that instead of features folder, you name it modules folder. Features folder should be reserved for features objects, pieces of functionality that you extract out of main module for better clarity and separation of logic. Once your objects/modules become big and contain more subdomains, you extract each subdomain onto it's own feature, especially if it has it's own state. There is nothing more horrifying than seeing a module with multiple features crammed in it, all containing their own state. Result, an object with 1000 private properties and names spanning two screens.
Let's say I've a function getUsers() in features/users
I want to use that in features/blogs, and let's say I want to use getUsers() function.
How I do that? Eslint won't allow to import from other features? Move that function to top level? only a single function on top level while rest in feature folder? This is confusing me.
Can u make a video about the difference between folder structure and a System Design for example MVC is this any related with the folder structure?
Please like to up this
😱 tysm
Rules implementation 👍
I usually go with this approach but I name them modules instead of features
My question is, why does a frontend project need a database folder? Frontend doesn't access db directly, it talks with backend via the api, so I feel like db folder is of no use.
The example was a NextJS app, which is more 'fullstack'. As well as your frontend code, you are also writing server code executed on a node server that is providing the API and access to the DB.
Astro fullstack architecture please !
13:00 you know what, i just did the reverse of this just now. lol 😂
Odd part is this is not to far removed from the junior version, just instead of one file multiple files/directories.
You can take this one step further. Try grouping by an action your user can perform. So, instead of having a folder called products, have "increase product price", where you could keep together things related particulary to that action, like a popup component, some dtos to interact with api, some service injected to call the api, constants. All these things that are dedicated for that action. This is even more cohesive than having together in a products/data folder some dtos ProductSaveRequest, ProductListItemResponse, IncreaseProductPriceForm etc. (all represent products, but do not work together, they are dedicated to specific tasks).
I have discovered this idea before, but just recently started to get it and try it. It's really nice, you might wanna think about it :)
Does anyone know which browser he is using ?
Arc
I like that approach. But hey, why not just have an app folder and folders A to Z and sort functions alphabetically?
Alphabetical order becomes quickly nonsensical.
Isn't it called feature sliced design architecture?
Gold
In theory this sounds great in practice it is not.
This approach requires constant planning and paying attention to what goes to which feature folder. For one-man or small to mid-sized projects it is doable.
For large scale projects with a lot of people this devolves quite fast into bloody mess. Do not try it if that is the case.
I try to make something similar... been calling it (in my head) a "fractal folder structure" (because you know, fractals...)
My rule is almost what you described, but allowing for further nesting when needed. (not sure how you would handle it there)
Like productsForFoo, productsForBar would each be able to replicate the products structure. The further nested, the "less impact" it can have, so someone more junior can work on it. But as it is needed "higher", then I refactor (aka move to a common shared space) and I know that the closer to root, the more impact it can have... so someone more senior and/or more people reviewing the changes.
Didn't know about that eslint plugin, but not sure how it would handle "recursive" folders.
Actually, I always go for making refactoring easier, so I can make a productsForFoo.ts first, if needed I rename to productsForFoo/index.ts, creating a folder and an index (no need to refactor imports), then move things on that file to adjacent files/folders as needed.
Das mit Servern von Amazon ist aber an sich egal. Das ist halt ein Cloud Provider, davon gibt es aber viele und auch einige in der größere. Eigene Server in den Größen sind einfach nicht sinnvoll. Bei so einem Cloud Provider kann man halt innerhalb von wenigen Momenten mehr Kapazitäten dazu buchen bzw. starten um mehr load gleichzeitig abzuarbeiten.
Well vertically sliced