Quick Start Node

Welcome to Quick Start Node, a template repository to kickstart your Node.js projects with a solid foundation and best practices.

Project Overview

Quick Start Node provides a generic starting point for your Node.js projects, complete with a well-organized project structure, common dependencies, and essential configurations. It's designed to help you save time and ensure consistency across your projects.

Getting Started

Follow these steps to get your project up and running:

1. Clone this repository to your local machine.
2. Navigate to the cloned directory: cd quick-start-node.
3. Install dependencies: npm install.
4. Customize the env code or change it as needed. Copy example.json and paste the content in three files: development.json, production.json and test.json: cat ./env/example.json | tee ./env/development.json ./env/production.json ./env/test.json > /dev/null.
5. Start the server: npm run start

Usage

This template covers the basic structure and setup of a Node.js project. You can adapt it for various types of applications:

• Define your routes and controllers in the src/routes and src/controllers directories.
• Model your data and schema in the src/models directory.
• Utilize middleware functions in the src/middleware directory.
• Expand your application logic in the index.js file.

Customization

• Dependencies: Add or remove dependencies by modifying the package.json file.
• Configuration: Adjust configuration settings in the env/ directory. Copy all code from example.json file to new files development.json, test.json and production.json in same directory and add or change the data. You can run this in in your package root also cat ./env/example.json | tee ./env/development.json ./env/production.json ./env/test.json > /dev/null.
• Scripts: Customize scripts in the package.json file to match your development workflow.

Testing and Development

• Start the development server: npm run dev.
• Run unit tests: npm run test:unit
• Run integration tests: npm run test:integration
• Set up additional testing configurations in the tests directory.

Tech Stack and Dependencies Used.

• Node Js
• Express Js
• Mongo DB

For other dependencies please check package.json file.

Project Structure

You can use these commands to print your project tress:

• CMD: tree /A /F | findstr /V /C:"node_modules"

• POWERSHELL: Get-ChildItem -Recurse | Where-Object { $_.FullName -notlike "*\node_modules\*" } | ForEach-Object { $_.FullName }

• UBUNTU (WSL): tree --prune -I 'node_modules' --dirsfirst or tree -a -I 'node_modules|.git' --dirsfirst

1quick-start-node/
2├── .github
3│   └── workflows
4│       └── build-lint-test.yml
5├── .vscode
6│   ├── extensions.json
7│   └── settings.json
8├── env
9│   ├── development.json
10│   ├── example.json
11│   ├── production.json
12│   └── test.json
13├── logs
14│   ├── error.log
15│   ├── uncaught-exceptions.log
16│   └── unhandled-rejections.log
17├── public
18│   ├── data
19│   │   ├── http-status-codes.js
20│   │   └── programming-error-codes.js
21│   ├── images
22│   │   ├── avatar1.png
23│   │   └── avatar2.png
24│   └── styles
25│       └── index.min.css
26├── src
27│   ├── assets
28│   │   └── scss
29│   │       ├── _about-us.scss
30│   │       ├── _contact-us-email-template.scss
31│   │       ├── _contact-us.scss
32│   │       ├── _footer.scss
33│   │       ├── _header.scss
34│   │       ├── _home.scss
35│   │       ├── _page-not-found.scss
36│   │       ├── _variables.scss
37│   │       └── index.scss
38│   ├── configurations
39│   │   ├── index.js
40│   │   ├── logger.js
41│   │   ├── mongo-atlas.js
42│   │   ├── nodemailer.js
43│   │   └── set-environment-config.js
44│   ├── controllers
45│   │   ├── auth-controller.js
46│   │   ├── index.js
47│   │   ├── pages-controller.js
48│   │   ├── reset-password-controller.js
49│   │   └── user-controller.js
50│   ├── middlewares
51│   │   ├── async-error-handler.js
52│   │   ├── index.js
53│   │   ├── is-authenticated-middleware.js
54│   │   ├── is-valid-object-id-middleware.js
55│   │   ├── log-request-info-middleware.js
56│   │   ├── uncaught-errors-middleware.js
57│   │   ├── use-middlewares.js
58│   │   └── validate-and-sanitize-request-middleware.js
59│   ├── models
60│   │   ├── Temporary-Token.js
61│   │   ├── User.js
62│   │   └── index.js
63│   ├── routes
64│   │   ├── auth-route.js
65│   │   ├── index.js
66│   │   ├── pages-route.js
67│   │   ├── reset-password-route.js
68│   │   └── user-route.js
69│   ├── utilities
70│   │   ├── format-error.js
71│   │   ├── format-response.js
72│   │   ├── get-project-name.js
73│   │   ├── index.js
74│   │   └── string-utilities.js
75│   ├── validators
76│   │   ├── auth-validators.js
77│   │   ├── index.js
78│   │   ├── pages-validators.js
79│   │   ├── reuseable-validators.js
80│   │   └── user-validators.js
81│   └── views
82│       ├── components
83│       │   ├── footer-mixin.pug
84│       │   └── header-mixin.pug
85│       ├── emails
86│       │   └── email-template.pug
87│       ├── about-us.pug
88│       ├── contact-us.pug
89│       ├── home.pug
90│       └── page-not-found.pug
91├── tests
92│   ├── integration
93│   │   └── routes
94│   │       └── user.test.js
95│   ├── unit
96│   │   ├── configs
97│   │   │   └── mongo-atlas.test.js
98│   │   ├── middlewares
99│   │   │   └── is-authenticated.test.js
100│   │   └── models
101│   │       └── User.test.js
102│   └── setup.js
103├── .eslintrc.json
104├── .gitignore
105├── LICENSE
106├── README.md
107├── index.js
108├── package-lock.json
109└── package.json

