Originally published at coreycleary.me. This is a cross-post from my content blog. I publish new content every week or two, and you can sign up to ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a great post and I will be waiting for the next ones!
When I was just starting with express and react this was the most difficult part, because it is done differently in all tutorials and projects or even not done at all, or is there without any explanation. Often it is explained how to do small separate things but not how to really put them together for something bigger. I found it very frustrating. As one goes these practices are usually picked up but it is nice to have a map.
Yeah I totally agree that the "big picture" is often missing, especially when it comes to Node tutorials. When I was first learning Node I too got really confused by it, and it wasn't until I started working on real-world projects that things started to click.
Hopefully I can pass on what I've learned
in these cases out of satire/sarcasm, I follow this guide
react-file-structure.surge.sh/
Note: Awesome reading!
Haha I've never seen that link before - I somewhat agree though - like I stated in the post as long as your separation of logic is good, then the structure either falls into place, or you can change it to how you see fit later on
yeah, I agree with you!
Or ...
You create a standard REST API using the OPEN API specifications, and let the generators made by the community to do the work for you, and focus on the business.
swagger.io/tools/swagger-codegen/
github.com/OpenAPITools/openapi-ge...
PS: I did not tried the NodeJS ones, I am playing with Go at the moment and the results are pretty good, as in idiomatic, basic functionalities and easy to extend.
This is exactly the same structure I use on most of my node+express projects.
When I started working with express.js I felt the same way, couldn't find any good resources about how to structure my REST APIs, so I just build my own in the way that felt more natural to me at that time. I'm happy it makes sense for others too.
Great to hear someone else follows this too - I think it's the most logical structure to end up with if you separate the concerns of your logic like I detailed in this post. Even if you want to change the structure later, it's trivial to do so.
This is pretty much the same standard we use throughout all the projects at our company. I think it was derived from a similar structure in Java applications we used to do before moving to node.
Amazing article, thank you very much. As a junior, just learning to build my own project, this is a real treat. Building my first full-stack portfolio project with node-postgres, and I really want to put some clean, well working app on the table.
Seen a lot of articles and tutorials with abstraction over the database, like mongoose or sequelize, but I struggled to find a good explanation on how to organize my project without those.
My first controller lost 150 lines of spaghetti on the first morning I implemented this. Long way for me to go, but at least I feel like I am making an effort in the right direction.
Thank you!
I feel much more enthusiastic about my next node-express project. Thanks Corey, this was eye opener for me!
Thanks for this great post. I have an API now with fat, bloated controllers, and I'm working to clean them up now. I love how you laid this out - a reminder for why I want to get them cleaned up!
Glad to hear it was helpful! I used to get "fat controllers" all the time before I started pulling things out into services. And I've seen so many projects with the same issue, so it's a common problem.
Once you get the controllers cleaned up I think one of the biggest benefits is they become much easier to test too.