This Folder Structure Makes Me 100% More Productive

[@t3dotgg]

I know my original folder structure video was awful but this was the key point I wanted to make. Grouping should always be by feature, NOT by technology. “Separation of concerns” was a lie

[@den9943]

It looks like we need a UseCases/Application Layer in our frontend app (thanks, Uncle Bob), where all domains come together. This might be considered our "features," but we shouldn't group them by domain names like product, users, etc.-that would be misleading. Instead, we need to structure them based on business intentions, making sure that every grouping clearly reflects what the system is actually doing, such as createProduct, manageOrders, handleUserRegistration, and so on.

[@dereotu5405]

Couldn't you still say that this is "separation of concerns", but your concern is features, and not the technologies? :)

[@Dan-StefanMartin]

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

[@SamuelL1clau]

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 !

[@canadianbootz1]

Agreed - the eslint plugin config is new to me and 100% helpful - thanks!

[@engelshernandez5898]

I'm just about to start a large complex project. Now I'm not worried about the folder structure. This is pure gold 💪

[@sndselecta]

So weird that alot of OOP languages and the people who teach them never mention this paradigm. I was on a few channels trying to engage on peoples thoughts on folder hierarchy which is so important as a basis of code but also could be looked at from a security viewpoint aswell, found that many people didnt have much input. Definitely gold. Interested to learn more. Especially front end versus back end, any thoughts on where this would fall under the django structure or just as simple as under a "js" folder, which is where I put my js code 🙈 ?

[@LewisCowles]

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.

[@Froggie92]

^^^^^^^ 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

[@sndselecta]

@@Froggie92 I noticed this too, I learnt on figma hated that so much, this seems way more dope

[@foldisnomistake]

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.

[@IncomingLegend]

looks good, will give it a try

[@foldisnomistake]

@@IncomingLegend yeah, and you can adopt it to your needs, and use whatever you like more from it

[@arvi8843]

how about circular dependency?

[@foldisnomistake]

@@arvi8843 you can setup linter for checking for it too. but usually it is not a problem in case of using FSD

[@tuananhdo1870]

Feature-Driven Development (chatgpt)

[@ericmisha]

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.

[@tengun]

Also Django.

[@Pankecal-v4k]

I also felt exactly same. I like angular way of organizing files tho

[@TwoLeggedTriceratops]

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.

[@alelunadev]

This is more like a clean architecture, not just like the Angular method. We have core, domain, and infrastructure. It’s very clear and well-explained. The methodology is called feature-first, but it aligns with clean architecture principles.

[@sndselecta]

@@tengun I seem to remember similarities please explain

[@6sense651]

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

[@deatho0ne587]

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.

[@dputra]

Naming things is hard when you're new. It's an acquired skill. You'll get better with time! 😊

[@hoaxygen]

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.

[@antidegenerates7449]

Cody and Kyle are the best web dev tutors on yt

[@sndselecta]

Wes Bos is good to did a bunch of his courses

[@antidegenerates7449]

@@sndselecta he's horrible

[@Vigiflyer]

I'd be interested in seeing a NUXT implementation of this. Great Video. Thank you for taking the time to produce it

[@QueeeeenZ]

You can use layers in Nuxt

[@ninoJAckwwe]

ُThank you so much Kyle, BTY you're the only youtuber that I watch his video with the normal playback speed :)

[@IncomingLegend]

i always watch at X1.5, you're a simp

[@megaclinton6527]

developing can get really complicated with just one change... thanks for simplifying it!

[@DigitalAlchemyst]

Okay This video has been living rent free in my mind since it dropped. I think I am going to refactor my work project this way and see how I like it. I am pretty much done with coding the project so if I don't like it I wont have to deal much with it anymore will come back later on and give my feedback on the structure.

[@private-1]

This is like domain driven design in the form of folder structures.

[@CottidaeSEA]

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.

[@gbkEmilgbk]

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.

[@ibrahimblahblahyapyap]

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.

[@jerryknows7765]

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.

[@gauravkumawat5811]

Exactly what I wanted to begin my Lead Management System Project ❤ Thnks Kyle....🎉🎉

[@SSan-n3q]

