![\"1\"](\"//images.ctfassets.net/xmu5vdhtphau/2dYMwtqTUEhanvPiFRDrvF/c3feab36eb6d19e4b95e150ee7fdfc0b/1.png\")
tl;dr — This is the third article of the Node is Simple article series. In this article series, I will be discussing how to create a simple and secure NodeJS, Express, MongoDB web application.
\nTo follow the past tutorials, Node is Simple Part 1, and Node is Simple Part 2.
\nHello, fellow developers, I am once again, asking you to learn some NodeJS with me. In this tutorial, I will be discussing creating basic CRUD operations in NodeJS. So without further ado, let’s start, shall we?
\nIf you can remember in my previous article, I have created a simple endpoint to POST a name and city of a student and created a record (document) of the student. What I am going to do is enhance what I’ve already done. Let’s update the model, and the service to reflect our needs.
\nWe are going to add some new fields to the student document.
\nconst mongoose = require(\"../database\");\nconst Schema = mongoose.Schema;\n\nconst studentSchema = new Schema(\n {\n _id: {\n type: mongoose.SchemaTypes.String,\n unique: true,\n required: true,\n index: true\n },\n name: { type: mongoose.SchemaTypes.String, required: true },\n city: { type: mongoose.SchemaTypes.String, required: true },\n telephone: { type: mongoose.SchemaTypes.Number, required: true },\n birthday: { type: mongoose.SchemaTypes.Date, required: true }\n },\n { strict: true, timestamps: true, _id: false }\n);\n\nconst collectionName = \"student\";\n\nconst Student = mongoose.model(collectionName, studentSchema, collectionName);\n\nmodule.exports = {\n Student\n};\nWhat I’ve done here is added \\id, telephone,_ and birthday as the new fields. And I have disabled the Mongoose default \\id_ and specified my own.
\nNow let’s update the service file.
\nconst { Student } = require(\"../models\");\n\nmodule.exports = class StudentService {\n async registerStudent(data) {\n const { _id, name, city, telephone, birthday } = data;\n\n const new_student = new Student({\n _id,\n name,\n city,\n telephone,\n birthday\n });\n\n const response = await new_student.save();\n const res = response.toJSON();\n delete res.__v;\n return res;\n }\n};\nBefore we are going to test what we have done, I am going to let you in on a super-secret. If you have experience in developing NodeJS applications, I hope you have come across the Nodemon tool. It restarts the server once you changed the files. But today I am going to tell you about this amazing tool called PM2.
\nPM2 is a production-grade process management tool. It has various capabilities such as load balancing (which I will discuss in a later tutorial), enhanced logging features, adding environment variables, and many more. Their documentation is super nifty and worth checking out.
\nSo let’s install PM2 and start using it in our web app.
\n$ npm install pm2@latest -g\nLet’s create ecosystem.config.js file in the project root, which will contain all of our environment variables, keys, secrets, and PM2 configurations.
\nconst fs = require(\"fs\");\n\nconst SERVER_CERT = fs.readFileSync(__dirname + \"/config/server.cert\", \"utf8\");\nconst SERVER_KEY = fs.readFileSync(__dirname + \"/config/server.key\", \"utf8\");\n\nmodule.exports = {\n apps: [\n {\n name: \"node-is-simple\",\n script: \"./index.js\",\n watch: true,\n env: {\n NODE_ENV: \"development\",\n SERVER_CERT,\n SERVER_KEY,\n HTTP_PORT: 8080,\n HTTPS_PORT: 8081,\n MONGO_URI: \"mongodb://localhost/students\"\n }\n }\n ]\n};\nSince we have moved all of our keys as the environment variables, now we have to change /config/index.js file to reflect these changes.
\nmodule.exports = {\n SERVER_CERT: process.env.SERVER_CERT,\n SERVER_KEY: process.env.SERVER_KEY,\n HTTP_PORT: process.env.HTTP_PORT,\n HTTPS_PORT: process.env.HTTPS_PORT,\n MONGO_URI: process.env.MONGO_URI\n};\nNow, remember, /config/index.js is safe to commit to a public repository. But not the ecosystem.config.js file. Also never commit your private keys to a public repository (But I’ve done it for the demonstration purposes). Protect your secrets like your cash 😂.
\nSince we have done our initial setup let’s run our application. And one thing to keep in mind. If you start the application, as usual,
\n$ node index.js\nit won’t work. Now we have to use PM2 to start our application because it contains all the environment variables needed for the Node web application. Now go to the project root folder and run the following command.
\n$ pm2 start\n
If you see this (figure 1) in your console it is working as it should. Now to see the logs run the following command.
\n$ pm2 logs\n![\"2\"](\"//images.ctfassets.net/xmu5vdhtphau/5550cNdtrp8croBKu9xRQy/6b37778d92facccf4b73c52f0877e571/2.png\")
If you see this (figure 2) in your console then the node app is working as it should.
\nYes, let’s move to test our enhanced CREATE endpoint.
\n![\"3\"](\"//images.ctfassets.net/xmu5vdhtphau/5xaxjOeH89dfwvATgk5z4E/17167a02aa03f7720c88c883ed74e6de/3.png\")
Now create a request like this (figure 3) and hit Send.
\n![\"4\"](\"//images.ctfassets.net/xmu5vdhtphau/2GCkcYOXS4gP5SpEWmavuh/f463273ae5546aff8581e7671a2657b8/4.png\")
If you see this response (figure 4), it is safe to say everything works as it should. Yay!
\nNow since we have a CREATE endpoint, let’s add a READ endpoint.
\nNow let’s read what’s inside our student collection. We can view all the students who are registered, or we can see details from only one student.
\nGET /students
\nNow let’s get all the students’ details. We only get the \\id, name,_ and city of the student here. Add these lines to the /controllers/index.js file.
\n/** @route GET /students\n * @desc Get all students\n * @access Public\n */\nrouter.get(\n \"/students\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.getAllStudents();\n res.send(response);\n })\n);\nAnd add these lines (inside the StudentService class) to the /servcies/index.js file.
\n_async_ getAllStudents() { \n _return_ Student.find({}, \"\\_id name city\"); \n}\nLet me give a summary of the above lines. Student.find() is the method to apply queries to the MongoDB. Since we need all the students we pass the empty object as the first argument. As the second argument (which is called a projection) we provide the fields we want to return and the fields we do not want to return. Here I want \\id, name,_ and city. We can use “-field\\name”_ to provide the field we do not want.
\nGET /students/:id
\nNow let’s get all the details from a single student. Now here we are getting all the details of a single student.
\nNow add these lines to the /controllers/index.js file.
\n/** @route GET /students/:id\n * @desc Get a single student\n * @access Public\n */\nrouter.get(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.getStudent(req.params.id);\n res.send(response);\n })\n);\nIn the Express router, we can specify a path parameter via /:param syntax. Now we can access this path parameter via req.params.param. This is basic Express and to get more knowledge on this please refer to the documentation, and it is a great source of good knowledge.
\nNow add these lines to the /servcies/index.js file.
\n_async_ getStudent(\\_id) { \n _return_ Student.findById(\\_id, \"-\\_\\_v -createdAt -updatedAt\"); \n}\nHere we provide the \\id_ of the student to get the details. As the projection, we do not want \\_v, createdAt,_ and updatedAt fields.
\nNow let’s check these endpoints.
\n![\"5\"](\"//images.ctfassets.net/xmu5vdhtphau/Jyk58isjAqmuywwLoUlLg/6162552a6d18bd48975c28ca1c013fd4/5.png\")
![\"6\"](\"//images.ctfassets.net/xmu5vdhtphau/3gJtTxSNhH0BgqAfg6k9CB/8aa7411bdfaafe2f032305d76378ab85/6.png\")
I have added two more students’ details, so I got three records.
\nNow let’s check the single student endpoint.
\n![\"7\"](\"//images.ctfassets.net/xmu5vdhtphau/3afY8PPNez6lHxv74BA6aG/43d5332068c4d61cb8fca9fd7148fa5c/7.png\")
![\"8\"](\"//images.ctfassets.net/xmu5vdhtphau/5oIO1gQYP7Ljo0XigUpuTP/c132236e231e5f6121bf2cc35ca6ac85/8.png\")
If you get similar results in figure 6 and figure 8 let’s say it was a success.
\nSince we created student records, viewed these student records, now it is time to update these student records.
\nTo PUT, or to PATCH?
\nSo this is the biggest question, to update a resource, should we use PUT or PATCH? The answer is somewhat simple. If you want to update the whole resource every time, use PUT. If you want to update the resource partially, use PATCH. It is that simple. This article clarified this dilemma.
\nDifferences between PUT and PATCH
\nSince I am going to partially update the student record, I will be using PATCH.
\nPATCH /students/:id
\nNow let’s update the /controllers/index.js file.
\n/** @route PATCH /students/:id\n * @desc Update a single student\n * @access Public\n */\nrouter.patch(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.updateStudent(\n req.params.id,\n req.body\n );\n res.send(response);\n })\n);\nAfter adding this let’s update the /services/index.js file.
\n_async_ updateStudent(\\_id, { name, city, telephone, birthday }) { \n _return_ Student.findOneAndUpdate( \n { \\_id }, \n { \n name, \n city, \n telephone, \n birthday \n }, \n { \n _new_: _true_, \n omitUndefined: _true_, \n fields: \"-\\_\\_v -createdAt -updatedAt\" \n } \n ); \n}\nLet me give a brief description of what’s going on here. We update the student by the given id, and we provide the name, city, telephone, and birthday data to be updated. As the third argument we provide new: true to return the updated document to us, omitUndefined: true to partially update the resource and fields: “-\\_v -createdAt -updatedAt”_ to remove these fields from the returning document.
\nNow let’s check this out.
\n![\"9\"](\"//images.ctfassets.net/xmu5vdhtphau/6loAbeATuw2yemdNDaFsVj/3cb60b51c4b05407c28457b6bb2a745a/9.png\")
![\"10\"](\"//images.ctfassets.net/xmu5vdhtphau/3XVaKIJh9CaiaTEsvx9mLQ/0acdb54e1422b92fc2ec71bae0c081f8/10.png\")
So if you get similar results as figure 10 then let’s say yay! Now let’s move on to the final part of this tutorial, which is DELETE.
\nSince we create, read, and update, now it is time to delete some students 😁.
\nDELETE /students/:id
\nSince we should not delete all the students at once (It is a best practice IMO), let’s delete student by the provided student_id.
\nNow let’s update the /controllers/index.js file.
\n/** @route DELETE /students/:id\n * @desc Delete a single student\n * @access Public\n */\nrouter.delete(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.deleteStudent(req.params.id);\n res.send(response);\n })\n);\nNow let’s update the /services/index.js file.
\n_async_ deleteStudent(\\_id) { \n _await_ Student.deleteOne({ \\_id }); \n _return_ { message: \\`Student \\[${\\_id}\\] deleted successfully\\` }; \n}\nNow the time to see this in action.
\n![\"11\"](\"//images.ctfassets.net/xmu5vdhtphau/51lF4tszuB1GSkvJuOiszw/b77e1d78af7674ec28f747a32d5a5f33/11.png\")
![\"12\"](\"//images.ctfassets.net/xmu5vdhtphau/2GDAjO0sLtucU0Juii1wxL/79583b63a0c0d1b4c1a856af148e0f58/12.png\")
If the results are similar to figure 12, then it is safe to assume, the application works as it should.
\nSo here are the current /controllers/index.js file and /services/index.js file for your reference.
\nconst router = require(\"express\").Router();\nconst asyncWrapper = require(\"../utilities/async-wrapper\");\nconst StudentService = require(\"../services\");\nconst studentService = new StudentService();\n\n/** @route GET /\n * @desc Root endpoint\n * @access Public\n */\nrouter.get(\n \"/\",\n asyncWrapper(async (req, res) => {\n res.send({\n message: \"Hello World!\",\n status: 200\n });\n })\n);\n\n/** @route POST /register\n * @desc Register a student\n * @access Public\n */\nrouter.post(\n \"/register\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.registerStudent(req.body);\n res.send(response);\n })\n);\n\n/** @route GET /students\n * @desc Get all students\n * @access Public\n */\nrouter.get(\n \"/students\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.getAllStudents();\n res.send(response);\n })\n);\n\n/** @route GET /students/:id\n * @desc Get a single student\n * @access Public\n */\nrouter.get(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.getStudent(req.params.id);\n res.send(response);\n })\n);\n\n/** @route PATCH /students/:id\n * @desc Update a single student\n * @access Public\n */\nrouter.patch(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.updateStudent(\n req.params.id,\n req.body\n );\n res.send(response);\n })\n);\n\n/** @route DELETE /students/:id\n * @desc Delete a single student\n * @access Public\n */\nrouter.delete(\n \"/students/:id\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.deleteStudent(req.params.id);\n res.send(response);\n })\n);\n\nmodule.exports = router;\nconst { Student } = require(\"../models\");\n\nmodule.exports = class StudentService {\n async registerStudent(data) {\n const { _id, name, city, telephone, birthday } = data;\n\n const new_student = new Student({\n _id,\n name,\n city,\n telephone,\n birthday\n });\n\n const response = await new_student.save();\n const res = response.toJSON();\n delete res.__v;\n return res;\n }\n\n async getAllStudents() {\n return Student.find({}, \"_id name city\");\n }\n\n async getStudent(_id) {\n return Student.findById(_id, \"-__v -createdAt -updatedAt\");\n }\n\n async updateStudent(_id, { name, city, telephone, birthday }) {\n return Student.findOneAndUpdate(\n { _id },\n {\n name,\n city,\n telephone,\n birthday\n },\n {\n new: true,\n omitUndefined: true,\n fields: \"-__v -createdAt -updatedAt\"\n }\n );\n }\n\n async deleteStudent(_id) {\n await Student.deleteOne({ _id });\n return { message: `Student [${_id}] deleted successfully` };\n }\n};\nSo this is it for this tutorial, and we will meet again in a future tutorial about uploading files to MongoDB using GridFS. As usual, you can find the code here (Check for the commit message “Tutorial 3 checkpoint”).
\n\nSo until we meet again, happy coding…
"}},"categories":[{"name":"How To","slug":"how-to"},{"name":"Tutorials","slug":"tutorials"}]}},{"node":{"slug":"node-is-simple-part-2","title":"Node Is Simple — Part 2","image":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/H0hK6NW9d5IUfT0boXBBc/b7b2052395c92ae841256065a5566286/node_is_simple.png","fileName":"node_is_simple.png"}},"bodyContent":{"childMarkdownRemark":{"html":"tl;dr — This is the second article of the Node is Simple article series. In this article series, I will be discussing how to create a simple and secure NodeJS, Express, MongoDB web application.
\nHello, my friends, this is part two of Node is Simple article series, where I will be discussing how to add MongoDB to your web application. If you haven’t read my first article you can read it from here: Node is Simple - Part 1
\nIf you haven’t heard of MongoDB that is news to me. It is the most popular database for modern web applications. (Yeah, yeah, Firebase, Firestore are there too.) MongoDB is a NoSQL database where it has documents as the atomic data structure and a collection of documents is a Collection. With these documents and collections, we can store data as we want.
\n{ \n \"\\_id\": \"5cf0029caff5056591b0ce7d\", \n \"firstname\": \"Jane\", \n \"lastname\": \"Wu\", \n \"address\": { \n \"street\": \"1 Circle Rd\", \n \"city\": \"Los Angeles\", \n \"state\": \"CA\", \n \"zip\": \"90404\" \n }, \n \"hobbies\": \\[\"surfing\", \"coding\"\\] \n}\nThis is how a simple document is constructed in MongoDB. For our tutorial, we will use MongoDB Cloud Atlas which is a MongoDB server as a service platform. I am not going to explain how to create an Atlas account and set up a database since it is really easy and the following is a really good reference.
\nGetting Started with MongoDB Atlas: Overview and Tutorial
\nAfter creating the MongoDB account and set up the database obtain the MongoDB URI which looks like this.
\n**_mongodb+srv://your\\_user\\_name:your\\_password@cluster0-v6q0g.mongodb.net/database\\_name_**\nYou can specify the following with the URI.
\nyour\\user_name:_ The username of the MongoDB database
\nyour\\password:_ The password for the MongoDB database
\ndatabase\\name:_ The MongoDB database name
\nNow that you have the MongoDB URI, you can use MongoDB Compass to view the database and create new collections.
\nFirst of all, let me tell you something awesome about linting. To catch errors in your code, before running any tests, it is vital to do linting. In linting, tools like ESLint, look at your code and displays warnings and errors about your code. So let’s set up ESLint in your development environment.
\nThis is a good reference to setting up ESLint in VSCode: Linting and Formatting with ESLint in VS Code
\nFirst, install ESLint in your project path.
\n$ npm install eslint --save-dev\nThere are several ESLint configurations to use. Let’s create .eslintrc.json file in the project root folder and specify the configurations.
\n{\n \"env\": {\n \"browser\": true,\n \"commonjs\": true,\n \"es6\": true,\n \"node\": true\n },\n \"extends\": [\"eslint:recommended\"],\n \"globals\": {\n \"Atomics\": \"readonly\",\n \"SharedArrayBuffer\": \"readonly\"\n },\n \"parserOptions\": {\n \"ecmaVersion\": 2018\n },\n \"rules\": {}\n}\nAfter that go to settings in WebStorm and then select Manual ESLint configuration.
\n![\"1\"](\"//images.ctfassets.net/xmu5vdhtphau/5F4OK4WRvLzo5MSP0KORs1/3e25487a9cd93709f0dc337fc3e1500f/1.png\")
Then click OK and done and dusted.
\nAlright, alright, let’s move on to the real deal. Now we are going to create a Mongoose reference for the MongoDB database and create some models. Mongoose is the Object Document Model for the MongoDB in NodeJS environment. It is really easy to use and the documentation is really good. Let me tell you a super-secret. Read the documentation, always read the documentation. Documentation is your best friend. 🤣
\nSo first let's install the mongoose package inside the project folder.
\n$ npm install mongoose --save\nNow let’s create the database connection file index.js in /database folder.
\nconst mongoose = require(\"mongoose\");\nconst config = require(\"../config\");\nconst dbPath = config.MONGO_URI;\nconst chalk = require(\"chalk\");\n\nmongoose\n .connect(dbPath, {\n useNewUrlParser: true,\n useUnifiedTopology: true,\n useCreateIndex: true,\n useFindAndModify: false\n })\n .then(() => {\n console.log(chalk.yellow(\"[!] Successfully connected to the database\"));\n })\n .catch(err => {\n console.log(chalk.red(err.message));\n });\n\nconst db = mongoose.connection;\n\ndb.on(\"error\", () => {\n console.log(chalk.red(\"[-] Error occurred from the database\"));\n});\n\ndb.once(\"open\", () => {\n console.log(\n chalk.yellow(\"[!] Successfully opened connection to the database\")\n );\n});\n\nmodule.exports = mongoose;\nNow let’s update the /config/index.js file.
\nconst fs = require(\"fs\");\n\nconst SERVER_CERT = fs.readFileSync(__dirname + \"/server.cert\", \"utf8\");\nconst SERVER_KEY = fs.readFileSync(__dirname + \"/server.key\", \"utf8\");\n\nmodule.exports = {\n SERVER_CERT,\n SERVER_KEY,\n HTTP_PORT: 8080,\n HTTPS_PORT: 8081,\n MONGO_URI:\n \"mongodb+srv://your_user_name:your_password@cluster0-v6q0g.mongodb.net/students\"\n};\nRemember to change the MONGO_URI according to the one you obtained from MongoDB Cloud Atlas instance.
\nNow let’s create a simple mongoose model. Create index.js inside /models folder.
\nconst mongoose = require(\"../database\");\nconst Schema = mongoose.Schema;\n\nconst studentSchema = new Schema(\n {\n name: { type: mongoose.SchemaTypes.String },\n city: { type: mongoose.SchemaTypes.String }\n },\n { strict: true, timestamps: true }\n);\n\nconst collectionName = \"student\";\n\nconst Student = mongoose.model(collectionName, studentSchema, collectionName);\n\nmodule.exports = {\n Student\n};\nAs simple as that. Now let’s create a simple service to create a student using the endpoint. Create index.js file inside /services folder.
\nconst { Student } = require(\"../models\");\n\nmodule.exports = class StudentService {\n async registerStudent(data) {\n const { name, city } = data;\n\n const new_student = new Student({\n name,\n city\n });\n\n const response = await new_student.save();\n const res = response.toJSON();\n delete res.__v;\n return res;\n }\n};\nSimple right? Now let’s use this service inside a controller. Remember our controller, we created in the first article. Let’s update it.
\nconst router = require(\"express\").Router();\nconst asyncWrapper = require(\"../utilities/async-wrapper\");\nconst StudentService = require(\"../services\");\nconst studentService = new StudentService();\n\n/** @route GET /\n * @desc Root endpoint\n * @access Public\n */\nrouter.get(\n \"/\",\n asyncWrapper(async (req, res) => {\n res.send({\n message: \"Hello World!\",\n status: 200\n });\n })\n);\n\n/** @route POST /register\n * @desc Register a student\n * @access Public\n */\nrouter.post(\n \"/register\",\n asyncWrapper(async (req, res) => {\n const response = await studentService.registerStudent(req.body);\n res.send(response);\n })\n);\n\nmodule.exports = router;\nIt’s not over yet. If you run this application as of now and send a POST request to the /register endpoint, it would just return a big error message. It is because our application still doesn’t know how to parse a JSON payload. It would just complain that req.body is undefined. So let’s teach how to parse a JSON payload to our web application. It is not much but it’s honest work. We have to use a simple Express middleware called Body-Parser for this situation. Now let’s set up this.
\nFirst, install the following packages inside the project folder.
\n$ npm install body-parser helmet --save\nCreate the file common.js inside /middleware folder.
\nconst bodyParser = require(\"body-parser\");\nconst helmet = require(\"helmet\");\n\nmodule.exports = app => {\n app.use(bodyParser.json());\n app.use(helmet());\n};\nBody-Parser is the middleware which parses the body payload. And Helmet is there to secure your web application by setting various security HTTP headers.
\nAfter that let’s export our middleware as a combined middleware. Now if we want to add new middleware all we have to do is update the common.js file. Create index.js file inside /middleware folder.
\nconst CommonMiddleware = require(\"./common\");\n\nconst Middleware = app => {\n CommonMiddleware(app);\n};\n\nmodule.exports = Middleware;\nWe are not done yet. Now we have to include this main middleware file inside the index.js root file. Remember we created the index.js file inside the project root folder. Let’s update it.
\nconst express = require(\"express\");\nconst chalk = require(\"chalk\");\nconst http = require(\"http\");\nconst https = require(\"https\");\nconst config = require(\"./config\");\n\nconst HTTP_PORT = config.HTTP_PORT;\nconst HTTPS_PORT = config.HTTPS_PORT;\nconst SERVER_CERT = config.SERVER_CERT;\nconst SERVER_KEY = config.SERVER_KEY;\n\nconst app = express();\nconst Middleware = require(\"./middleware\");\nconst MainController = require(\"./controllers\");\n\nMiddleware(app);\napp.use(\"\", MainController);\napp.set(\"port\", HTTPS_PORT);\n\n/**\n * Create HTTPS Server\n */\n\nconst server = https.createServer(\n {\n key: SERVER_KEY,\n cert: SERVER_CERT\n },\n app\n);\n\nconst onError = error => {\n if (error.syscall !== \"listen\") {\n throw error;\n }\n\n const bind =\n typeof HTTPS_PORT === \"string\"\n ? \"Pipe \" + HTTPS_PORT\n : \"Port \" + HTTPS_PORT;\n\n switch (error.code) {\n case \"EACCES\":\n console.error(chalk.red(`[-] ${bind} requires elevated privileges`));\n process.exit(1);\n break;\n case \"EADDRINUSE\":\n console.error(chalk.red(`[-] ${bind} is already in use`));\n process.exit(1);\n break;\n default:\n throw error;\n }\n};\n\nconst onListening = () => {\n const addr = server.address();\n const bind = typeof addr === \"string\" ? `pipe ${addr}` : `port ${addr.port}`;\n console.log(chalk.yellow(`[!] Listening on HTTPS ${bind}`));\n};\n\nserver.listen(HTTPS_PORT);\nserver.on(\"error\", onError);\nserver.on(\"listening\", onListening);\n\n/**\n * Create HTTP Server (HTTP requests will be 301 redirected to HTTPS)\n */\nhttp\n .createServer((req, res) => {\n res.writeHead(301, {\n Location:\n \"https://\" +\n req.headers[\"host\"].replace(\n HTTP_PORT.toString(),\n HTTPS_PORT.toString()\n ) +\n req.url\n });\n res.end();\n })\n .listen(HTTP_PORT)\n .on(\"error\", onError)\n .on(\"listening\", () =>\n console.log(chalk.yellow(`[!] Listening on HTTP port ${HTTP_PORT}`))\n );\n\nmodule.exports = app;\nWell done people, now we have completed setting up MongoDB connection and the model. So how do we test this? It is so simple, we just have to use a super easy tool called Postman.
\nI hope you all know what Postman does. (Not the one that delivers letters ofc.) Install Postman and fire it up.
\n![\"2\"](\"//images.ctfassets.net/xmu5vdhtphau/ZGIz9cvXhxHGF1WtHq4LJ/63d6a71a9b3a2ec89f72e3f1c18a9af1/2.jpeg\")
![\"2\"](\"//images.ctfassets.net/xmu5vdhtphau/7zNST0cSgnmnwVk4Jn6Man/a9e0f9ddae9a43383613c8118a6b9398/2.jpeg\")
As in figure 1, change the settings for SSL certificate validation. And set it to off. Since we only have a self-signed SSL certificate. (Remember tutorial one.) After that, we are ready to go.
\n![\"3\"](\"//images.ctfassets.net/xmu5vdhtphau/2CgEc5YjKwYItNch6N3Wmo/32e7d00851dba90eb11fa609cdcd6ef5/3.png\")
As in figure 2, create your JSON body request. Add your name and city. Then click Send.
\n![\"4\"](\"//images.ctfassets.net/xmu5vdhtphau/7wa5ISuyFy6NzFWWnfaoBV/f088c7699a69aca595464143fb629f57/4.png\")
If everything goes as it should, you’ll see this response. If you see this response, voila, everything works correctly. Now let’s take a look at MongoDB Compass.
\n![\"5\"](\"//images.ctfassets.net/xmu5vdhtphau/6JQEbHhxzEzr5l06wDPPdp/8f3e7f731a6f8b8ec212f9763c3ac1a1/5.png\")
As in figure 3, you'll see how it shows in the database. Here, the MongoDB database is “students” and the collection is “student” and the document is the one that is showed in the view.
\nNow that was easy right? So that’s it for this tutorial. In the coming tutorial, I’ll add some more CRUD operations to give you more details on working with MongoDB. All the code is saved in the GitHub repo and matched with the commit message. Look for the commit message “Tutorial 2 checkpoint”.
\n\nUntil we meet again, happy coding…
"}},"categories":[{"name":"How To","slug":"how-to"},{"name":"Tutorials","slug":"tutorials"}]}},{"node":{"slug":"new-node-js-14-features-will-see-it-disrupt-ai-iot-and-more-node-latest","title":"New Node.js 14 features will see it disrupt AI, IoT and more, Node latest version report","image":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/5xhMzxcERft4xDTeCMugR0/dabf4e6950a3143996589c55c1437b0d/nodejs-14-features___1_.jpg","fileName":"nodejs-14-features_ (1).jpg"}},"bodyContent":{"childMarkdownRemark":{"html":"New or latest Node.js features aren’t the usual selling point of this platform. Node.js is primarily well-known for its speed and simplicity. This is why so many companies are willing to give it a shot. However, with the release of a new LTS (long-term support) Node.js 14 version, Node.js will gain a lot of new features every Node.js developer can be excited about. Why? That’s because the new Node.js features added in the version 12 through 14 and the possibilities they create are simply that amazing! Find our more from this Node latest version report.
\nThis article has been updated to reflect the latest changes added in Node.js 14. What you can find here is a thorough overview of the latest Node.js features added in version 12 through 14.
\nWeb Assembly is slowly gaining in popularity. More and more Node modules are experimenting with this language and so is Node itself! With the upcoming Node 14 release, we will gain access to the experimental Web Assembly System Interface – WASI.
\nThe main idea behind this is to provide us with an easier way to access the underlying operating system. I’m really looking forward to seeing more Web Assembly in Node.
\nI did mention that the new Node comes with the V8. This gives us not only access to the private field, but also some performance optimizations.
\nAwaits should work much faster, as should JS parsing.
\nOur apps should load quicker and asyncs should be much easier to debug, because we’re finally getting stack traces for them.
\nWhat’s more, the heap size is getting changed. Until now, it was either 700MB (for 32bit systems) or 1400MB (for 64bit). With new changes, it’s based on the available memory!
\nWith the latest Node version 14, we’re getting access to the newest V8. This means that we’re getting some popular features of the JavaScript engine.
\nIf you’re using TypeScript, you probably try nullish coalescing and optional chaining. Both of those are natively supported by Node 14.
\nWe’re also getting a few updates to Intl. The first one is support for Intl.DisplayNames and the second one is support for calendar and numberingSystem for Intl.DateTimeFormat.
\nIn Node 12, we’ve got a new experimental feature called Diagnostic Reports. By using it, we could easily get a report that contains information about the current system. What’s more, we can generate it not only on demand but also after a certain event.
\nIf you have any production running a Node app, then this is something you should be checking out.
\nWith the last LTS we’ve got access to threads. Of course, it was an experimental feature and required a special flag called –experimental-worker for it to work.
\nWith the upcoming LTS (Node 12) it’s still experimental, but won’t require a flag anymore. We are getting closer to a stable version!
\nLet’s face it, ES modules are currently the way to go in JavaScript development. We are using it in our frontend apps. We are using it on our desktop or even mobile apps. And yet, in case of Node we were stuck with common.js modules.
\nOf course, we could use Babel or Typescript, but since Node.js is a backend technology, the only thing we should care about is a Node version installed on the server. We don’t need to care about multiple different browsers and support for them, so what’s the point of installing a tool that was made precisely with that in mind (Babel/Webpack etc.)?
\nWith Node 10, we could finally play a little with ES modules (current LTS has experimental implementation for modules), but it required us to use special file extension – .mjs (module javascript).
\nWith Node 12, it’s getting a little bit easier to work with. Much like it is with web apps, we get a special property type called that will define if code should be treated like common.js or es module.
\nThe only thing you need to do to treat all your files as a module is to add the property type with the value module to your package.json.
\n{\n \"type\": \"module\"\n}\nFrom now on, if this package.json is the closest to our .js file, it will be treated like a module. No more mjs (we can still use it if we want to)!
\nSo, what if we wanted to use some common.js code?
\nAs long as the closest package.json does not contain a module type property, it will be treated like common.js code.
\nWhat’s more, we are getting new an extension called cjs – a common.js file.
\nEvery mjs file is treated as a module and every cjs as a common.js file.
\nIf you didn’t have a chance to try it out, now is the time!
\n\n\nInterested in developing microservices? 🤔 Make sure to check out our State of Microservices 2020 report – based on opinions of 650+ microservice experts!
\n
When it comes to JavaScript, we have always struggled to protect some data in our classes/functions from the outside.
\nJS is famous for its monkey patching, meaning we could always somehow access almost everything.
\nWe tried with closures, symbols and more to simulate private-like variables. Node 12 ships with the new V8 and so we’ve got access to one cool feature – private properties in the class.
\nI’m sure you all remember the old approach to privates in Node:
\nclass MyClass {\n constructor() {\n this._x = 10\n }\n \n get x() {\n return this._x\n }\n}\nWe all know it’s not really a private – we are still able to access it anyway, but most of IDEs treated it like a private field and most of Node devs knew about this convention. Finally, we can all forget about it.
\nclass MyClass {\n #x = 10\n \n get x() {\n return this.#x\n }\n}\nCan you see the difference? Yes, we use # character to tell Node that this variable is private and we want it to be accessible only from the inside of this class.
\nTry to access it directly, you’ll get an error that this variable does not exists.
\nSadly some IDE do not recognize them as proper variables yet.
\nWith Node 12, we’re getting access to new JavaScript features.
\nFirst of all, we’re getting access to new array methods – flat and flatMap. The first one is similar to Lodash’s flattenDepth method.
\nIf we pass a nested arrays to it, we will get a flatten array as a result.
\n[10, [20, 30], [40, 50, [60, 70]]].flat() // => [10, 20, 30, 40, 50, [60, 70]]\n[10, [20, 30], [40, 50, [60, 70]]].flat(2) // => [10, 20, 30, 40, 50, 60, 70]\nAs you can see, it also has a special parameter – depth. By using it, you can decide how many levels down you want to flatten.
\nThe second one – flatMap – works just like map, followed by flat 🙂
\nAnother new feature is optional catch binding. Until now we always had to define an error variable for try – catch.
\ntry {\n someMethod()\n} catch(err) {\n // err is required\n}\nWith Node 12 we can’t skip the entire catch clause, but we can skip the variable at least.
\ntry {\n someMethod()\n} catch {\n // err is optional\n}\nAnother new JavaScript feature is the Object.fromEntries method. It’s main usage is to create an object either from Map or from a key/value array.
\nObject.fromEntries(new Map([['key', 'value'], ['otherKey', 'otherValue']]));\n// { key: 'value', otherKey: 'otherValue' }\n\n\nObject.fromEntries([['key', 'value'], ['otherKey', 'otherValue']]);\n// { key: 'value', otherKey: 'otherValue' }\nIf there is one thing we can all agree on, it’s that every programming language has its pros and cons. Most popular technologies have found their own niche in the world of technology. Node.js is no exception.
\nWe’ve been told for years that Node.js is good for API gateways and real-time dashboards (e.g. with websockets). As a matter of fact, its design itself forced us to depend on the microservice architecture to overcome some of its common obstacles.
\nAt the end of the day, we knew that Node.js was simply not meant for time-consuming, CPU-heavy computation or blocking operations due to its single-threaded design. This is the nature of the event loop itself.
\nIf we block the loop with a complex synchronous operation, it won’t be able to do anything until it’s done. That’s the very reason we use async so heavily or move time-consuming logic to a separate microservice.
\nThis workaround may no longer be necessary thanks to new Node.js features that debuted in its 10 version. The tool that will make the difference are worker threads. Finally, Node.js will be able to excel in fields where normally we would use a different language.
\nA good example could be AI, machine learning or big data processing. Previously, all of those required CPU-heavy computation, which left us no choice, but to build another service or pick a better-suited language. No more.
\nThis new Node.js feature is still experimental – it’s not meant to be used in a production environment just yet. Still, we are free to play with it. So where do we start?
\nStarting from Node 12+ we no longer need to use special feature flag –experimental-worker. Workers are on by default!
\nnode index.js
\nNow we can take full advantage of the worker_threads module. Let’s start with a simple HTTP server with two methods:
\n→ GET /hello (returning JSON object with “Hello World” message),
\n→ GET /compute (loading a big JSON file multiple times using a synchronous method).
\nconst express = require('express');\nconst fs = require('fs');\n\nconst app = express();\n\napp.get('/hello', (req, res) => {\n res.json({\n message: 'Hello world!'\n })\n});\n\napp.get('/compute', (req, res) => {\n let json = {};\n for (let i=0;i<100;i++) {\n json = JSON.parse(fs.readFileSync('./big-file.json', 'utf8'));\n }\n\n json.data.sort((a, b) => a.index - b.index);\n\n res.json({\n message: 'done'\n })\n});\n\napp.listen(3000);\nThe results are easy to predict. When GET /compute and /hello are called simultaneously, we have to wait for the compute path to finish before we can get a response from our hello path. The Event loop is blocked until file loading is done.
\nLet’s fix it with threads!
\nconst express = require('express');\nconst fs = require('fs');\nconst { Worker, isMainThread, parentPort, workerData } = require('worker_threads');\n\nif (isMainThread) {\n console.log(\"Spawn http server\");\n\n const app = express();\n\n app.get('/hello', (req, res) => {\n res.json({\n message: 'Hello world!'\n })\n });\n\n app.get('/compute', (req, res) => {\n\n const worker = new Worker(__filename, {workerData: null});\n worker.on('message', (msg) => {\n res.json({\n message: 'done'\n });\n })\n worker.on('error', console.error);\n worker.on('exit', (code) => {\n if(code != 0)\n console.error(new Error(`Worker stopped with exit code ${code}`))\n });\n });\n\n app.listen(3000);\n} else {\n let json = {};\n for (let i=0;i<100;i++) {\n json = JSON.parse(fs.readFileSync('./big-file.json', 'utf8'));\n }\n\n json.data.sort((a, b) => a.index - b.index);\n\n parentPort.postMessage({});\n}\nAs you can see, the syntax is very similar to what we know from Node.js scaling with Cluster. But the interesting part begins here.
\nTry to call both paths at the same time. Noticed something? Indeed, the event loop is no longer blocked so we can call /hello during file loading.
\nNow, this is something we have all been waiting for! All that’s left is to wait for a stable API.
\nThe raw speed of Node.js is one of the reason we choose this technology. Worker threads are the next step to improve it. But is it really enough?
\nNode.js is a C-based technology. Naturally, we use JavaScript as a main programming language. But what if we could use C for more complex computation?
\nNode.js 10 gives us a stable N-API. It’s a standardized API for native modules, making it possible to build modules in C/C++ or even Rust. Sounds cool, doesn’t it?
\n![\"c-logo-267x300\"](\"//images.ctfassets.net/xmu5vdhtphau/7ioxRx9zuGmwxyTbCUl8mE/83c35529356d1b1bf103d5e43cb162ca/c-logo-267x300.png\"){kind=logo}
\nBuilding native Node.js modules in C/C++ has just got way easier
A very simple native module can look like this:
\n#include <napi.h>\n#include <math.h>\n\nnamespace helloworld {\n Napi::Value Method(const Napi::CallbackInfo& info) {\n Napi::Env env = info.Env();\n return Napi::String::New(env, \"hello world\");\n }\n\n Napi::Object Init(Napi::Env env, Napi::Object exports) {\n exports.Set(Napi::String::New(env, \"hello\"),\n Napi::Function::New(env, Method));\n return exports;\n }\n\n NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)\n}\nIf you have a basic knowledge of C++, it’s not too hard to write a custom module. The only thing you need to remember is to convert C++ types to Node.js at the end of your module.
\nNext thing we need is binding:
\n{\n \"targets\": [\n {\n \"target_name\": \"helloworld\",\n \"sources\": [ \"hello-world.cpp\"],\n \"include_dirs\": [\"<!@(node -p \\\"require('node-addon-api').include\\\")\"],\n \"dependencies\": [\"<!(node -p \\\"require('node-addon-api').gyp\\\")\"],\n \"defines\": [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]\n }\n ]\n}\nThis simple configuration allows us to build *.cpp files, so we can later use them in Node.js apps.
\nBefore we can make use of it in our JavaScript code, we have to build it and configure our package.json to look for gypfile (binding file).
\n{\n \"name\": \"n-api-example\",\n \"version\": \"1.0.0\",\n \"description\": \"\",\n \"main\": \"index.js\",\n \"scripts\": {\n \"install\": \"node-gyp rebuild\"\n },\n \"gypfile\": true,\n \"keywords\": [],\n \"author\": \"\",\n \"license\": \"ISC\",\n \"dependencies\": {\n \"node-addon-api\": \"^1.5.0\",\n \"node-gyp\": \"^3.8.0\"\n }\n}\nOnce the module is good to go, we can use the node-gyp rebuild command to build and then require it in our code. Just like any popular module we use!
\nconst addon = require('./build/Release/helloworld.node');\n\nconsole.log(addon.hello());\nTogether with worker threads, N-API gives us a pretty good set of tools to build high-performance apps. Forget APIs or dashboards – even complex data processing or machine learning systems are far from impossible. Awesome!
\nWe’re able to compute faster. We’re able to compute in parallel. So how about assets and pages serving?
\nFor years, we were stuck with the good old http module and HTTP/1.1. As more and more assets are being served by our servers, we increasingly struggle with loading times. Every browser has a maximum number of simultaneous persistent connections per server/proxy, especially for HTTP/1.1. With HTTP/2 support, we can finally kiss this problem goodbye.
\nSo where do we start? Do you remember this basic Node.js server example from every tutorial on web ever? Yep, this one:
\nconst http = require('http');\n\nhttp.createServer(function (req, res) {\n res.write('Hello World!');\n res.end();\n}).listen(3000);\nWith Node.js 10, we get a new http2 module allowing us to use HTTP/2.0! Finally!
\nconst http = require('http2');\nconst fs = require('fs');\n\nconst options = {\n key: fs.readFileSync('example.key'),\n cert: fs.readFileSync('example.crt')\n };\n\nhttp.createSecureServer(options, function (req, res) {\n res.write('Hello World!');\n res.end();\n}).listen(3000);\nFull HTTP/2 support in Node.js 10 is what we have all been waiting for
\nThe new Node.js features bring fresh air to our tech ecosystem. They open up completely new possibilities for Node.js. Have you ever imagined that this technology could one day be used for image processing or data science? Neither have I.
\nNode latest version gives us even more long-awaited features such as support for es modules (still experimental, though) or changes to fs methods, which finally use promises rather than callbacks.
\nWant even more new Node.js features? Watch this short video.
\n\nAs you can see from the chart below, the popularity of Node.js seems to have peaked in early 2017, after years and years of growth. It’s not really a sign of slowdown, but rather of maturation of this technology.
\n![\"node-popularity-over-the-years-chart-1024x425\"](\"//images.ctfassets.net/xmu5vdhtphau/1ewCUNO1n9x3cbpr1t40MH/4a9333a7554affd42bffad3bcaa4b082/node-popularity-over-the-years-chart-1024x425.png\")
\nPopularity of Node.js over time chart, peaked in 2017
However, I can definitely see how all of these new improvements, as well as the growing popularity of Node.js blockchain apps (based on the truffle.js framework), may give Node.js a further boost so that it can blossom again – in new types of projects, roles and circumstances.
\nWith the release of Node.js 14, the future is looking brighter and brighter for Node.js development!
"}},"categories":[{"name":"Tutorials","slug":"tutorials"},{"name":"Node.js","slug":"node-js"}]}},{"node":{"slug":"node-is-simple-part-1","title":"Node is Simple — Part 1","image":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/1wPDiEeSUpjD3lRRdev6UP/fa2b5a348289eb756540991b919747db/1_q4C3LGm0jGTaDtoSco5d1w.jpg","fileName":"1_q4C3LGm0jGTaDtoSco5d1w.jpg"}},"bodyContent":{"childMarkdownRemark":{"html":"tl;dr — This is the first article of the Node is Simple article series. In this article series, I will be discussing how to create a simple and secure NodeJS, Express, MongoDB web application.
\nFirst of all let me give a big shout out to JavaScript, who’s going to turn 25 years old this year. W/O JavaScript, the world would be a much darker place indeed. 😁 In this article series what I am going to do is create an API with NodeJS, ExpressJS, and MongoDB. I know there is a vast ocean of tutorials out there, describing how to build an API with these technologies, but the thing is that I have never found a very comprehensive all in one tutorial where you get the knowledge of the following things.
\nWell if you have done all of these things with your web application, it would be awesome. Since I learned all of these the hard way, I want to share them with all of you. Because sharing is caring 😇.
\nSince this tutorial is a series I won’t be making this a long; boring to read one. In this first article, I will describe how to set up a simple NodeJS and Express app with SSL/TLS. Just that, nothing else.
\n![\"maxresdefault\"](\"//images.ctfassets.net/xmu5vdhtphau/6LsNJMcGwfz5MxaiPSf55W/6515ce3dea77d2caceb7c434e51e4287/maxresdefault.jpg\")
On your feet soldier, we are starting.
\nFirst of all, let’s create the folder structure of our web application.
\n![\"1](\"//images.ctfassets.net/xmu5vdhtphau/X8HViCF0BVbb4gPN1ojt4/909fea9e6991bbde125497f3c92d8016/1_jnP_vv30BKCx84yOSHbTRQ.png\")
As shown in figure 1, you need to create the folders and the index.js file. If you use Linux or, Git Bash on Windows, let’s make a simple script to do this. So you won’t have to do this again when you need to create another application. (We are so lazy aren’t we? 😂)
\n#!/usr/bin/env bash\n\n############################################################\n# Remember to create a folder for your project first #\n# And run `npm init` to initialize a node project #\n# Inside that project folder run this bootstrap.sh script #\n############################################################\n\n# Create the folders\nmkdir config controllers errors middleware models services swagger utilities database\n\n# Create the index.js file\ntouch index.js\n\n############################################################\n# Remember to check if you have node and npm installed #\n# I assume you have installed node and npm #\n############################################################\n\n# Install required packages\nnpm install express chalk --save\n\n#That's it folks!\nLet’s go through it again.
\nFirst, you need to create a folder for your project and run npm init and initialize your application. With this, you can specify a great name to your project, your license of preference, and many more. Ah, I just forgot. You need to check if you have the current version of Node and NPM installed in your machine. I hope you know how to install NodeJS on your computer. If not please refer to the following links.
\nHow to Download & Install Node.js - NPM on Windows
\nHow To Install Node.js on Ubuntu 18.04
\nAfter doing that just run this bootstrap.sh bash script inside your project folder and it will create a simple Node, Express application. So simple right?
\nAfter creating the necessary folder structure let’s set up the Express application. Let’s go to the index.js file on the root folder and add these lines.
\nconst express = require(\"express\");\nconst chalk = require(\"chalk\");\nconst http = require(\"http\");\nconst https = require(\"https\");\nconst config = require(\"./config\");\n\nconst HTTP_PORT = config.HTTP_PORT;\nconst HTTPS_PORT = config.HTTPS_PORT;\nconst SERVER_CERT = config.SERVER_CERT;\nconst SERVER_KEY = config.SERVER_KEY;\n\nconst app = express();\nconst MainController = require(\"./controllers\");\n\napp.use(\"\", MainController);\napp.set(\"port\", HTTPS_PORT);\n\n/**\n * Create HTTPS Server\n */\n\nconst server = https.createServer(\n {\n key: SERVER_KEY,\n cert: SERVER_CERT\n },\n app\n);\n\nconst onError = error => {\n if (error.syscall !== \"listen\") {\n throw error;\n }\n\n const bind =\n typeof HTTPS_PORT === \"string\"\n ? \"Pipe \" + HTTPS_PORT\n : \"Port \" + HTTPS_PORT;\n\n switch (error.code) {\n case \"EACCES\":\n console.error(chalk.red(`[-] ${bind} requires elevated privileges`));\n process.exit(1);\n break;\n case \"EADDRINUSE\":\n console.error(chalk.red(`[-] ${bind} is already in use`));\n process.exit(1);\n break;\n default:\n throw error;\n }\n};\n\nconst onListening = () => {\n const addr = server.address();\n const bind = typeof addr === \"string\" ? `pipe ${addr}` : `port ${addr.port}`;\n console.log(chalk.yellow(`[!] Listening on HTTPS ${bind}`));\n};\n\nserver.listen(HTTPS_PORT);\nserver.on(\"error\", onError);\nserver.on(\"listening\", onListening);\n\n/**\n * Create HTTP Server (HTTP requests will be 301 redirected to HTTPS)\n */\nhttp\n .createServer((req, res) => {\n res.writeHead(301, {\n Location:\n \"https://\" +\n req.headers[\"host\"].replace(\n HTTP_PORT.toString(),\n HTTPS_PORT.toString()\n ) +\n req.url\n });\n res.end();\n })\n .listen(HTTP_PORT)\n .on(\"error\", onError)\n .on(\"listening\", () =>\n console.log(chalk.yellow(`[!] Listening on HTTP port ${HTTP_PORT}`))\n );\n\nmodule.exports = app;\nDon’t run this yet, since we haven’t done anything yet. I know this is a bit too much just bear with me, I’ll explain everything. What we are doing here is, first we create an HTTP server and then we create an HTTPS server. Then we redirect all the HTTP traffic to the HTTPS server. First of all, we need to create certificates to use inside the HTTPS server. It is a little bit of pain, but it’ll worth it. This is a good resource about creating SSL certificates for your Node application.
\nHow to Use SSL/TLS with Node.js
\nI am a little bit of a lazy person so I’ll just generate server.cert and server.key files using this link.
\nSelf-Signed Certificate Generator
\nInside the server name input, you just have to provide your domain name. For this purpose, I’ll use the localhost as the domain name.
\nAfter generating the *.cert and *.key files copy them to the /config folder. And rename them to server.cert and server.key.
\nNow let’s import the certificates and make them useful. Inside the /config folder create the file index.js and add these lines.
\nconst fs = require(\"fs\");\n\nconst SERVER_CERT = fs.readFileSync(__dirname + \"/server.cert\", \"utf8\");\nconst SERVER_KEY = fs.readFileSync(__dirname + \"/server.key\", \"utf8\");\n\nmodule.exports = {\n SERVER_CERT,\n SERVER_KEY,\n HTTP_PORT: 8080,\n HTTPS_PORT: 8081\n};\nNot so simple after all right? Well, let’s see.
\nNow that we have set up the certificates, let’s create a simple controller (endpoint) to our application and check that out. First, let’s got to the /controllers folder and create an index.js file. Inside that add the following lines.
\nconst router = require(\"express\").Router();\nconst asyncWrapper = require(\"../utilities/async-wrapper\");\n\n/** @route GET /\n * @desc Root endpoint\n * @access Public\n */\nrouter.get(\n \"/\",\n asyncWrapper(async (req, res) => {\n res.send({\n message: \"Hello World!\",\n status: 200\n });\n })\n);\n\nmodule.exports = router;\nasyncWrapper what is that???
\nLet me tell you about that. Async Wrapper is a wrapper function that will catch all the errors happen inside your code and returns them to the error handling middleware. I’ll explain this a little more when I am discussing Express middleware. Now let’s create this infamous asyncWrapper. Go to the /utilities folder and create the two following files.
\n**async-wrapper.js**
module.exports = requestHandler => (req, res, next) =>\n requestHandler(req, res).catch(next);\n**async.wrapper.d.ts** (Async wrapper type definition file)
We have done it, folks, we have done it. Now let’s check this beautiful Express app at work. Let’s run the web application first. Let’s go to the project folder and in the terminal (or Git Bash on Windows) run the following line.
\nnode index.js
\nAfter that let’s fire up your favorite browser (mine is Chrome 😁) and hit the endpoint at,
\n\nDon’t worry if your browser says it is not secure to go to this URL. You trust yourself, don’t you? So let’s accept the risk and go ahead.
\n![\"1](\"//images.ctfassets.net/xmu5vdhtphau/6376WfRDmfD2l7nNerhgOE/e67006295d61ab844c1e8531827330de/1_-j7gNIpPkuqIQj_OQf9Y0A.png\")
Now if you can see something like this,
\n![\"1](\"//images.ctfassets.net/xmu5vdhtphau/5fBDIxDCiysuWEzT5A05vb/de95f050a10cc91ab51695f37ea1506c/1_UNQTECXa-hXe2YM4ANG0DQ.png\")
You have successfully created a NodeJS, Express application. Also since we have set up an HTTP server, you can try this URL too. http://localhost:8080
\nIf you go to this URL, you’ll see that you’ll be redirected to https://localhost:8081
\nNow that’s the magic with our Express application. Awesome right? So this is it for this tutorial. In the next tutorial, I’ll tell you all about adding MongoDB as the database.
\nhttps://github.com/Niweera/node-is-simple
\nThis is the GitHub repo for this tutorial and I’ll update this repo as the tutorial grows. Check for the commit messages for the snapshot of the repo for a particular tutorial. If you have any queries, don’t forget to hit me up on any social media as shown on my website.
\n\nSo until we meet again with part two of this tutorial series, happy coding…
"}},"categories":[{"name":"Node.js","slug":"node-js"},{"name":"How To","slug":"how-to"}]}},{"node":{"slug":"running-your-node-js-app-with-systemd-part-1","title":"Running Your Node.js App With Systemd - Part 1","image":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/7hMby0z6l7JP5c9uQWoz0T/b543178d4eff1f68fd23dad178eeee44/5-min.jpg","fileName":"5-min.jpg"}},"bodyContent":{"childMarkdownRemark":{"html":"You've written the next great application, in Node, and you are ready to unleash it upon the world. Which means you can no longer run it on your laptop, you're going to actually have to put it up on some server somewhere and connect it to the real Internet. Eek.
\nThere are a lot of different ways to run an app in production. This post is going to cover the specific case of running something on a \"standard\" Linux server that uses systemd, which means that we are not going to be talking about using Docker, AWS Lambda, Heroku, or any other sort of managed environment. It's just going to be you, your code, and terminal with a ssh session my friend.
Before we get started though, let's talk for just a brief minute about what systemd actually is and why you should care.
systemd Anyway?The full answer to this question is big, as in, \"ginormous\" sized big. So we're not going to try and answer it fully since we want to get on the the part where we can launch our app. What you need to know is that systemd is a thing that runs on \"new-ish\" Linux servers that is responsible for starting / stopping / restarting programs for you. If you install mysql, for example, and whenever you reboot the server you find that mysql is already running for you, that happens because systemd knows to turn mysql on when the machine boots up.
This systemd machinery has replaced older systems such as init and upstart on \"new-ish\" Linux systems. There is a lot of arguably justified angst in the world about exactly how systemd works and how intrusive it is to your system. We're not here to discuss that though. If your system is \"new-ish\", it's using systemd, and that's what we're all going to be working with for the forseeable future.
What does \"new-ish\" mean specifically? If you are using any of the following, you are using systemd:
I'm going to assume you have a fresh installation of Ubuntu Xenial to work with, and that you have set up a default user named ubuntu that has sudo privileges. This is what the default will be if you spin up a Xenial instance in Amazon EC2. I'm using Xenial because it is currently the newest LTS (Long Term Support) version available from Canonical. Ubuntu Yakkety is available now, and is even newer, but Xenial is quite up-to-date at the time of this writing and will be getting security updates for many years to come because of its LTS status.
Use ssh with the ubuntu user to get into your server, and let's install Node.
$ sudo apt-get -y install curl\n$ curl -sL https://deb.nodesource.com/setup_6.x | sudo bash -\n$ sudo apt-get -y install nodejs\nNext let's create an app and run it manually. Here's a trivial app I've written that simply echoes out the user's environment variables.
\nconst http = require('http');\n\nconst hostname = '0.0.0.0';\nconst port = process.env.NODE_PORT || 3000;\nconst env = process.env;\n\nconst server = http.createServer((req, res) => {\n res.statusCode = 200;\n res.setHeader('Content-Type', 'text/plain');\n for (var k in env) {\n res.write(k + \": \" + env[k] + \"\\n\");\n }\n res.end();\n});\n\nserver.listen(port, hostname, () => {\n console.log(\"Server running at http://\" + hostname + \":\" + port + \"/\");\n});\nUsing your text editor of choice (which should obviously be Emacs but I suppose it's a free country if you want to use something inferior), create a file called hello_env.js in the user's home directory /home/ubuntu with the contents above. Next run it with
$ /usr/bin/node /home/ubuntu/hello_env.js\nYou should be able to go to
\nhttp://11.22.33.44:3000\nin a web browser now, substituting 11.22.33.44 with whatever the actual IP address of your server is, and see a printout of the environment variables for the ubuntu user. If that is in fact what you see, great! We know the app runs, and we know the command needed to start it up. Go ahead and press Ctrl-c to close down the application. Now we'll move on to the systemd parts.
systemd Service FileThe \"magic\" that's needed to make systemd start working for us is a text file called a service file. I say \"magic\" because for whatever reason, this seems to be the part that people block on when they are going through this process. Fortunately, it's much less difficult and scary than you might think.
We will be creating a file in a \"system area\" where everything is owned by the root user, so we'll be executing a bunch of commands using sudo. Again, don't be nervous, it's really very straightforward.
The service files for the things that systemd controls all live under the directory path
/lib/systemd/system\nso we'll create a new file there. If you're using Nano as your editor, open up a new file there with:
\nsudo nano /lib/systemd/system/hello_env.service\nand put the following contents in it:
\n[Unit]\nDescription=hello_env.js - making your environment variables rad\nDocumentation=https://example.com\nAfter=network.target\n\n[Service]\nEnvironment=NODE_PORT=3001\nType=simple\nUser=ubuntu\nExecStart=/usr/bin/node /home/ubuntu/hello_env.js\nRestart=on-failure\n\n[Install]\nWantedBy=multi-user.target\nLet's go ahead and talk about what's in that file. In the [Unit] section, the Description and Documentation variables are obvious. What's less obvious is the part that says
After=network.target\nThat tells systemd that if it's supposed to start our app when the machine boots up, it should wait until after the main networking functionality of the server is online to do so. This is what we want, since our app can't bind to NODE_PORT until the network is up and running.
Moving on to the [Service] section we find the meat of today's project. We can specify environment variables here, so I've gone ahead and put in:
Environment=NODE_PORT=3001\nso our app, when it starts, will be listening on port 3001. This is different than the default 3000 that we saw when we launched the app by hand. You can specify the Environment directive multiple times if you need multiple environment variables. Next is
Type=simple\nwhich tells systemd how our app launches itself. Specifically, it lets systemd know that the app won't try and fork itself to drop user privileges or anything like that. It's just going to start up and run. After that we see
User=ubuntu\nwhich tells systemd that our app should be run as the unprivileged ubuntu user. You definitely want to run your apps as unprivileged users to that attackers can't aim at something running as the root user.
The last two parts here are maybe the most interesting to us
\nExecStart=/usr/bin/node /home/ubuntu/hello_env.js\nRestart=on-failure\nFirst, ExecStart tells systemd what command it should run to launch our app. Then, Restart tells systemd under what conditions it should restart the app if it sees that it has died. The on-failure value is likely what you will want. Using this, the app will NOT restart if it goes away \"cleanly\". Going away \"cleanly\" means that it either exits by itself with an exit value of 0, or it gets killed with a \"clean\" signal, such as the default signal sent by the kill command. Basically, if our app goes away because we want it to, then systemd will leave it turned off. However, if it goes away for any other reason (an unhandled exception crashes the app, for example), then systemd will immediately restart it for us. If you want it to restart no matter what, change the value from on-failure to always.
Last is the [Install] stanza. We're going to gloss over this part as it's not very interesting. It tells systemd how to handle things if we want to start our app on boot, and you will probably want to use the values shown for most things until you are a more advanced systemd user.
systemctl To Control Our AppThe hard part is done! We will now learn how to use the system provided tools to control our app. To being with, enter the command
\n$ sudo systemctl daemon-reload\nYou have to do this whenever any of the service files change at all so that systemd picks up the new info.
Next, let's launch our app with
\n$ sudo systemctl start hello_env\nAfter you do this, you should be able to go to
\nhttp://11.22.33.44:3001\nin your web browser and see the output. If it's there, congratulations, you've launched your app using systemd! If the output looks very different than it did when you launched the app manually don't worry, that's normal. When systemd kicks off an application, it does so from a much more minimal environment than the one you have when you ssh into a machine. In particular, the $HOME environment variable may not be set by default, so be sure to pay attention to this if your app makes use of any environment variables. You may need to set them yourself when using systemd.
You may be interested in what state systemd thinks the app is in, and if so, you can find out with
$ sudo systemctl status hello_env\nNow, if you want to stop your app, the command is simply
\n$ sudo systemctl stop hello_env\nand unsurprisingly, the following will restart things for us
\n$ sudo systemctl restart hello_env\nIf you want to make the application start up when the machine boots, you accomplish that by enabling it
\n$ sudo systemtl enable hello_env\nand finally, if you previously enabled the app, but you change your mind and want to stop it from coming up when the machine starts, you correspondingly disable it
\n$ sudo systemctl disable hello_env\nThat concludes today's exercise. There is much, much more to learn and know about systemd, but this should help get you started with some basics. In a follow up blog post, we will learn how to launch multiple instances of our app, and load balance those behind Nginx to illustrate a more production ready example.
This article was first published NodeSource blog post in November 2016
"}},"categories":[{"name":"How To","slug":"how-to"},{"name":"Node.js","slug":"node-js"}]}},{"node":{"slug":"configuring-your-npmrc-for-an-optimal-node-js-environment","title":"Configuring Your .npmrc for an Optimal Node.js Environment","image":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/1DTT5AD0XSonP7LBHxXJdR/d9c15a40f2752a3517f38098476c1398/6-min.jpg","fileName":"6-min.jpg"}},"bodyContent":{"childMarkdownRemark":{"html":"This blog post was first published on March 2017. Find out more here
\nFor Node.js developers, npm is an everyday tool. It's literally something we interact with multiple times on a daily basis, and it's one of the pieces of the ecosystem that's led to the success of Node.js.
One of the most useful, important, and enabling aspects of the npm CLI is that its highly configurable. It provides an enormous amount of configurability that enables everyone from huge enterprises to individual developers to use it effectively.
One part of this high-configurability is the .npmrc file. For a long time I'd seen discussion about it - the most memorable being the time I thought you could change the name of the node_modules directory with it. For a long time, I didn't truly understand just how useful the .npmrc file could be, or how to even use it.
So, today I've collected a few of the optimizations that .npmrc allows that have been awesome for speeding up my personal workflow when scaffolding out Node.js modules and working on applications long-term.
npm init Just a Bit MoreWhen you're creating a new module from scratch, you'll typically start out with the npm init command. One thing that some developers don't know is that you can actually automate this process fairly heftily with a few choice npm config set ... commands that set default values for the npm init prompts.
You can easily set your name, email, URL, license, and initial module version with a few commands:
\nnpm config set init.author.name \"Hiro Protagonist\"\nnpm config set init.author.email \"hiro@showcrash.io\"\nnpm config set init.author.url \"http://hiro.snowcrash.io\"\nnpm config set init.license \"MIT\"\nnpm config set init.version \"0.0.1\"\nIn the above example, I've set up some defaults for Hiro. This personal information won't change too frequently, so setting up some defaults is helpful and allows you to skip over entering the same information in manually every time.
\nAdditionally, the above commands set up two defaults that are related to your module.
\nThe first default is the initial license that will be automatically suggested by the npm init command. I personally like to default to MIT, and much of the rest of the Node.js ecosystem does the same. That said, you can set this to whatever you'd like - it's a nice optimization to just be able to nearly automatically select your license of choice.
The second default is the initial version. This is actually one that made me happy, as whenever I tried building out a module I never wanted it to start out at version 1.0.0, which is what npm init defaults to. I personally set it to 0.0.1 and then increment the version as I go with the npm version [ major | minor | patch ] command.
As time moves forward, we're seeing more options for registries arise. For example, you may want to set your registry to a cache of the modules you know you need for your apps. Or, you may be using Certified Modules as a custom npm registry. There's even a separate registry for Yarn, a topic that is both awesome and totally out of scope for this post.
\nSo, if you'd like to set a custom registry, you can run a pretty simple one-line command:
\nnpm config set registry \"https://my-custom-registry.registry.nodesource.io/\"\nIn this example, I've set the registry URL to an example of a Certified Modules registry - that said, the exact URL in the command can be replaced with any registry that's compatible. To reset your registry back to the default npm registry, you can simply run the same command pointing to the standard registry:
\nnpm config set registry \"https://registry.npmjs.com/\"\nnpm install with loglevelWhen you npm install a bunch of information gets piped to you. By default, the npm command line tool limits how much of this information is actually output into the console when installing. There are varying degrees of output that you can assign at install, or by default, if you change it with npm config in your .npmrc file. The options, from least to most output, are: silent, error, warn, http, info, verbose, and silly.
Here's an example of the silent loglevel:\n![\"npm](\"//images.contentful.com/hspc7zpa5cvq/4W74xwLugw6EoOSISIUwie/0d9f29dd32c4e39de5b98ba46d138a19/npm_install_express_loglevel_silent.gif\")
And here's an example of the silly loglevel:\n![\"npm](\"//images.contentful.com/hspc7zpa5cvq/6p7v2EFSTuSw860Y0EUgeU/449080a2f1bd32910ce2e23358381bca/npm_install_express_loglevel_silly.gif\")
If you'd like to get a bit more information (or a bit less, depending on your preferences) when you npm install, you can change the default loglevel.
npm config set loglevel=\"http\"\nIf you tinker around with this config a bit and would like to reset to what the npm CLI currently defaults to, you can run the above command with warn as the loglevel:
npm config set loglevel=\"warn\"\nThis is a really awesome change - it has a few steps, but is really worth it. With a few commands, you can change where the npm CLI installs global modules by default. Normally, it installs them to a privileged system folder - this requires administrative access, meaning that a global install requires sudo access on UNIX-based systems.
If you change the default global prefix for npm to an unprivileged directory, for example, ~/.global-modules, you'll not need to authenticate when you install a global module. That's one benefit - another is that globally installed modules won't be in a system directory, reducing the likelihood of a malicious module (intentionally or not) doing something you didn't want it to on your system.
To get started, we're going to create a new folder called global-modules and set the npm prefix to it:
mkdir ~/.global-modules\nnpm config set prefix \"~/.global-modules\"\nNext, if you don't already have a file called ~/.profile, create one in your root user directory. Now, add the following line to the ~/.profile file:
export PATH=~/.global-modules/bin:$PATH\nAdding that line to the ~/.profile file will add the global-modules directory to your PATH, and enable you to use it for npm global modules.
Now, flip back over to your terminal and run the following command to update the PATH with the newly updated file:
\nsource ~/.profile\nIf you'd like to keep reading about Node.js, npm, configuration options, and development with the Node.js stack, I've got some fantastic articles for you.
\nOur most recent guide is a deep-dive into the core concepts of the package.json file. You'll find a ton of info about package.json in there, including a ton of super helpful configuration information. We also published an absolute beginner's guide to npm that you may be interested in reading - even though it's a beginner's guide, I'd bet you'll find something useful in it.
With this article, the intent was to help you set up a great configuration for Node.js development. If you'd like to take the leap and ensure that you're always on a rock-solid platform when developing and deploying you Node.js apps, check out NodeSource Certified Modules - it's a new tool we launched last week that will help enable you to spend more time building apps and less time worrying about modules.
\nThis blog post was first published on March 2017. Find out more here
\nUsing npm effectively can be difficult. There are a ton of features built-in, and it can be a daunting task to try to approach learning them.
\nPersonally, even learning and using just one of these tricks (npm prune, which is #4) saved me from getting rid of unused modules manually by deleting node_modules and re-installing everything with npm install. As you can probably imagine, that was insanely stressful.
We've compiled this list of 11 simple-to-use npm tricks that will allow you to speed up development using npm, no matter what project you're working on.
\nRun: npm home $package
Running the home command will open the homepage of the package you're running it against. Running against the lodash package will bring you to the Lodash website. This command can run without needing to have the package installed globally on your machine or within the current project.
Run: npm repo $package
Similar to home, the repo command will open the GitHub repository of the package you're running it against. Running against the express package will bring you to the official Express repo. Also like home, you don’t need to have the package installed.
Run: npm outdated
You can run the outdated command within a project, and it will check the npm registry to see if any of your packages are outdated. It will print out a list in your command line of the current version, the wanted version, and the latest version.
![\"Running](\"https://nodesource.com/media/2016/Aug/Screen_Shot_2016_08_26_at_3_52_53_PM-1472242056432.png\")
Run: npm prune
When you run prune, the npm CLI will run through your package.json and compare it to your project’s /node_modules directory. It will print a list of modules that aren’t in your package.json.
The npm prune command then strips out those packages, and removes any you haven't manually added to package.json or that were npm installed without using the --save flag.
![\"Running](\"https://nodesource.com/media/2016/Aug/Screen_Shot_2016_08_26_at_3_54_00_PM-1472242073013.png\")
Update: Thanks to @EvanHahn for noticing a personal config setting that made npm prune provide a slightly different result than the default npm would provide!
Run: npm shrinkwrap
Using shrinkwrap in your project generates an npm-shrinkwrap.json file. This allows you to pin the dependencies of your project to the specific version you’re currently using within your node_modules directory. When you run npm install and there is a npm-shrinkwrap.json present, it will override the listed dependencies and any semver ranges in package.json.
If you need verified consistency across package.json, npm-shrinkwrap.json and node_modules for your project, you should consider using npm-shrinkwrap.
![\"Running](\"https://nodesource.com/media/2016/Aug/Screen_Shot_2016_08_26_at_3_54_36_PM-1472242098179.png\")
Run: npm install -g npm@3
Installing npm@3 globally with npm will update your npm v2 to npm v3, including on the Node.js v4 LTS release (“Argon”) ships with the npm v2 LTS release. This will install the latest stable release of npm v3 within your v4 LTS runtime.
npm install -g without needing sudoRun: npm config set prefix $dir
After running the command, where $dir is the directory you want npm to install your global modules to, you won’t need to use sudo to install modules globally anymore. The directory you use in the command becomes your global bin directory.
The only caveat: you will need to make sure you adjust your user permissions for that directory with chown -R $USER $dir and you add $dir/bin to your PATH.
Run: npm config set save-prefix=\"~\"
The tilde (~) is more conservative than what npm defaults to, the caret (^), when installing a new package with the --save or --save-dev flags. The tilde pins the dependency to the minor version, allowing patch releases to be installed with npm update. The caret pins the dependency to the major version, allowing minor releases to be installed with npm update.
devDependencies for a production environmentWhen your project is ready for production, make sure you install your packages with the added --production flag. The --production flag installs your dependencies, ignoring your devDependencies. This ensures that your development tooling and packages won’t go into the production environment.
Additionally, you can set your NODE_ENV environment variable to production to ensure that your project’s devDependencies are never installed.
.npmignoreIf you haven't been using .npmignore, it defaults to .gitignore with a few additional sane defaults.
What many don't realize that once you add a .npmignore file to your project the .gitignore rules are (ironically) ignored. The result is you will need to audit the two ignore files in sync to prevent sensitive leaks when publishing.
npm init with defaultsWhen you run npm init in a new project, you’re able to go through and set up your package.json’s details. If you want to set defaults that npm init will always use, you can use the config set command, with some extra arguments:
npm config set init.author.name $name\nnpm config set init.author.email $email\nIf, instead, you want to completely customize your init script, you can point to a self-made default init script by running
\nnpm config set init-module ~/.npm-init.js`\nHere’s a sample script that prompts for private settings and creates a GitHub repo if you want. Make sure you change the default GitHub username (YOUR_GITHUB_USERNAME) as the fallback for the GitHub username environment variable.
var cp = require('child_process');\nvar priv;\n\nvar USER = process.env.GITHUB_USERNAME || 'YOUR_GITHUB_USERNAME';\n\nmodule.exports = {\n\n name: prompt('name', basename || package.name),\n\n version: '0.0.1',\n\n private: prompt('private', 'true', function(val){\n return priv = (typeof val === 'boolean') ? val : !!val.match('true')\n }),\n\n create: prompt('create github repo', 'yes', function(val){\n val = val.indexOf('y') !== -1 ? true : false;\n\n if(val){\n console.log('enter github password:');\n cp.execSync(\"curl -u '\"+USER+\"' https://api.github.com/user/repos -d \" +\n \"'{\\\"name\\\": \\\"\"+basename+\"\\\", \\\"private\\\": \"+ ((priv) ? 'true' : 'false') +\"}' \");\n cp.execSync('git remote add origin '+ 'https://github.com/'+USER+'/' + basename + '.git');\n }\n\n return undefined;\n }),\n\n main: prompt('entry point', 'index.js'),\n\n repository: {\n type: 'git',\n url: 'git://github.com/'+USER+'/' + basename + '.git' },\n\n bugs: { url: 'https://github.com/'+USER'/' + basename + '/issues' },\n\n homepage: \"https://github.com/\"+USER+\"/\" + basename,\n\n keywords: prompt(function (s) { return s.split(/\\s+/) }),\n\n license: 'MIT',\n\n cleanup: function(cb){\n\n cb(null, undefined)\n }\n\n}\nIf you want to learn more about npm, Node.js, JavaScript, Docker, Kubernetes, Electron, and tons more, you should follow @NodeSource on Twitter. We're always around and would love to hear from you!
"}},"categories":[{"name":"Tutorials","slug":"tutorials"},{"name":"Node.js","slug":"node-js"}]}}]},"contentfulHero":{"headLine":"List of useful articles and blog post on Node.js","coverImage":{"file":{"url":"//images.ctfassets.net/xmu5vdhtphau/3tCG630sR3116gwqT52u9C/dadf240e71f8ab06e2492da2e46a561a/blog-min.jpg","fileName":"blog-min.jpg"}}}},"pageContext":{"limit":7,"skip":7,"numPages":5,"currentPage":2,"type":"blog","hero":"hero-blogs","prevPath":"/blogs","nextPath":"/blogs/page/3"}}}