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.
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
Hi Kyle, As a beginner and struggling to organize my files since English is my second language where it takes time to think a name of a file or folder, this is a really HUGE help for us
Try the rubber ducky-ChatGPT approach: start by telling it what exactly what your file/variable/funcion does in a few sentences. The more precisely you describe it, the better. You'll either have come up with a good name for it yourself by the time you hit enter or ChatGPT will help you out with that. Then you can ask ChatGPT to refine it for you by asking for variations and explanations for nuance when using other synonyms. I'd say naming things is mostly hard when you don't know how to tackle the problem, but this approach is usually helpful and gets you in the right direction.
You've just described is how Angular has been doing this for years. A textbook example of structuring medium and large-sized Angular applications that scale well. This is the proper way to do it.
I had my Sass files structured this way 10+ years ag. I think this is the setup that everyone gravitates to as the complexity and feature set rises. You start thinking in modules/features first before responsibility.
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 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 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.
That's it! I use the same structure, the folders have different names, but it's the same idea. In many places, I was treated like a madman by people who wanted to implement clean architecture in the frontend (domain, infra, presentation, etc.). That's crazy, the frontend needs to be simple. And this structure works really well. People who advocate for complexity in frontend architecture talk about business rules and blah blah blah, but if there's any business rule in the frontend, it's wrong; business rules should stay in the backend.
Fantastic! Really important stuff, thanks for covering this Kyle. It's sad and overwhelming as a junior of a super complex codebase that nobody I ask has a competent understanding of any of our apps file structure because it grew too big and is now too costly to refactor without causing massive regression costs.
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.
perfect timing. I currently have domain driven architecture where all my business logic flows through that specific domain but I should probably extend that to include all the ui too!
This is 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.
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.
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.
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 💖
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
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.
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 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
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
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, ..."
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?
Hexagonal Architecture is my go-to. 3 folders: domain, application and infrastructure. That's it. Business logic and entities in domain. UseCases/Services in application, and DB, API, I/O... in infra. Rinse and repeat for each project
I 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
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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.
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'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.
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
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
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.
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.
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'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
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?
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✌
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 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?
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.
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.
Thank you for the video; it was incredibly helpful for setting up a large project. I have one question: I have a hooks folder under each feature folder, and in some components, I need to access the state (using React context and reducer) of another feature. For example, I want to show the product name in the sales component. How should this be handled? Is it acceptable to refer to the state from one feature in another feature?
valid question. my thought is to use an adapter or make an exception that a feature can pull the state object from app directly (but not from another feature). This really needs to be discussed further
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
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
I'm just about to start a large complex project. Now I'm not worried about the folder structure. This is pure gold 💪
Cody and Kyle are the best web dev tutors on yt
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)
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
You're killing it with the unique content ideas as usual! Thanks Kyle
Hi Kyle, As a beginner and struggling to organize my files since English is my second language where it takes time to think a name of a file or folder, this is a really HUGE help for us
Even if English is your primary it is always hard to name files, folders and variables. Might be the hardest part of development to be honest.
Naming things is hard when you're new. It's an acquired skill. You'll get better with time! 😊
Try the rubber ducky-ChatGPT approach: start by telling it what exactly what your file/variable/funcion does in a few sentences. The more precisely you describe it, the better. You'll either have come up with a good name for it yourself by the time you hit enter or ChatGPT will help you out with that. Then you can ask ChatGPT to refine it for you by asking for variations and explanations for nuance when using other synonyms.
I'd say naming things is mostly hard when you don't know how to tackle the problem, but this approach is usually helpful and gets you in the right direction.
You've just described is how Angular has been doing this for years. A textbook example of structuring medium and large-sized Angular applications that scale well. This is the proper way to do it.
Also Django.
I also felt exactly same. I like angular way of organizing files tho
I had my Sass files structured this way 10+ years ag. I think this is the setup that everyone gravitates to as the complexity and feature set rises. You start thinking in modules/features first before responsibility.
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
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 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 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.
Thank you for this, this improves scalability for my projects. Both web app and game dev
That's it! I use the same structure, the folders have different names, but it's the same idea. In many places, I was treated like a madman by people who wanted to implement clean architecture in the frontend (domain, infra, presentation, etc.). That's crazy, the frontend needs to be simple. And this structure works really well. People who advocate for complexity in frontend architecture talk about business rules and blah blah blah, but if there's any business rule in the frontend, it's wrong; business rules should stay in the backend.
Fantastic! Really important stuff, thanks for covering this Kyle. It's sad and overwhelming as a junior of a super complex codebase that nobody I ask has a competent understanding of any of our apps file structure because it grew too big and is now too costly to refactor without causing massive regression costs.
ُ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
Exactly what I wanted to begin my Lead Management System Project ❤
Thnks Kyle....🎉🎉
developing can get really complicated with just one change... thanks for simplifying it!
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.
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.
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
Bro never failed to deliver. Love you man.
I am up for nextjs video
TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)
Feature Sliced Design is the answer guys. We adapted it at work and 2+ years in it works wonder.
perfect timing. I currently have domain driven architecture where all my business logic flows through that specific domain but I should probably extend that to include all the ui too!
This is 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.
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.
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.
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
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 💖
Great video. I want to see the next version. With more folders like caching, middleware and all.
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
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.
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 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
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
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 like the features -structure, will like your super long 7 hrs video tutorial to cover that :)
Modular setup is what I'm practicing right now.
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
Brilliant Great explanation. The ESlint is amazing, just what I need. And yes very interested in a specific version of this for NextJS.
Absolutely need a next.js version of this video!!
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?
super interesting! Having a good structure to avoid refactoring every time the project grows. Thanks a lot Kyle ❤
Theo can't be mad this time.
Nice vid 👍
Hexagonal Architecture is my go-to. 3 folders: domain, application and infrastructure. That's it. Business logic and entities in domain. UseCases/Services in application, and DB, API, I/O... in infra. Rinse and repeat for each project
I 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
Super useful !!
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
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.
Thank you Kyle!
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).
saved the day with this vid
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.
Wonderful, thanks a lot for this detailed video.
Thanks for including a github link!
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
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.
This is nice, going to change the structure of my project. would be nice to see a nextjs setup with this :)
this' what i really need. thanks a lot kyle
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
Great video let’s do this for a backend in node and express
😊
I would *love* to see the next is specific version of this video.
That looks amazing!
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.
I really like this folder strucutre, very modular !
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.
thank you for very pro contents about our comunity. and please make the nextjs specific folder structure video.
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?
Great explanation!
That's an excellent way to force the developer to follow a certain pattern.
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
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
My current project got way too big and messy. I'll definitely switch to this folder structure
Great video, thank you
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?
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✌
If you dive into the use-cases architecture approach, you’ll become a 1000x developer!
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.
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.
When I see your videos I feel happy. How do you do it?
Great video! Thank you.
Can I know how you're drawing this red line with your cursor when you're showing the diagram?
Feels like a demo for eslint boundaries demo and it’s really cool. if I introduce to my team, they might crucified me.
In fact, organizing TypeScript files into folders is the most challenging part.
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.
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.
Great video. Would you be open to share your thoughts on a better structure for TypeScript-based Node.js folder structures? Maybe another video?
This project structure is very commonly used in angular.
Angular works with modules and each module is a feature.
folder structure is the bane of my existance
Thank you!
woooooooooow man! this is pure gold
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 give it a try!
Nice awesome file structure ,Beginnergs always worries about it..
How long have you been in this line of work? Great content, very helpful, greetings from Serbia
You do an amazing job!!!!
Awesome idea, please create a video for NextJs 🙏
Thanks for this, We want NEXT js specific file structure .......
Thank you for the video; it was incredibly helpful for setting up a large project. I have one question: I have a hooks folder under each feature folder, and in some components, I need to access the state (using React context and reducer) of another feature. For example, I want to show the product name in the sales component. How should this be handled? Is it acceptable to refer to the state from one feature in another feature?
valid question. my thought is to use an adapter or make an exception that a feature can pull the state object from app directly (but not from another feature). This really needs to be discussed further