TIL about the eslint boundary plugin, will implement this way of folder structure going forward. tysm for the amazing videos and diagrams Kyle :)

[@henriquezolini]

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.

[@peeratchaikleebbua7723]

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

[@javadbagheri9921]

I'm extremely waiting for the large project you want to publish on KZbin, 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.

[@roguesherlock]

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!

[@dgdev69]

Bro never failed to deliver. Love you man. I am up for nextjs video

[@cliffordwilliam3714]

Thank you for this, this improves scalability for my projects. Both web app and game dev

[@1337bitcoin]

I'm sold. Time to spend a week refactoring everything!

[@shubitoxX]

Better wait for the next video, youtubers tend to discover the next big best thing minimum on a weekly basis for clicks

[@arifrabbani4204]

Great video. I want to see the next version. With more folders like caching, middleware and all.

[@andyvennells2034]

Thanks. This seems great. I would also like to see a NextJs version please

[@aaeonCodes]

Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.

[@frostytf2]

This is the type of content I love to see. Thanks for going over practical examples and showing full config. Really insightful

[@alokprakash2017]

Overtime I realised the same. Proposed it to colleagues and they liked it too

[@xenos112]

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

[@IncomingLegend]

monorepos suck

[@xenos112]

@@IncomingLegend agree but needed for big projects, you don't wonna create many repos and manage them separately

[@johnrake4]

We use a monorepo structure for our client projects. It’s really convenient to have smaller projects where the api/db/app is all under the same repo for sharing configs and simple referencing. This was super easy for web apps, mobile apps were more tricky until we started using external services for our backend like Convex. I’m optimistic something like tanstack will be a game changer for us

[@MarkRambotech]

This is really PURE GOLD!

[@DarkzarichV2]

Feature Sliced Design is the answer guys. We adapted it at work and 2+ years in it works wonder.

[@pezwarrior4]

Modular setup is what I'm practicing right now.

[@warrenarnoldmusic]

20:53 😅Js devs have just discovered scoped packages. This is the convention in java

[@chaws314]

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.

[@megamind452]

Theo can't be mad this time. Nice vid 👍

[@raymondmichael4987]

I like the features -structure, will like your super long 7 hrs video tutorial to cover that :)

[@jacobphillips9235]

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 💖

[@Srabon444]

Looking Forward to the NextJS Folder Structure. Would be great if you also add role permission handling things folders.

[@reninmohan2303]

I tried feature based folder structure, what i liked the most was the time it saved, which i usually spent solving merge conflict.

[@se7sTC]

I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication

[@rtpHarry]

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.

[@arinovilyas4986]

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

[@prodevus]

@@arinovilyas4986 Commenting so i'm also alerted if someone thinks of it

[@zeph8620]

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.

[@rtpHarry]

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.

[@skillfulfighter23]

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

[@HowieRhee]

Brilliant Great explanation. The ESlint is amazing, just what I need. And yes very interested in a specific version of this for NextJS.

[@wildernns]

You're killing it with the unique content ideas as usual! Thanks Kyle

[@pedromartinezlopez]

Looking froward to the NextJS Folder Structure video.

[@sealone777]

Feels like a demo for eslint boundaries demo and it’s really cool. if I introduce to my team, they might crucified me.

[@realfranciscohermida]

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.

[@zeustechdev]

Love your content!

[@McFamily25]

Absolutely need a next.js version of this video!!

[@Cwyrm]

I would *love* to see the next is specific version of this video.

[@steffen480310]

This is nice, going to change the structure of my project. would be nice to see a nextjs setup with this :)

[@AJCrowley]

Thanks for including a github link!

[@DmitriiBaranov-ib3kf]

Thank you Kyle!

[@FunQuizzy88]

this' what i really need. thanks a lot kyle

[@amaralensheriff]

Wonderful, thanks a lot for this detailed video.

[@comosaycomosah]

saved the day with this vid

[@StephenFosterUK]

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.

[@electronpicante2520]

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

[@LePhenixGD]

I really like this folder strucutre, very modular !

[@flavioarantesdoamorimbarce95]

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?

[@danielocampo543]

Great video let’s do this for a backend in node and express 😊

