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 !
@LewisCowles
12 сағат бұрын
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.
@Vigiflyer
Күн бұрын
I'd be interested in seeing a NUXT implementation of this. Great Video. Thank you for taking the time to produce it
@QueeeeenZ
14 сағат бұрын
You can use layers in Nuxt
@6sense651
22 сағат бұрын
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.
@ericmisha
2 сағат бұрын
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.
@foldisnomistake
12 сағат бұрын
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
10 сағат бұрын
looks good, will give it a try
@foldisnomistake
10 сағат бұрын
@@IncomingLegend yeah, and you can adopt it to your needs, and use whatever you like more from it
@private-1
Күн бұрын
This is like domain driven design in the form of folder structures.
@CottidaeSEA
7 сағат бұрын
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.
@MattCreenan
Күн бұрын
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.
@gauravkumawat5811
Күн бұрын
Exactly what I wanted to begin my Lead Management System Project ❤ Thnks Kyle....🎉🎉
@javadbagheri9921
Күн бұрын
I'm extremely waiting for the large project you want to publish on KZitem, 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.
@megaclinton6527
Күн бұрын
developing can get really complicated with just one change... thanks for simplifying it!
@AIZEN155
Күн бұрын
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
10 сағат бұрын
monorepos suck
@AIZEN155
9 сағат бұрын
@@IncomingLegend agree but needed for big projects, you don't wonna create many repos and manage them separately
@StephenFosterUK
11 сағат бұрын
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.
@rtpHarry
6 сағат бұрын
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.
@ninoJAckwwe
23 сағат бұрын
ُThank you so much Kyle, BTY you're the only youtuber that I watch his video with the normal playback speed :)
@IncomingLegend
10 сағат бұрын
i always watch at X1.5, you're a simp
@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
@roguesherlock
17 сағат бұрын
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!
@maddada
19 сағат бұрын
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
10 сағат бұрын
monorepos suck
@maddada
9 сағат бұрын
@@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.
@se7sTC
4 сағат бұрын
I think this structure forces you to think in Microfrontends architecture. Not just at dependency level, but rendering, decoupling, state and communication
@wildernns
18 сағат бұрын
You're killing it with the unique content ideas as usual! Thanks Kyle
@yoyo26-34
11 сағат бұрын
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, ..."
@fletcherrat337
22 сағат бұрын
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.
@rns10
4 сағат бұрын
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.
@megamind452
11 сағат бұрын
Theo can't be mad this time. Nice vid 👍
@realfranciscohermida
21 сағат бұрын
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.
@flavioarantesdoamorimbarce95
22 сағат бұрын
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?
@jacobphillips9235
17 сағат бұрын
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 💖
@arifrabbani4204
21 сағат бұрын
Great video. I want to see the next version. With more folders like caching, middleware and all.
@TheHermitHacker
21 сағат бұрын
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.
@jhaeberli
16 сағат бұрын
Great explanation!
@LePhenixGD
Күн бұрын
I really like this folder strucutre, very modular !
@anuragpramanik6095
14 сағат бұрын
Kyle got tanned :D. But great content. Thanks for sharing.
10 сағат бұрын
So you saying you found modular system in 2024 :) Great work dude.
@petherpettersson6152
12 сағат бұрын
It's a take on Vertical Slice Architecture, haven't seen or thought about it for web before though.
@denisgithinji1119
18 сағат бұрын
Couldn't have been released at a more right on time. Thanks 👍🏽
@Weahl
21 сағат бұрын
That looks amazing!
@cat_copilot
16 сағат бұрын
Ty for Eslint tip
@StanislausKatczinsky
19 сағат бұрын
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?
@maddada
19 сағат бұрын
Great video! Thank you. Can I know how you're drawing this red line with your cursor when you're showing the diagram?
@aaeonCodes
22 сағат бұрын
Very insightful and practical. Thank you Kyle for always focusing on the useful stuff.
@The_RubenM
2 сағат бұрын
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?
@Raphael-jo1rp
18 сағат бұрын
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.
@gabrielcorpuz5649
15 сағат бұрын
Deciding what parts of the app are features and shared is probably the hardest part
@rtpHarry
5 сағат бұрын
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.
@rugucloud
13 сағат бұрын
In fact, organizing TypeScript files into folders is the most challenging part.
@a.r.b5653
22 сағат бұрын
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...
@pkorneev5226
21 сағат бұрын
Check out feature slice design architecture
@convulsion1928
12 сағат бұрын
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.
@loquek
7 сағат бұрын
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✌
@matthiasweston3426
18 сағат бұрын
Remix Feature Folders by Jacob Paris is a good read.
@joezappie
6 сағат бұрын
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.
@dgdev69
17 сағат бұрын
Bro never failed to deliver. Love you man. I am up for nextjs video
@cbbcbb6803
21 сағат бұрын
Let's give it a try!
@leulfanuel3550
20 сағат бұрын
When I see your videos I feel happy. How do you do it?
@omnilothar
18 сағат бұрын
if the folder name should consist of 2 words, what do you use? camel case, dash or underscore?
@i-heart-google7132
12 сағат бұрын
Hey Kyle, here's a question - why don't you simply use the Nx Workspace, instead of reinventing the wheel? :)
@charlescoult
Күн бұрын
Can this be made recursive? like - the 'products' feature could have a 'features' folder within it that defines features for the products features
@chambaderaphael8946
2 сағат бұрын
It reminds me of the module organization of angular or nestjs👍
@phailsharkaev4653
21 сағат бұрын
If you dive into the use-cases architecture approach, you’ll become a 1000x developer!
@MilanTrpkovic
9 сағат бұрын
How long have you been in this line of work? Great content, very helpful, greetings from Serbia
@GiigliHub
7 сағат бұрын
Nice awesome file structure ,Beginnergs always worries about it..
@thebks1
15 сағат бұрын
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?
@mingyangli9171
21 сағат бұрын
Great video. Would you be open to share your thoughts on a better structure for TypeScript-based Node.js folder structures? Maybe another video?
@julianklumpers
22 сағат бұрын
How would you apply this to a monorepo where you want to reuse code across multiple applications
@julionunes2092
Күн бұрын
This project structure is very commonly used in angular. Angular works with modules and each module is a feature.
@antonarbus
Күн бұрын
Looks like the light version of Feature Sliced Design pattern
@nexovec
Күн бұрын
oh, what about starting flat and just making folders when it seems counterproductive to not have them? Kinda always works out for me.
@The-Torbey
Күн бұрын
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
@chrishabgood8900
Күн бұрын
You do an amazing job!!!!
@guilhermenascimento4067
Күн бұрын
And how you make the relations in drizzle if you can’t import the table outside
@cagansen5404
Күн бұрын
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
@rohitkharche7562
7 сағат бұрын
What about collocation of components with _components folder just in the place it is being used ?
@WhyAreYouFindingMe
Күн бұрын
The best folder structure, I found
@warrenarnoldmusic
Күн бұрын
20:53 😅Js devs have just discovered scoped packages. This is the convention in java
@Snozcumber
Күн бұрын
@@warrenarnoldmusicoooo Mr snazzy pants
@Love_Peace_Giver
10 сағат бұрын
@@warrenarnoldmusic java is not as popular as js lol
@ivanmaglica264
10 сағат бұрын
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.
@ziacodes
12 сағат бұрын
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.
@simpingsyndrome
12 сағат бұрын
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
@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
23 сағат бұрын
Great reference, thanks for the mention!
@Shuyinz
22 сағат бұрын
So the clean architecture is feature based architecture Kyle is showing us?
@nobir98
20 сағат бұрын
@@NaourassDerouichi You are most welcome 😁
@nobir98
20 сағат бұрын
@@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
19 сағат бұрын
meh
@PooyaBadiee
Күн бұрын
I usually go with this approach but I name them modules instead of features
@tannertanner1
22 сағат бұрын
😱 tysm
@2gbeh
13 сағат бұрын
Rules implementation 👍
@NaourassDerouichi
23 сағат бұрын
Astro fullstack architecture please !
@deatho0ne587
4 минут бұрын
Odd part is this is not to far removed from the junior version, just instead of one file multiple files/directories.
@awekeningbro1207
10 сағат бұрын
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.
@oliverhughes169
5 сағат бұрын
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.
@imkir4n
Күн бұрын
13:00 you know what, i just did the reverse of this just now. lol 😂
@stefan-d.grigorescu
20 сағат бұрын
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 :)
@videoponder4673
23 сағат бұрын
I like that approach. But hey, why not just have an app folder and folders A to Z and sort functions alphabetically?
@NorthernChimp
20 сағат бұрын
Alphabetical order becomes quickly nonsensical.
@pkorneev5226
21 сағат бұрын
Isn't it called feature sliced design architecture?
@Ryujin_001
14 сағат бұрын
Does anyone know which browser he is using ?
@zy1p
13 сағат бұрын
Arc
@stefanopuloz622
Күн бұрын
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.
@ianengelbrecht4773
12 сағат бұрын
Gold
@Saleh_Balakisiyev
11 сағат бұрын
I think it would be a lot harder to implement i18n to this folder structure
@noriller
Күн бұрын
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.
@fabaladibbasey7453
20 сағат бұрын
Well vertically sliced
@iou878
Күн бұрын
So basically it’s DDD approach…
@АртемБутенко-н7к
5 сағат бұрын
check Feature-Sliced Design Architectural methodology for frontend projects
@kim92se64
23 сағат бұрын
Can we see this kind of "Features" Project on your channel, soon ?
@sammy_vee
19 сағат бұрын
The next.js video pls!
@7iomka
4 сағат бұрын
Looks like Feature-Sliced Design partially
@adulis_et
22 сағат бұрын
Bro is obsessed with todo list apps
@sahilaggarwal2004
Сағат бұрын
Wth is Next.js not shifting to eslint v9
@chok8356
20 сағат бұрын
See Feature-Sliced Design
@KevinVandyTech
7 сағат бұрын
I prefer to keep all 100k lines of code in just 1 file. No folder structure needed if there are no folders.
@mamupelu565
Күн бұрын
hey I'm the first here
@crakyanime8903
Күн бұрын
Nice bro
@iraveen98
Күн бұрын
second
@Kushagraa
16 сағат бұрын
Angular solved this problems on first release 😂
@piyush-arora
15 сағат бұрын
If you use packages instead of folders , you got urself a pretty descent mono repo 😂
Пікірлер: 155