Conventions

Naming

• Variables: Utilize camelCase when naming variables.
• Files:
  • Apply kebab-case for file names (e.g., is-authenticated-user.js).
  • In cases of repetitive file names, consider appending the folder name to improve clarity and organization.
    • For example, if "user" appears in multiple places, name files as user-route.js, user-controller.js, user-middleware.js.
• Classes:
  • Opt for PascalCase when naming classes (e.g., User).
  • The files containing classes should follow PascalCase + kebab-case (e.g. User-Class.js).

File Organization

The project employs a meticulous folder structure to uphold a neat and methodical codebase:

• /public: Serves as the repository for static files.
• /env: Hosts environment and confidential files, catering to various environments. Files such as development.json, test.json, and production.json are ignored; however, an illustrative example.json is included.
• /tests: Houses test files, further categorized into:
  • /unit: Reflects the /src structure, housing unit tests.
  • /integration: Resonates with the /src layout and contains integration tests.
• /src: The primary source folder, home to JavaScript files and a spectrum of subfolders encompassing distinct components:
  • /assets: Designated for assets, including SCSS and more.
  • /configurations: Houses assorted settings like MongoDB, logger, and nodemailer.
  • /controllers: Encompasses code pertinent to route handlers.
  • /middlewares: Hosts middleware modules catering to application logic.
  • /models: Encapsulates schemas and methods tailored for database models.
  • /routes: Holds handler functions for diverse API endpoints.
  • /utilities: Features utility functions and classes.
  • /validators: Contains validation logic dedicated to user data.
  • /views: Nurtures the creation of views and components via the Pug templating engine.

API Endpoints

Routes are created using Express.js routes. Some of them are:

• /api/
• /api/about-us
• /api/contact-us
• /api/users/
• /api/users/me
• /api/users/:userId
• /api/auth/login
• /api/auth/logout
• /api/reset-password

HTTP Verbs Used

• GET : Use this to fetch data from the DB to client
• POST: Use this when creating new record in DB
• PATCH: Use this when you partially update any entity
• DELETE: Use this when you are performing delete operation

HTTP Status Codes

Some of the status codes used are see all here in a file:

• 200 Used when you get data successfully.
• 201 Used when your data created successfully.
• 400 Used when there is bad request from the client.
• 401 Used when user is not authenticated.
• 403 Used when user is authenticated but do not have permissions to access resource.
• 404 Used when data not found.
• 422 Used when payload key(s) is valid but the data in the key(s) are unprocessable.
• 500 is used for internal server error.

Contribution

Contributions are welcome! If you encounter issues or have improvements to suggest, please create a pull request.

Thank you for considering contributing to this project!

License

This project is licensed under the MIT License.