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.
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!!!
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.
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.
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)
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!
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 ?
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.
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.
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?
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?
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
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...?
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
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.
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!
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
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.
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.
It's amazing how difficult finding information on this topic has been. Thanks.
"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.
Finally, I couldn't find anyone that actually explained it.
Thank you Pedro this is what i needed for my project :)
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!
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 :)
really nice video, knowing a common production folder structure helps understand node itself
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!
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.
I like how the beginner folder structure had PascalCase for the folder names, kinda like class names lol. Great video, very informative!
What a great tutorial! concise, yet really informative!
Glad you liked it
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.
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.
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 :)
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!
Short and precise. Best combo 👍
Glad you think so!
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 ?
That's all that I needed. Thanks, buddy
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.
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!
This video was very beneficial for me thanks a lot for such a good video, this kind of video is a need for the TH-cam community. wish you the best.
Informative ! Folder structure + some code would have been more useeful ~
Great tutorial man! I'm just getting into React so this was helpful :)
Glad it helped!
Thanks for creating this video. Really helped a lot
Beautiful! Exactly what I was looking for. Thanks so much.
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.
Great bro! This is an excellent content we need. Keep it up!
Really appreciate it! I am happy you liked it!
Thank you for this great overview!
this is so well explained, thanks pedro
What I personally prefer is creating separate folder for each function/component like Auth, user, pages, etc.
thanks for the video dude!, really good content!
Thank you for sharing your knowledge! really great stuff!!!
Glad you liked it!
Very Clean Explanation wonderful
This was very helpful thank you!
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 helpful, thank you!
Really appreciating content 👍👍
Plz make video on mvc model which u talked about.
I plan on it! Thank you!
Great video Pedro thank you!
Glad you liked it!
Amazing content! Thank you for this video
Glad you liked it!
Thanks Pedro
Great informative video. I was a bit confused to start & you have made it clear to me. Thanks
Glad I was able to help!
thank you, this was very helpful!
This is a great one dude.. Can you make a tutorial using the advanced folder structure for a project?
I also like having a "utils" folder where I add all the utility functions
Really good video
Thanks a lot
I will definitely subscribe to this channel
Great video !
Question... How Can you call the modules related to controller or you use a Shared Module.? I like Advanced Folder Structure
Adorei o canal, agora preciso aprender inglês "de vdd" hahaha
kkkkkkk obrigado mano!
Muy buen video Pedro
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?
new Intro
Glad you liked it! Im very happy with the result!
I the advanced section of this video, what type of test is the test folder that sit alongside src be running
Excellent job amazing
Can make simple project for this structure to be amazing
Thank you! Why would you do validation in the controller instead of the service? isn’t that business logic?
Do you suggest mocking a local database for testing database querying
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?
Hi, do you have any project that uses medium or advanced structure? I would like to see what code goes in the folder
It's great, thanks!
Vlw, Pedro
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
Amazing tips!!!!
Thank you! Glad you liked it!
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...?
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
for intermediate express api what will be present in the config folder ?
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!
What are the other popular design patterns?
Apart from MVC
Noice !! :) great job
Thanks! 😄
I wanna know is that, advance structure is control by only one person ? Or multiple members work on it to maintain it ?
And the validation folder is for? validation for like form inputs?
Good stuff. Those index.ts are conventionally called "barrel files" btw.
Yes, should have used the conventional name :)
Guys don't overcomplicate stuff, if you wanna have advanced folder structure, use nest js.
Next Please Service workers :) PWA = Progressive web applications ;)
I love PWA's so I can definitely make a video on it!
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.
Hey bro, can you please tell the name of this VScode icon extension ?
Brazilian hug 😎
a new begining.
Yes!!
@@PedroTechnologies best of best supportive content .We are counting on you .Really appreciated.
src (model controller middleware helper environment router)
Always use that schema folder in api what I made
Can you give me a links for projects that follow intermediate and advanced structure
Great videos. Pls Pedro, can i know the differences between services ans helpers in your project 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 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!
Good job
@PedroTech Now we have a Clean Architecture. That also needs your attention.
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
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
excellent
Thanks!
Nice!
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
would you make a simple real example using this advanced structure? or if you sell it in a course it would be great :(
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.
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!
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!
What are different design patterns?
can you do video on JEST / Testing
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.
Beginner here, I did not understand what it is used for .env =(
MVC is an architectural patter, not a design pattern
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.