Wow, after all this time still no answers? Isn't anyone here using NodeJS at all? 😂
Well, let me quickly answer your questions!
How can I set up a Node.js project?
While there is an in-depth Hashnode Original about this topic, here is a tl;dr:
$ mkdir my-app && cd my-app Create a new folder for your project
$ npm initAccording to the docs and answer all questions in the CLI
$ mkdir src For apps, you usually want to create a /src folder for all the code and other folders for things like assets, bundler configs, docs, etc.
$ nano package.json Edit the package file, so that the field main points to the index file inside the src folder. Also add a build or start script, depending on whether you build a library or application
$ cd src && touch index.js Create the index file, which is the starting point for your application or package
Get coding with your favorite editor or IDE!
$ npm start to run your application, or $ npm build to build your library
I am concerned about the directory structure
I recommend using sub-directories whenever you want to split up a big module (big file). Each sub-directory should use the same filename as entry-file, for example index.js, so that the import is easy. For example:
CD may stand for "Continuous Delivery", which means that you develop your software in a way which allows quick releases anytime. It may also stand for "Continuous Deployment", which means that you automatically deploy software frequently, which was developed in a continuous delivery manner.
CI is "Continuous Integration. It means that all developers work on their topics and merge their progress in short time intervals (for example several times a day) in order to spot problems early.
Usually, both, CD and CI, are used in conjunction with each other, so that developers work on small tasks, push them to a main branch in a repo (CD), where a CI pipeline automatically starts tests and if all of the tests succeed publish a new version. As far as I know, Hashnode uses such a process for this very website, in order to quickly fix bugs and issues.
There may be an additional step in the CI pipeline, where the new version first is published on a consolidation system, so that QA can do manual tests and reviews before possible problems, which are not covered by tests, go public. They may then merge all changes into a release branch, which continues the CI pipeline.
Kindly explain the usages of Redis.
Redis is a key-value database. It is simple and fast, and usually not persistent. These attributes make it an ideal solution for a cache, which can persist a reboot of the server application (for example because of a CI process publishing the latest server version), or support horizontal scaling (meaning you add more and more server applications, which need one common cache).
Marco Alka
Software Engineer, Technical Consultant & Mentor
Wow, after all this time still no answers? Isn't anyone here using NodeJS at all? 😂
Well, let me quickly answer your questions!
While there is an in-depth Hashnode Original about this topic, here is a tl;dr:
$ mkdir my-app && cd my-appCreate a new folder for your project$ npm initAccording to the docs and answer all questions in the CLI$ mkdir srcFor apps, you usually want to create a/srcfolder for all the code and other folders for things like assets, bundler configs, docs, etc.$ nano package.jsonEdit the package file, so that the fieldmainpoints to the index file inside the src folder. Also add a build or start script, depending on whether you build a library or application{ "name": "example", "version": "0.1.0", "description": "Example", "main": "src/index.js", "scripts": { "start": "node src/index.js" }, "keywords": [ "test" ], "author": "Marco Alka", "license": "ISC" }$ cd src && touch index.jsCreate the index file, which is the starting point for your application or package$ npm startto run your application, or$ npm buildto build your libraryI recommend using sub-directories whenever you want to split up a big module (big file). Each sub-directory should use the same filename as entry-file, for example
index.js, so that the import is easy. For example:/app-root/ ┠ docs/ ┃ ┗ docs.md ┠ img/ ┃ ┠ hello.jpg ┃ ┠ logo.jpg ┃ ┗ profile.jpg ┠ src/ ┃ ┠ big-feature/ ┃ ┃ ┠ func1.js ┃ ┃ ┠ func2.js ┃ ┃ ┠ index.js ┃ ┠ low-level/ ┃ ┃ ┠ index.js ┃ ┃ ┠ network.js ┃ ┃ ┠ shell.js ┃ ┠ index.js ┃ ┗ server.jsDid so here:
CD may stand for "Continuous Delivery", which means that you develop your software in a way which allows quick releases anytime. It may also stand for "Continuous Deployment", which means that you automatically deploy software frequently, which was developed in a continuous delivery manner.
CI is "Continuous Integration. It means that all developers work on their topics and merge their progress in short time intervals (for example several times a day) in order to spot problems early.
Usually, both, CD and CI, are used in conjunction with each other, so that developers work on small tasks, push them to a main branch in a repo (CD), where a CI pipeline automatically starts tests and if all of the tests succeed publish a new version. As far as I know, Hashnode uses such a process for this very website, in order to quickly fix bugs and issues.
There may be an additional step in the CI pipeline, where the new version first is published on a consolidation system, so that QA can do manual tests and reviews before possible problems, which are not covered by tests, go public. They may then merge all changes into a release branch, which continues the CI pipeline.
Redis is a key-value database. It is simple and fast, and usually not persistent. These attributes make it an ideal solution for a cache, which can persist a reboot of the server application (for example because of a CI process publishing the latest server version), or support horizontal scaling (meaning you add more and more server applications, which need one common cache).