This right here is an absolute truth. My first expressJs app was a single line with an accumulation of all that I learnt as I went. Now I can't even look at it without my eyes bleeding. One thing that is underrated/not emphasized enough is that the first version of any app is the TRUE process of requirement gathering/skill proficiency: that's where you really close the gap between the things _you know that know_ and the things _you don't know that you don't know_
Not necessarily. There are beginners who write cleaner code than most experienced developers. It depends on the teacher and/or learning material source
For advance mode: I suggest adding a repositories folder, where it handles the database operations, and letting the services just handling the business logic. It makes it easier to migrate to another database.
@@florianfanderl6674 , I got your point, but I saw this twice, and the last one has been very smooth due to this practice. Moreover, It doesn´t hurt to implement it just in case. Anyway, keep the risk matrix chart in mind based on the requirements.
@@yankarlotexeira well at least you had that case. First time I hear somebody actually did that. I tend to get VERY cautious, if people put things into code they don't need more, but might need later. Also later never arrives. Add 15 of such things and you for a mess. E.g. there's also the habit of putting 100 random things into application config that actually don't change, just because they seem to belong into the application config. Even worse when they're actually not really supported to change. There are so many ways to make software generic and it really helps when this piece of software actually needs to be generic for a real need. But I heavily advise against it, just for the "what if". But yeah, data access in general isn't too hard to abstract. So it doesn't introduce a lot of complexity.
@@chesswithsarang yes. It makes easier to isolate problems, easier to do unit tests, and in my opinion it would make the code cleaner and more maintainable.
A separate data layer could also be added in the advanced section. This layer will interact with db and could be imported in the service layer to be used as a database adaptor. Then in case of a db swap, just the adaptor has to be re-implemented without even touching the rest of the application.
In advanced level : I like separation of api versioning api/v1, api/v2 but its debatable for versioning vs subdomain. Rather than that i prefer app folder containing MVC + index.ts (entry point) Initially and if the project scales then separation based on component/functionality i.e lets say we've 3 comp. user, product, order. so each comp. have their own MVC, rest is same. What do you think ?
We can keep the Models and Helpers out of the api/v1 folder because the database models do not depend on the version of API. Also, the utils/helpers also don't change I guess.
Obrigado Pedro! Your videos have been helping me a lot in getting back into web dev after a few months break. You're the man! Can you point out any public repos for advanced projects that use a similar stack and structure? I think that would really help connect all the dots if we could see something simmilar implemented in a mature project. Cheers! Keep it up on being awsome!
Hi Pedro, thanks for sharing it. I was going really crazy about folder structure and in the end you make very clear that there's more about it than meets the eye.
I'm a programmer of 20 years and I've been strongly questioning MVC lately especially on the backend. Mainly there is a lot more logic that needs to be shared. It's obvious services needed to be invented because it couldn't all be contained in the controller level, but it's still not good enough. The model layer is also outdated. It's just a thin layer to the DB so it shouldn't be given so much weight. Applications are no longer desktop apps that save data on a hardrive. We have lots of logic that needs to be shared between lots of services and controllers. We probably need something that is more along the lines of (Routes) | (Controllers) | (Logic -> Components -> Small Functions, External API Calls and Models). Top level in () and -> is nested. Logic is where the business logic is and it may call other peer elements at times. Components would only ever call lower in the tree.
@@katalystcod2Lately I have, Routes, Controllers, Services, and Utilities. I don't personally use a database folder because I always an ORM and database access doesn't require any complex connection logic. That's on the backend. If we're talking about the front end then a lot of people are using projects like Next.js where the routes are actually defined by the file location, then you might have a global Context folder where your "model" is but you don't call it that. Then you may also have "hooks" and "components" folders for re-usable logic. My main point is that on both the backend and the front end it makes more sense to organize things by what we actually need and what we're actually doing and that's how most modern projects are organized. Having an actual "model", "view", and "controller" folder isn't always necessary. It's more a general concept. Although I do use a controller folder on the backend. On the front end a "controller" folder isn't really necessary.
QUE MASSA! Eu tinha essa curiosidade desde que comecei a desenvolver APIs e finalmente achei um conteúdo massa sobre isso! Parabéns mano! (Mais legal ainda é ter assistido o video inteiro achando que era de algum americano e no final descobrir que é um brazuca hahahah)
Ganhou mais um inscrito. Estou em busca de vídeos mais avançados assim já faz algum tempo. A maioria dos vídeos são bem "Getting Started" e não mostram as melhores práticas que podem facilitar na escalabilidade dos projetos. Obrigado!!!
Muito bacana Pedro! Vc foi direto ao ponto. Espero que você faça um video de um projeto com essa estrutura avançada de pastas, junto com REACT, usando talvez o PERN stack e usando o TDD. Já me inscrevi. Quero passar pra senior e ter modelos como inspiração para futuros projetos.
what if we have also have contents in v2 directory, then how will your directory structure change as we also have to make sure we are not repeating the code, eg you have put Helpers inside v1 . any comments on that...?
What do we have to put in the index.ts file that you create in the service folder of advance level? Do we need to add something in particular in order to access the classes the way you explained it, by only calling the service folder when we do the import?
For the index.ts files. I guess the concept is a bit confusing. Shouldn't it say export since you're exporting the files in those folders so they can accessed elsewhere?
hey, thanks for the video! would clerify what goes in the "service" folder? would this be someting like getting extra resources from another restAPI or even connecting with another webservice like optimizing photos etc?
hey hi I made an api with express. and the pictures are on the same port.. I can access the links of my pictures from a different server, but I can't show the pictures.
Shouldn't controllers, services & models be grouped together per "domain" (or entity) api>users>(user.service.ts, user.model.ts, user.controller.ts) ? When the project will grow it will be easier to find what you're searching for
Hi , hee is the best explanation of folder structure. I have a question. Can you tell me how to manage the folder structure in the case of when are writting code for admin , user and vendor in the same project. Please explain this as well ... Thank you
You only mention validation in the controllers. I personally do my validation in a middleware. Does that mean that to divide up my files into controllers and services is unnecessary? Feels like there are more to controllers than validation. If you could shed some more light on controllers/services and how to think about that-if one is using that pattern, I know it is not a must-that would be really helpful. Thank you!
Thank you pedro for such an amazing video. I had looking for something like this all around. I am now planning to use your intermediate folder structure, as I am fairly new to Nodejs. I have one doubt though, where should I place 3rd Party API Calls? 3rd Party API calls I am integrating will include CRUD operations of their own. Infact, I need to perform CRUD in my database based on success/failure of 3rd party API CRUD operations. Any suggestions will be of great help.
I don't like that you keep your versions in the repo. I would rather use github and add a commit or some kind of tag where I say that this is the v1 of the api. Then I can easily update to that commit if I need v1. But if I keep it in the repo there is a lot of dead code. On the one hand your approach is more comfortable, but the approach I would use is cleaner imo.
People love to say as a beginner dont…. Lmao as a beginner, do because no one cares who long you’ve been coding, they will expect baller level code from you from day 1
I've worked with a lot of projects that use typescript and don't. With good test coverage typescript really becomes obsolete and development time increases dramatically. As developers we need to always be aware of when a tool was invented just to give developers more to do with their time and when it is actually helpful. Introducing typescript increases the code quantity by 30% and increases the bug surface level by exactly double since every piece of code can now fail at the abstraction level as well. Until types are officially part of JavaScript it's always going to be just another failure point without any real affect on the outcome.-- but real slowdown on developer time.
"if you're a beginner, dont worry about folder structure too much, you're gonna write garbage code anyways" LMAOOOOO
Hahaha I still remember my first nodejs / express project. I wrote a whole API for a social media platform in a single file :)
@@PedroTechnologies damn hahaha, great video though, i think i'll do a mix of all 3 types that you showed for my project
sam
This right here is an absolute truth. My first expressJs app was a single line with an accumulation of all that I learnt as I went. Now I can't even look at it without my eyes bleeding.
One thing that is underrated/not emphasized enough is that the first version of any app is the TRUE process of requirement gathering/skill proficiency: that's where you really close the gap between the things _you know that know_ and the things _you don't know that you don't know_
Not necessarily.
There are beginners who write cleaner code than most experienced developers.
It depends on the teacher and/or learning material source
For advance mode: I suggest adding a repositories folder, where it handles the database operations, and letting the services just handling the business logic. It makes it easier to migrate to another database.
How often did you migrate to another database? I hear this argument so often, but I havent changed the database once, nor has anybody I know.
@@florianfanderl6674 , I got your point, but I saw this twice, and the last one has been very smooth due to this practice. Moreover, It doesn´t hurt to implement it just in case. Anyway, keep the risk matrix chart in mind based on the requirements.
@@yankarlotexeira well at least you had that case. First time I hear somebody actually did that. I tend to get VERY cautious, if people put things into code they don't need more, but might need later. Also later never arrives. Add 15 of such things and you for a mess. E.g. there's also the habit of putting 100 random things into application config that actually don't change, just because they seem to belong into the application config. Even worse when they're actually not really supported to change. There are so many ways to make software generic and it really helps when this piece of software actually needs to be generic for a real need. But I heavily advise against it, just for the "what if". But yeah, data access in general isn't too hard to abstract. So it doesn't introduce a lot of complexity.
hey, In my code I am using mySQL queries inside APIs. So according to you I should have repository folder containing a file with query?
@@chesswithsarang yes. It makes easier to isolate problems, easier to do unit tests, and in my opinion it would make the code cleaner and more maintainable.
It's amazing how difficult finding information on this topic has been. Thanks.
Finally, I couldn't find anyone that actually explained it.
A separate data layer could also be added in the advanced section. This layer will interact with db and could be imported in the service layer to be used as a database adaptor. Then in case of a db swap, just the adaptor has to be re-implemented without even touching the rest of the application.
Good point!
In advanced level : I like separation of api versioning api/v1, api/v2 but its debatable for versioning vs subdomain. Rather than that i prefer app folder containing MVC + index.ts (entry point) Initially and if the project scales then separation based on component/functionality i.e lets say we've 3 comp. user, product, order. so each comp. have their own MVC, rest is same. What do you think ?
We can keep the Models and Helpers out of the api/v1 folder because the database models do not depend on the version of API. Also, the utils/helpers also don't change I guess.
Thank you Pedro this is what i needed for my project :)
Obrigado Pedro!
Your videos have been helping me a lot in getting back into web dev after a few months break. You're the man!
Can you point out any public repos for advanced projects that use a similar stack and structure? I think that would really help connect all the dots if we could see something simmilar implemented in a mature project.
Cheers! Keep it up on being awsome!
Hi Pedro, thanks for sharing it.
I was going really crazy about folder structure and in the end you make very clear that there's more about it than meets the eye.
Didn't know there was a video on this LOL. Ended up watching one of your tutorial series video to see how things were structured!
Hahaha hope you liked it :)
Amazing content, dude! I'm trying to improve my code and you're helping me a lot. Really appreciated! :)
Thats awesome! I am glad you are learning!
@@PedroTechnologies TMJ!
I'm a programmer of 20 years and I've been strongly questioning MVC lately especially on the backend. Mainly there is a lot more logic that needs to be shared. It's obvious services needed to be invented because it couldn't all be contained in the controller level, but it's still not good enough. The model layer is also outdated. It's just a thin layer to the DB so it shouldn't be given so much weight. Applications are no longer desktop apps that save data on a hardrive. We have lots of logic that needs to be shared between lots of services and controllers. We probably need something that is more along the lines of (Routes) | (Controllers) | (Logic -> Components -> Small Functions, External API Calls and Models). Top level in () and -> is nested. Logic is where the business logic is and it may call other peer elements at times. Components would only ever call lower in the tree.
so what do you propose? give a concrete example with file structure and logic?
@@katalystcod2Lately I have, Routes, Controllers, Services, and Utilities. I don't personally use a database folder because I always an ORM and database access doesn't require any complex connection logic. That's on the backend. If we're talking about the front end then a lot of people are using projects like Next.js where the routes are actually defined by the file location, then you might have a global Context folder where your "model" is but you don't call it that. Then you may also have "hooks" and "components" folders for re-usable logic.
My main point is that on both the backend and the front end it makes more sense to organize things by what we actually need and what we're actually doing and that's how most modern projects are organized. Having an actual "model", "view", and "controller" folder isn't always necessary. It's more a general concept. Although I do use a controller folder on the backend. On the front end a "controller" folder isn't really necessary.
Thanks Pedro for this. Please make more content on production grade setup and practices.
I really enjoyed the support on this video so I plan on making more like this!
QUE MASSA! Eu tinha essa curiosidade desde que comecei a desenvolver APIs e finalmente achei um conteúdo massa sobre isso! Parabéns mano!
(Mais legal ainda é ter assistido o video inteiro achando que era de algum americano e no final descobrir que é um brazuca hahahah)
Kkkkkkkk muita gente nao percebe até ler meu nome. Fico feliz que gostou do video :)
What a great tutorial! concise, yet really informative!
Glad you liked it
I like how the beginner folder structure had PascalCase for the folder names, kinda like class names lol. Great video, very informative!
Short and precise. Best combo 👍
Glad you think so!
Ganhou mais um inscrito. Estou em busca de vídeos mais avançados assim já faz algum tempo. A maioria dos vídeos são bem "Getting Started" e não mostram as melhores práticas que podem facilitar na escalabilidade dos projetos. Obrigado!!!
Thanks for this video it helped so much man, especially right now in my bootcamp.
Great tutorial man! I'm just getting into React so this was helpful :)
Glad it helped!
That's all that I needed. Thanks, buddy
Muito bacana Pedro! Vc foi direto ao ponto. Espero que você faça um video de um projeto com essa estrutura avançada de pastas, junto com REACT, usando talvez o PERN stack e usando o TDD. Já me inscrevi. Quero passar pra senior e ter modelos como inspiração para futuros projetos.
what if we have also have contents in v2 directory, then how will your directory structure change as we also have to make sure we are not repeating the code, eg you have put Helpers inside v1 . any comments on that...?
I the advanced section of this video, what type of test is the test folder that sit alongside src be running
Great bro! This is an excellent content we need. Keep it up!
Really appreciate it! I am happy you liked it!
This video was very beneficial for me thanks a lot for such a good video, this kind of video is a need for the UA-cam community. wish you the best.
What do we have to put in the index.ts file that you create in the service folder of advance level? Do we need to add something in particular in order to access the classes the way you explained it, by only calling the service folder when we do the import?
For the index.ts files. I guess the concept is a bit confusing. Shouldn't it say export since you're exporting the files in those folders so they can accessed elsewhere?
for intermediate express api what will be present in the config folder ?
Question... How Can you call the modules related to controller or you use a Shared Module.? I like Advanced Folder Structure
This was very helpful thank you!
I wanna know is that, advance structure is control by only one person ? Or multiple members work on it to maintain it ?
hey, thanks for the video! would clerify what goes in the "service" folder? would this be someting like getting extra resources from another restAPI or even connecting with another webservice like optimizing photos etc?
Yes!
Beautiful! Exactly what I was looking for. Thanks so much.
Do you suggest mocking a local database for testing database querying
Thanks for creating this video. Really helped a lot
thanks for the video dude!, really good content!
Thank you for this great overview!
Hi, do you have any project that uses medium or advanced structure? I would like to see what code goes in the folder
Thank you for sharing your knowledge! really great stuff!!!
Glad you liked it!
this is so well explained, thanks pedro
hey hi
I made an api with express. and the pictures are on the same port.. I can access the links of my pictures from a different server, but I can't show the pictures.
What would be the folder structure for react large project where we call Apis as well as axios request etc..
I want to make a video on react project structures! But I would create a personalized hook for making api calls!
What are the other popular design patterns?
Apart from MVC
Informative ! Folder structure + some code would have been more useeful ~
Very Clean Explanation wonderful
Great stuff..Kudos on the intro... testing express n mongo APIs TS with jest... something to cover in the next video?
Thank you! I am planning on doing a video on API testing!
Seconded! Jest/supertest. Also a video on mocking best practices would be awesome.
This is a great one dude.. Can you make a tutorial using the advanced folder structure for a project?
This is helpful, thank you!
What I personally prefer is creating separate folder for each function/component like Auth, user, pages, etc.
And the validation folder is for? validation for like form inputs?
Hey bro, can you please tell the name of this VScode icon extension ?
Brazilian hug 😎
Amazing content! Thank you for this video
Glad you liked it!
Really appreciating content 👍👍
Plz make video on mvc model which u talked about.
I plan on it! Thank you!
Thank you! Why would you do validation in the controller instead of the service? isn’t that business logic?
Shouldn't controllers, services & models be grouped together per "domain" (or entity)
api>users>(user.service.ts, user.model.ts, user.controller.ts) ?
When the project will grow it will be easier to find what you're searching for
Great video Pedro thank you!
Glad you liked it!
thank you, this was very helpful!
Hi , hee is the best explanation of folder structure. I have a question. Can you tell me how to manage the folder structure in the case of when are writting code for admin , user and vendor in the same project. Please explain this as well ... Thank you
I also like having a "utils" folder where I add all the utility functions
Can you give me a links for projects that follow intermediate and advanced structure
You only mention validation in the controllers. I personally do my validation in a middleware. Does that mean that to divide up my files into controllers and services is unnecessary? Feels like there are more to controllers than validation.
If you could shed some more light on controllers/services and how to think about that-if one is using that pattern, I know it is not a must-that would be really helpful. Thank you!
I have a validation middleware too! I just create the YUP schema in the validations folder!
That doesn’t answer my question, but thank you anyway.
What are different design patterns?
Really good video
Thanks a lot
Adorei o canal, agora preciso aprender inglês "de vdd" hahaha
kkkkkkk obrigado mano!
src (model controller middleware helper environment router)
Always use that schema folder in api what I made
Hi Pedro! Nice video. I have a question, how to upload a project with front and back to GitHub? Frontend and Backend in the same repository?
In the project, I have the "client" folder (React Native), and the "server" folder (API REST with MySQL).
I always recommend separating the repositories!
I would separate the repos and upload the client to the google play store and the server to either aws, zeet, or heroku!
@@PedroTechnologies thank you so much bro!
Thank you pedro for such an amazing video. I had looking for something like this all around.
I am now planning to use your intermediate folder structure, as I am fairly new to Nodejs.
I have one doubt though, where should I place 3rd Party API Calls?
3rd Party API calls I am integrating will include CRUD operations of their own. Infact, I need to perform CRUD in my database based on success/failure of 3rd party API CRUD operations. Any suggestions will be of great help.
Great videos. Pls Pedro, can i know the differences between services ans helpers in your project structure
Are you using yarn 2? Could you make a video on package managers, great video btw
Thank you! Yes I use yarn 2! I can make one but I think both npm and yarn are equally good
I will definitely subscribe to this channel
How did you make that sweet intro? Pls do a video on that!
Hahaha I didn’t make it! I paid an awesome person on fiver to make it for me. Trying to improve the video quality!
@@PedroTechnologies ah gotcha good thinking
Guys don't overcomplicate stuff, if you wanna have advanced folder structure, use nest js.
Excellent job amazing
Can make simple project for this structure to be amazing
Great informative video. I was a bit confused to start & you have made it clear to me. Thanks
Glad I was able to help!
Beginner here, I did not understand what it is used for .env =(
Great video !
would you make a simple real example using this advanced structure? or if you sell it in a course it would be great :(
Thanks Pedro
Amazing tips!!!!
Thank you! Glad you liked it!
nice video, can you put git links for these folder structures with some boilerplate code.
This was a long time ago so I don't know if I still have the folder with all of this. But I can defo create one and put the link!
It's great, thanks!
I don't like that you keep your versions in the repo.
I would rather use github and add a commit or some kind of tag where I say that this is the v1 of the api.
Then I can easily update to that commit if I need v1. But if I keep it in the repo there is a lot of dead code.
On the one hand your approach is more comfortable, but the approach I would use is cleaner imo.
Muy buen video Pedro
People love to say as a beginner dont…. Lmao as a beginner, do because no one cares who long you’ve been coding, they will expect baller level code from you from day 1
@PedroTech Now we have a Clean Architecture. That also needs your attention.
Next Please Service workers :) PWA = Progressive web applications ;)
I love PWA's so I can definitely make a video on it!
Noice !! :) great job
Thanks! 😄
MVC is an architectural patter, not a design pattern
can you do video on JEST / Testing
new Intro
Glad you liked it! Im very happy with the result!
como tu conseguiu ficar sem sotaque?
Vlw, Pedro
a new begining.
Yes!!
@@PedroTechnologies best of best supportive content .We are counting on you .Really appreciated.
Good job
excellent
Thanks!
I've worked with a lot of projects that use typescript and don't. With good test coverage typescript really becomes obsolete and development time increases dramatically. As developers we need to always be aware of when a tool was invented just to give developers more to do with their time and when it is actually helpful. Introducing typescript increases the code quantity by 30% and increases the bug surface level by exactly double since every piece of code can now fail at the abstraction level as well. Until types are officially part of JavaScript it's always going to be just another failure point without any real affect on the outcome.-- but real slowdown on developer time.
i think ddd folder bester than mvc folder
Nice!