The nuance you mentioned at the end should've been a big disclaimer right at the beginning, because beginners might now go out and do this prematurely, where in fact it has serious tradeoffs in practice, and can hurt more than help. This requires you to come up with your own abstraction on an already (usually) well tested and thought through API, which often ends up being too generic. For instance, you may write a function getProducts, but then you realize that another place needs or doesn't need some extra data, so you either end up writing a function getProductsWithOrders (and eventually end up with 20 one-off functions anyway, which is usually OK, but people don't often do it like that), or you end up passing `query` argument that you forward to the database query - which either ends up being coupled to the database library anyway, or you write your own crappy untested not-well-thought-through API on top of an already good library which over time just converges to whatever you were using under the hood (prisma/drizzle or whatever). In 9 years I've seen this go wrong just as much if not more than it helps.
I work with a codebase where we have lots of nested abstractions where they weren't needed. And it was a case where newbie tried to be smart. If you meed to inspect somehing it takes 8-12 jumps ))
I prefer a centralised way, as data related things separate in one file and out of the actual presentation. And then have either separate functions going for similar data, or better use the database itself via views. Where the view name pass to the function.
I tried both the approaches, but after certain size both becomes impossible to manage or maintain speed. This is why i follow a different approach which you kinda cover in earlier videos. I created a features folder. Inside that i have folder for each feature (auth, payment, etc). It contain db folder, usecases folders, and components folders. DB folder contain schema and data-access funcitons, Usecases contain business logic and talk to database, and components are ui components. This made my life so simple. Especially when I am working on some complex feature, I can find everything at a single place.
But how to maange the fact that under one feature there would be multiple components and same components will have to go in other features also, making a different copy of same component at multiple places
@@sahilgupta7001 these would come under common folder. I am handling such things two ways. 1st. If a component is getting shared between handful of features, then inside features folder I have a common folder (featuers/common/components). I put these there. 2nd. If something is shared across the entire site like shadcn components or navbar etc .. I put those in components folder at top level (src/components)
This is one of the best insights a senior developer can give, and I'm currently facing a similar issue in my project. I was using next-safe-action in a the previous version, but we've now decided to use React Query within the project, making next-safe-action a bit redundant. This change requires updating a ton of files. If I had used this pattern earlier, I could simply update the API layer, and everything would work seamlessly. I discovered this pattern a couple of months ago, but Kyle, you've explained it amazingly!
Truly, what I mostly do is create "wrappers" of the snippets I use a lot. I type the input and output. Like you said, so I can have great flexibility of changing the internals or even mock the function.
Yeah there's separation of concern. Angular does it well, there you have Services where you should put the business logic and components etc. for the view
I like this "Like A Senior Dev" and especially the feature flags ! I was looking for a tutorial for this subject for months ! Do you think you can also do one about how to setup the CI/CD, like the basics and then, for a MERN stack for example ? In Europe, companies are into craftmanship and devops is a part of it. And how to manage a monorepo with microservices & microfrontends ?
About the auth thing... It's kind of silly to me that you have to do this on every page when you're using Nextjs. Most other frameworks have a concept of "middleware", which is effectively execution a function for every request. Since the vast majority of your pages would be auth-ed, it makes sense to put the auth logic there, and check at the top if the URL is one not requiring auth. Nextjs does have a thing it calls "middlewares", but those have to use Vercel's "Edge" runtime, which in practice means no direct IO - there is fetch, and that's about it. No files, no remote DB access either. And no way to tell the middleware "I'm not going to use Vercel, let me just run this on my own Nodejs server".
The lesson here is to create an adapter to standardize the interface inside of your application and convert all calls to a service to the current implementation, this is the contract that should be well documented by the service provider. The biggest challenge is when you choose a provider that isn’t great at creating documentation and you have features that are missing or ones that had been deprecated. This can be the most frustrating and challenging part of development.
This "Like a Senior Dev" series is kinda hilarious when you consider a fact, that Kyle only had one real full-time dev job that he quit rather quickly to become full-time youtuber :D He talks about it himself, in a video where he claims - oh the sweet irony - that "clean code is killing your project" (ruclips.net/video/1uzlBSL7-UM/видео.html). He never mentions any specific dates or periods there, I don't think so, but the context suggest it wasn't overly long career. So I'm rather skeptical if he knows how senior developers do anything, considering he is himself a strong junior most likely, maybe regular. Sure, he has a lot of knowledge, it's clearly visible on his videos - but I'd argue seniority level is much more than just knowledge alone.
Writing code is like writing text: it's not only for your, but also for who's going to read it next. Yes, even you will change, and at some point, reading your code after a year will look almost like somebody else written it. That's why structuring the code right not only important, but I'd also say respectful. But it's not only that, using a good project architecture requires you to know how things really work, and trust me, people notice that.
@@vincaslt the right way for me is the one that makes your code readable, easy to maintain and refactor, by having different "layers", if you watched the video there's a clear example of why mixing things is bad.
Could you please create a Project by watching and checking it with a Figma file having any design and upload that video to this channel so that we learn & get benefits? We need to learn the strategy to complete a project quickly through Figma.
If we move CRUD operations to findOne, findAll, create, update, remove api fetch services or custom hook, useReducer Hook and database queries to repository? controller dto services entity repository
according to this, I should be applying for senior dev job, despite never having worked as a dev... how am I supposed to know which position am I supposed to apply for?!
I'm an old developer - have they stopped teaching design patterns in computer science ? Or is the problem that the people who are developers don't actually have any formal education ?
I'd say take it a step further. Instead of just declaring facades with functions that take in a userId, have the function receive a db object that implements the functionality via an interface. So when you want to switch libraries, you can just make a new db object and pass that in instead. Now you're really making that Bob guy proud
You just extracted functionality into separate utils functions, I mean that’s not really senior… you didn’t say anything about dependency injection, abstractions, interfaces, etc. For example if you wanna test your application are you just gonna depend on drizzle or mock every one of those functions you created? I was expecting an injected db operation adapter using interfaces Also an auth library is exactly something you would like to change in the future, not your ORM 😅, the ORM is already the abstraction of your db
I'm meeting some "seniors" devs that thinks this (good) practice to be bad because it is just an indirection and now you need to jump to another file to understand what is happening... ¯\_(ツ)_/¯
it depends on how your project will evolve. call the database directly in frontend is cursed as fuck, you should at least create an abstraction for mocks
Definitely improvement, but it's still bloated. I would actually introduce some architecture here, use layers, split by feature/bounded context and communicate by facades, since folder structure is not architecture, it's just folder structure. It will simplify apps scaling, and reusing some of "modules" and share them between project, even refactoring them to separate libs or parts of mono repo etc. A lot easier is to think about this when you actually will have unit test in your code base. FE devs very slowly adapts DDD approach.
Its an "ORM" that most likely uses SQL under the hood. Advantage: Easier to write + Type safety. Disadvantage: Often bad for performance in some niche scenarios where performance matters.
![Coheed and Cambria - Searching for Tomorrow [Official Video]](http://i.ytimg.com/vi/hDsYGLbmadg/mqdefault.jpg)
The nuance you mentioned at the end should've been a big disclaimer right at the beginning, because beginners might now go out and do this prematurely, where in fact it has serious tradeoffs in practice, and can hurt more than help.
This requires you to come up with your own abstraction on an already (usually) well tested and thought through API, which often ends up being too generic. For instance, you may write a function getProducts, but then you realize that another place needs or doesn't need some extra data, so you either end up writing a function getProductsWithOrders (and eventually end up with 20 one-off functions anyway, which is usually OK, but people don't often do it like that), or you end up passing `query` argument that you forward to the database query - which either ends up being coupled to the database library anyway, or you write your own crappy untested not-well-thought-through API on top of an already good library which over time just converges to whatever you were using under the hood (prisma/drizzle or whatever).
In 9 years I've seen this go wrong just as much if not more than it helps.
I work with a codebase where we have lots of nested abstractions where they weren't needed. And it was a case where newbie tried to be smart. If you meed to inspect somehing it takes 8-12 jumps ))
I prefer a centralised way, as data related things separate in one file and out of the actual presentation.
And then have either separate functions going for similar data, or better use the database itself via views.
Where the view name pass to the function.
Thank god, someone is talking about this with a big audience. Sick and tired of no one caring about frontend structure.
bite your forehead
I tried both the approaches, but after certain size both becomes impossible to manage or maintain speed. This is why i follow a different approach which you kinda cover in earlier videos. I created a features folder. Inside that i have folder for each feature (auth, payment, etc). It contain db folder, usecases folders, and components folders. DB folder contain schema and data-access funcitons, Usecases contain business logic and talk to database, and components are ui components. This made my life so simple. Especially when I am working on some complex feature, I can find everything at a single place.
IT depends on the project you are currently working on.
But how to maange the fact that under one feature there would be multiple components and same components will have to go in other features also, making a different copy of same component at multiple places
@@sahilgupta7001 these would come under common folder. I am handling such things two ways. 1st. If a component is getting shared between handful of features, then inside features folder I have a common folder (featuers/common/components). I put these there. 2nd. If something is shared across the entire site like shadcn components or navbar etc .. I put those in components folder at top level (src/components)
Vertical slice architecture
This is one of the best insights a senior developer can give, and I'm currently facing a similar issue in my project. I was using next-safe-action in a the previous version, but we've now decided to use React Query within the project, making next-safe-action a bit redundant. This change requires updating a ton of files. If I had used this pattern earlier, I could simply update the API layer, and everything would work seamlessly. I discovered this pattern a couple of months ago, but Kyle, you've explained it amazingly!
Truly, what I mostly do is create "wrappers" of the snippets I use a lot. I type the input and output. Like you said, so I can have great flexibility of changing the internals or even mock the function.
It is called Repository pattern
Yeah there's separation of concern. Angular does it well, there you have Services where you should put the business logic and components etc. for the view
You are slowly rediscovering Clean Architecture.
we are rediscovering signals, MVC, logic-less client (HTMX...). Frontend is just one big endless cylce.
I like this "Like A Senior Dev" and especially the feature flags !
I was looking for a tutorial for this subject for months !
Do you think you can also do one about how to setup the CI/CD, like the basics and then, for a MERN stack for example ? In Europe, companies are into craftmanship and devops is a part of it.
And how to manage a monorepo with microservices & microfrontends ?
Very good insights shared. Thanks as always for breaking it down for us!
I need to think about this, it makes a lot of sense
web dev simplified finally discovered clean architecture
Facade = put all your crap under a carpet and pretend it isn't there
Adapter = put a square peg into a round hole
tbf most of the time we use adapter as "facades" cuz create interfaces for everything is pretty annoying
About the auth thing... It's kind of silly to me that you have to do this on every page when you're using Nextjs. Most other frameworks have a concept of "middleware", which is effectively execution a function for every request. Since the vast majority of your pages would be auth-ed, it makes sense to put the auth logic there, and check at the top if the URL is one not requiring auth.
Nextjs does have a thing it calls "middlewares", but those have to use Vercel's "Edge" runtime, which in practice means no direct IO - there is fetch, and that's about it. No files, no remote DB access either. And no way to tell the middleware "I'm not going to use Vercel, let me just run this on my own Nodejs server".
The lesson here is to create an adapter to standardize the interface inside of your application and convert all calls to a service to the current implementation, this is the contract that should be well documented by the service provider. The biggest challenge is when you choose a provider that isn’t great at creating documentation and you have features that are missing or ones that had been deprecated. This can be the most frustrating and challenging part of development.
If you are going to write adapter for another adapter, might as well just run sql query directly
This "Like a Senior Dev" series is kinda hilarious when you consider a fact, that Kyle only had one real full-time dev job that he quit rather quickly to become full-time youtuber :D He talks about it himself, in a video where he claims - oh the sweet irony - that "clean code is killing your project" (ruclips.net/video/1uzlBSL7-UM/видео.html). He never mentions any specific dates or periods there, I don't think so, but the context suggest it wasn't overly long career.
So I'm rather skeptical if he knows how senior developers do anything, considering he is himself a strong junior most likely, maybe regular. Sure, he has a lot of knowledge, it's clearly visible on his videos - but I'd argue seniority level is much more than just knowledge alone.
i would really love to see you shred that jackson some day :D nice stuff man
I love this pattern. Great video!
What about using the repository design pattern?
controller repository services dto entity)))
This is repository pattern but lack of interface contract
Writing code is like writing text: it's not only for your, but also for who's going to read it next. Yes, even you will change, and at some point, reading your code after a year will look almost like somebody else written it.
That's why structuring the code right not only important, but I'd also say respectful.
But it's not only that, using a good project architecture requires you to know how things really work, and trust me, people notice that.
What does structuring "right" mean?
@@vincaslt structuring the code in the right way!
@@Fred_Klingon but what is the right way?
@@vincaslt the right way for me is the one that makes your code readable, easy to maintain and refactor, by having different "layers", if you watched the video there's a clear example of why mixing things is bad.
Very cool idea 🙂
Could you please create a Project by watching and checking it with a Figma file having any design and upload that video to this channel so that we learn & get benefits?
We need to learn the strategy to complete a project quickly through Figma.
Great video man!
Component libraries can be a pain to do it, it is possible but can be a pain. Also say using ShadCN, but not all things will use it.
If we move CRUD operations to findOne, findAll, create, update, remove api fetch services or custom hook, useReducer Hook and database queries to repository? controller dto services entity repository
Awesome video ❤❤
what is the difference between products and productViews? I don't know how to use it like you :)
good video
best hair in the game
So weird that I'm subconsciously doing this on my latest project to make my life easier after a LOOT of bs and changes I encountered over the years.
according to this, I should be applying for senior dev job, despite never having worked as a dev... how am I supposed to know which position am I supposed to apply for?!
treinee 😊
isn't it kind of like making your own library to wrap another library
I'm an old developer - have they stopped teaching design patterns in computer science ? Or is the problem that the people who are developers don't actually have any formal education ?
🔥🔥🔥
TRPC routers!
Auth should be in a context it looks like
Isn‘t this the basics for programming 😅? We learned this in the first class of programming in the university…
I'd say take it a step further. Instead of just declaring facades with functions that take in a userId, have the function receive a db object that implements the functionality via an interface. So when you want to switch libraries, you can just make a new db object and pass that in instead. Now you're really making that Bob guy proud
And, of course, create a factory to generate the database objects based on a strategy object that you inject as a dependency.
You just extracted functionality into separate utils functions, I mean that’s not really senior… you didn’t say anything about dependency injection, abstractions, interfaces, etc.
For example if you wanna test your application are you just gonna depend on drizzle or mock every one of those functions you created?
I was expecting an injected db operation adapter using interfaces
Also an auth library is exactly something you would like to change in the future, not your ORM 😅, the ORM is already the abstraction of your db
I'm meeting some "seniors" devs that thinks this (good) practice to be bad because it is just an indirection and now you need to jump to another file to understand what is happening... ¯\_(ツ)_/¯
And they're right.
it depends on how your project will evolve. call the database directly in frontend is cursed as fuck, you should at least create an abstraction for mocks
cool
Sorry i am not a full stack guy but knowing a bit of patterns, isnt this just a dal ?
Your first mistake is using ORMs. If you use SQL, you don't have anything to change.
Procedural coding is still king
Use a Controller Folder
opt for clean architecture instead??
This is similar to repository pattern
First Comment
👑 this is for you
Ah, what an achievement! Congratulations! 🎉
🥇
I wish you make video once a month/biweekly rather 3 days a week,
and focused more on backend.
Definitely improvement, but it's still bloated. I would actually introduce some architecture here, use layers, split by feature/bounded context and communicate by facades, since folder structure is not architecture, it's just folder structure. It will simplify apps scaling, and reusing some of "modules" and share them between project, even refactoring them to separate libs or parts of mono repo etc.
A lot easier is to think about this when you actually will have unit test in your code base. FE devs very slowly adapts DDD approach.
And here I was thinking that this was common sense. Welp, guess not.
you learned it from somebody else, it wasn't "common sense" for you either.
Third!
I first read this as "How to Use Liberals Like a Senior Dev"
Guess I've been watching too much election stuff
zoomers invent SOLID
Extracting util functions for db queries has nothing to do with SOLID.
Second
S.O.L.I.D
Lets get a video on how to get sleep at night like a senior dev
bro i am srry to say but its annoying to see your left eye flickering too much but you are doing great work
holy balls... just use SQL instead of the whatever that is
Its an "ORM" that most likely uses SQL under the hood.
Advantage: Easier to write + Type safety.
Disadvantage: Often bad for performance in some niche scenarios where performance matters.
That's very basic. No good dev doesn't modularize it db functions.
Exactly
I see nothing fancy about this
Are you Okay Bro... you look exhausted...or something