Node mongo starter kit
Nhan Nguyen
- github/nhannguyendevjs
- twitter/nhannguyendevjs
- linkedin/nhannguyendevjs
- dev.to/nhannguyendevjs
- medium/nhannguyendevjs
Copyright Β© 2024, Nhan Nguyen.
Released under the MIT License.
You can download and install Docker on https://docs.docker.com/desktop/install/windows-install/
docker network create node-mongo-network
docker run --name node-mongo-ubuntu --network node-mongo-network -p 80:8080 -p 443:8443 -p 22:22 -itd ubuntu:latest
docker run -d --network node-mongo-network --name node-mongo -p 27017:27017 -e MONGO_INITDB_ROOT_USERNAME=admin -e MONGO_INITDB_ROOT_PASSWORD=admin mongo:latest
docker exec -it node-mongo mongosh
mongodb://admin:admin@localhost:27017/
docker run -d --network node-mongo-network --name node-mongo-redis -p 6379:6379 redis:latest
β PascalCase π Classes and Methods
β camelCase π variable and function names
β snake_case π file names and variable identifiers
β kebab-case π HTML attributes and CSS classes
β UPPERCASE π CONSTANTS and ENUMERATIONS
β UPPER_SNAKE_CASE π CONSTANTS and ENVIRONMENT_VARIABLES
β Development (dev)
All new features and bug fixes should be brought to the development branch.
β QA/Test (test)
Contains all codes ready for QA testing.
β Staging (staging, Optional)
It contains tested features that the stakeholders wanted to be available either for a demo or a proposal before elevating into production.
β Master (master)
The production branch, if the repository is published, is the default branch being presented.
Any code changes for a new module or use case should be done on a feature branch. This branch is created based on the current development branch. When all changes are Done, a Pull Request/Merge Request is needed to put all of these to the development branch.
Examples
feature/AZURE-1234
feature/AZURE-5678
If the code changes made from the feature branch were rejected after a release, sprint or demo, any necessary fixes after that should be done on the bugfix branch.
Examples
bugfix/AZURE-1234
bugfix/AZURE-5678
If there is a need to fix a blocker, do a temporary patch, or apply a critical framework or configuration change that should be handled immediately, it should be created as a Hotfix. It does not follow the scheduled integration of code and could be merged directly to the production branch and then into the development branch later.
Examples
hotfix/disable-endpoint-zero-day-exploit
hotfix/increase-scaling-threshold
Any new feature or idea that is not part of a release or a sprint. A branch for playing around.
Examples
experimental/dark-theme-support
A branch specifically for creating specific build artifacts or for doing code coverage runs.
Examples
build/azure-metric
A branch for tagging a specific release version.
Examples
release/app-1.0.0
A temporary branch for resolving merge conflicts, usually between the latest development and a feature or Hotfix branch. This can also be used if two branches of a feature being worked on by multiple developers need to be merged, verified, and finalized.
Examples
merge/dev_lombok-refactoring
merge/combined-device-support
Use clear, descriptive names. Use camelCase for multi-word names. Avoid using MongoDB reserved words.
- Prettier - Code formatter
- SonarLint
- Code Spell Checker