Prelude
I've worked over several backend technologies, starting from PHP, then moving to RoR before getting my hands on NodeJS. I love h...
For further actions, you may consider blocking this person and/or reporting abuse
I think it's not a secret for anyone that express.js is a dead project. Gets some packages updated every half of the year, and it hasn't changed in 5 years.
Outdated, and slow, with a whole bunch of legacy code supporting very old node versions. Why do you need It?
I highly recommend not making a monolith when your client side and server side are together in the same project. Create two projects and use the API.
I disagree that express is dead. Are you even up with the latest frameworks like NestJS, NextJS etc.. which have over a million downloads a week on npm registry? They all use express under the hood. Just because youโre not using it directly doesnโt mean it is dead. There are 65k dependent packages as we speak.
you damn right man... I disliked Express cause of having no structure and was annoying when projects got bigger and bigger. It was till the day I started workign with Nestjs... OHHH My God!!!! Is this a dream??? OOP , Modularity, scalablity!!! Am I alive!! you are right man, nestjs is on top of Express and Fastify, but with a turning point feature which is it's modularity and OOP style and many industry standard features that come out of the box.. I love it man.
Lol Okay!
How is Expresssjs a dead project? They have been pushing out updates regularly.
Secondly I've stated that the above could be used as a website and as a standalone project if it's API only. The only thing you need to do is get rid of public and src like folders which are not relevant. Rest stays pretty much the same.
Stop using
dotenv. Use wj-config. It is far better.Not to be super critical, but you should probably disclose that you're the only contributor to wj-config, a project that's only a few months old, when you promote your own work. Telling someone to stop using something because your creation is "far better" as a single, isolated statement without justification, context, or evidence, is self-biased.
Yes, it is self-biased. I, however, would not invest time in trying to solve something that already has an acceptable solution. I come from the .Net environment where configuration is far more robust. When I had the need for configuration in the JavaScript realm it was a shock for me. I could not stand the current configuration solutions, so I made my own.
As far as being the only contributor or being a few months old, I don't see the relevance. The product can speak for itself, regardless of who made it, I would say.
It might not seem relevant to you as the author -- it's certainly relevant to everyone else in the community when you express authoritative (and biased, self-promoting) comments and tell somebody what to do (or stop doing), as you did. A bit of self-awareness as well as a little tact toward the author of the post you commented on is healthy, friend.
Ah, I see now what you meant. It is not about the capability of the package, it is about the social aspect of the sentence. I just wrote that quickly, as I do most comments, without a second thought.
I get it. I meant no disrespect towards the author. I simply volunteered an option without much second thought.
What problem does it solve in the above context as opposed to using dotENV?
I find this very insightful. I don't really understand why people would keep suggesting and/or tell people to use a different library than the ones mentioned in this article, but I totally get that there are libraries that are better than the ones we use, but this focuses on the stuff that the majority of the developers/engineers use. I also do think this post is usually for those who want to learn and understand and gain different approaches and perspective from different people in terms of file architecture.
I don't know way I don't love this kind of folder structure where route, controller are not at the same file
Here What I prefer:
`
project-root/
โ
โโโ src/
โ โโโ api/ # Group controllers, routes, and validation by feature
โ โ โโโ user/
โ โ โ โโโ user.controller.ts # User controller
โ โ โ โโโ user.route.ts # User routes
โ โ โ โโโ user.validation.ts # User input validation (optional)
โ โ โ โโโ user.service.ts # User-specific services
โ โโโ database/
โ โ โโโ Redis.database.js
โ โ โโโ Mongo.database.js
โ โ โโโ auth/
โ โ โโโ auth.controller.ts # Auth controller
โ โ โโโ auth.route.ts # Auth routes
โ โ โโโ auth.service.ts # Auth service
โ โ โโโ auth.validation.ts # Auth validation (optional)
โ โ
โ โโโ config/ # App configuration (environment, database, etc.)
โ โ โโโ database.ts # Database connection
โ โ โโโ env.ts # Environment variable configuration
โ โ โโโ logger.ts # Logger configuration
โ โ
โ โโโ middlewares/ # Custom middleware (authentication, error handling)
โ โ โโโ error.middleware.ts # Centralized error handling
โ โ โโโ auth.middleware.ts # Auth middleware for protected routes
โ โ โโโ validate.middleware.ts # Validation middleware for request schemas
โ โ
โ โโโ models/ # Mongoose/Sequelize models or DB schemas
โ โ โโโ user.model.ts # User model (Mongoose, Sequelize, etc.)
โ โ โโโ auth.model.ts # Auth-related model (tokens, sessions, etc.)
โ โ
โ โโโ services/ # Business logic and reusable services
โ โ โโโ email.service.t # Email service (send emails)
โ โ โโโ auth.service.ts # Authentication and authorization service
โ โ โโโ user.service.ts # User-related services (CRUD operations)
โ โ
โ โโโ utils/ # Helper functions/utilities (non-business logic)
โ โ โโโ httpResponse.ts # Standardized response format
โ โ โโโ constants.ts # App constants
โ โ โโโ hash.ts # Password hashing utility
โ โ
โ โโโ validations/ # Centralized validation schemas (using Zod, Joi, etc.)
โ โ โโโ user.validation.ts # User-related validation
โ โ โโโ auth.validation.ts # Auth validation
โ โ
โ โโโ app.ts # Initialize Express app
โ โโโ index.ts # Main entry point to start the server
โ
โโโ dist/ # Compiled JavaScript files (from TypeScript)
โ
โโโ node_modules/ # Dependencies
โ
โโโ .env # Environment variables
โโโ .eslintignore # ESLint ignore patterns
โโโ .eslintrc.json # ESLint configuration
โโโ .gitignore # Ignore node_modules and dist
โโโ package.json # Project dependencies and scripts
โโโ tsconfig.json # TypeScript configuration
โโโ README.md
`
Use aex instead of express
What problem is aex solving that express doesnโt? What now the only thing I can see it is pushing the use of decorators, which feels more like something a Java insisted on.
Whatโs your relationship to aex?
Just take a look at:
github.com/calidion/aex
It has at lease the following advantages over express:
And 20% faster than express.
Are you the author of aex?
AEX is the only project that makes reference to โweb straight lineโ, from what I can see. Also articles on it on medium donโt have any feedback, making me nervous about something that doesnโt have a proper discussion.
What is wrong if I am the author? So you determine things by medium not logic?
There is nothing wrong if you are the author, just that you arenโt being transparent that you are. Itโs like recommending stocks, while not disclosing you are the owner of the business.
It helps us in deciding how objective an opinion is.
For the most part, you have a great structure. I have something to add on to the structure. Basically, we can follow something called domain-driven development. By doing this we can make the codebase a lot more maintainable. You can read about it in this blog post.
Scalable Directory Structure for NodeJS + Express Web Servers
It was interesting to read your article and learn something new. I myself now work in a company and do database management. I recently had a problem, I didn't know how to quickly sync data in MySQL. So, I came across this article about sync MySQL databases Where I found a detailed guide on how to do everything. Perhaps someone will also find it useful, so I'll leave it here.
The folder structure for a Node.js and Express.js project helps keep your code organized by grouping related files together. It has separate folders for configuration, handling routes, database models, middleware, and other important parts of your app. This makes it easier to find and manage your code as your project grows.
test
ะกongratulations ๐ฅณ! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up ๐
They @mr_ali3n can you provide template of this nodejs folder structure. It would be really helpfull.
Thank You.
i am creating the mern stack project give me the folder structure
Great article!
Thanks for sharing these best practices. Itโs always helpful to see how experienced developers structure their projects to keep things manageable.
Great explanation
Useful article, especially for beginners.
A detailed explanation. It taught me a lot as a NodeJS begginer.
This folder structure seems easy to follow, clean and manageable. Thanks for this!
very useful
Your guide promotes a clear and structured approach to Node.js project organization, making it easier for developers to maintain and scale their applications.
Interesting perspective on Express.js! While some argue itโs outdated, its continued use in many modern frameworks suggests it still has a strong presence in the ecosystem.
Well said
Very useful one.
A good folder structure in your Node JS and Express JS project helps keep your code organized and easy to debug. It makes your project clearer and simpler to work with. Thank you for this blog!
Well explained! The structure is clear and easy to follow. Thanks for sharing!
๐ nice