[@Weahl]

That looks amazing!

[@frostmichael8360]

Super useful !!

[@alirezaghadyani16]

thank you for very pro contents about our comunity. and please make the nextjs specific folder structure video.

[@jhaeberli]

Great explanation!

[@WhyAreYouFindingMe]

The best folder structure, I found

[@warrenarnoldmusic]

20:53 😅Js devs have just discovered scoped packages. This is the convention in java

[@sausageroll6979]

​@@warrenarnoldmusicoooo Mr snazzy pants

[@Love_Peace_Giver]

@@warrenarnoldmusic java is not as popular as js lol

[@raphaelsanchez1235]

super interesting! Having a good structure to avoid refactoring every time the project grows. Thanks a lot Kyle ❤

[@user-gm3lg8gp3m]

Great video, thank you

[@fletcherrat337]

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.

[@boscodomingo]

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

[@Soraphis91]

I'd put all the global folders also in a folder "global" (or I'd like to call it "essentials" because "e" sorts before "f" of "features" (or "core")) so that features are not somewhere in the middle of the shared-folders. I also don't create a subfolder if it will only contain 1 (or 2) elements. so I would not "users\server\db\users.ts" with "users" and "users\server" empty. if the only part of the users feature is the db schema, then it's fine to have a single file in a folder with a single level. In game dev I also realized in my last project that it is sometimes hard to go "feature based" all the way down. at some point inside the feature structure it starts to make sense to say: "okay, I have a materials folder here, since this single feature has multiple materials" even though in general a "materials" folder would be named after content instead of feature and thus forbidden. so, yeah a bit of pragmatism does not hurt 🙂

[@Nodsaibot]

folder structure is the bane of my existance

[@LouisLascelles-Palys]

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.

[@maximegod1]

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.

[@zmeireles68]

That's an excellent way to force the developer to follow a certain pattern.

[@kris_k93]

Awesome idea, please create a video for NextJs 🙏

[@JasonLayton]

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]

Sounds horrible tbh? Why is it good?

[@JasonLayton]

@@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.

[@caballerosalas]

The music of your channel always reminds me of Thin Lizzy for some reason

[@cbbcbb6803]

Let's give it a try!

[@julianklumpers]

How would you apply this to a monorepo where you want to reuse code across multiple applications

[@yoyo26-34]

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, ..."

[@noman_ali_khan]

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

[@chrishabgood8900]

You do an amazing job!!!!

[@hazim3448]

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?

[@maddada]

Great video! Thank you. Can I know how you're drawing this red line with your cursor when you're showing the diagram?

[@anuragpramanik6095]

Kyle got tanned :D. But great content. Thanks for sharing.

[@josecentenodev]

woooooooooow man! this is pure gold

[@nobir98]

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

[@NaourassDerouichi]

Great reference, thanks for the mention!

[@Shuyinz]

So the clean architecture is feature based architecture Kyle is showing us?

[@nobir98]

@@NaourassDerouichi You are most welcome 😁

[@nobir98]

@@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.

[@yojou3695]

meh

[@raphauy]

Thank you!

[@ahamedfazilbuhari]

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?

[@inversemetric]

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

[@StanislausKatczinsky]

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?

[@hoaxygen]

That sounds like integration of the features, which would go in the "app" folder somewhere.

[@8_ball_z]

Ty for Eslint tip

[@abdelrhmangad351]

Thanks very much, what about the types for each feature? should they be at each feature folder or all of them should be at a global separated folder ?

[@KevinVandyTech]

I prefer to keep all 100k lines of code in just 1 file. No folder structure needed if there are no folders.

[@hoaxygen]

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.

[@21mighty86]

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?

[@hoaxygen]

I'm thinking you'll need to use other techniques like composition and handle the integration logic at the "app" level.

[@yickkiuleung5037]

what about contexts ? will they have their own directory or be combined with one of the listed ones ?

[@whodoneitx2x]

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

[@leulfanuel3550]

When I see your videos I feel happy. How do you do it?

[@AdityaSinghCodes]

You are awesome.

[@JasGigli_Dev]

Nice awesome file structure ,Beginnergs always worries about it..