DEV Community: Temiogundeji

How to Build a Blog API using MongoDB Aggregation Pipeline Framework

Temiogundeji — Thu, 12 Oct 2023 09:12:50 +0000

Introduction

Hello, The first article of this series gave you a background knowledge of the MongoDB Aggregation Pipeline, its stages, operations and how it handles relationships.

This article was originally published on my Hashnode Blog of this series gave you a background knowledge of the MongoDB Aggregation Pipeline, its stages, operations and how it handles relationships.

In this article, we will be building a Blog API to demonstrate concepts from the previous post.

Prerequisites

A good understanding of JavaScript
A working knowledge of NodeJS
A working knowledge of MongoDB
A basic knowledge of the Command line

Overview of the Project

What is a Blog?

A blog is an online platform or website where an individual, group, or organization shares informational, educational, or personal content in the form of articles, posts, or entries.

What is an API?

API is an acronym for Application Programming Interface. API is basically a way two or more computers communicate with each other. Also, one of ways two systems can share functionalities without gaining access to the each other's entire codebases. To learn more about API, visit wikipedia.

Project Goal

Our goal is to create an API with specific endpoints that will enable a basic Blog to function effectively. This project is designed to be straightforward, ensuring that anyone who meets the requirements can easily follow through. Nevertheless, we will include features that showcase the main capabilities of the MongoDB Aggregation Pipeline. This will provide you with a deep understanding of its concepts which you can apply to create complex queries in real-life projects.

User stories

Our users are expected to achieve the above goals through the API

Designing the Structure for the Blog API

These are the endpoints we will be building in this tutorial:

Feature	Route	HTTP Methods	Description
Signup	/auth/signup	POST	POST	Register user
Login	/auth/login	POST	Login user
Get all articles	/articles	GET	Get all articles
Post article	/articles	POST	Post a new article
View a specific article	/api/articles/{articleId}	GET	View a specific article
Comment on article	/articles/{articleId}/comments	POST	Comment on an article
View the most recent article	/api/articles/most-recent	GET	Get the most recently published article
Sort article by their post date in descending order	/api/articles?sort=desc	GET	Sort article by the date they are created in descending order
View the most commented article	/api/articles/most-commented	GET	Retrieve the most commented article with its comment count

Let's get started!

Setting up the Project

In the last section, we stated the features and designed our API structure to provide our project with direction and scope. Let's set up our development environment to start building the highlighted features.

Although, I will be building this project in Visual Studio Code, feel free to use any IDE of your choice.

Initializing the project

To open VSCode on your machine, If you already have it installed, open your terminal and type the following command:

code .

Let's create our project directory and initialize npm by typing the following commands:

mkdir aggregation-pipeline-project
cd aggregation-pipeline-project
npm init -y

Next, let's create our index.js and db.js file, which are entry point and database connection file respectively:

touch index.js db.js

Creating files and directories

With the commands entered in the last step, we have created a root directory for the project. A package.json file has been generated for us by npm. Also, we created the entry point (main file) and the database connection file.

To create the subdirectories required in this project, enter the command below in order:

mkdir src
cd src
mkdir config models middlewares controllers routes utils

If you have entered above commands in order, your file structure should look exactly as below:

Now, let's create models for the project's collections:

touch models/article.js models/category.js models/comment.js models/user.js

Installing dependencies

Next, we would install these project dependencies: bcrypt, express, joi, jsonwebtoken, dotenv, pino, and express-pino-logger. Also, a development dependency called nodemon to avoid restarting our server multiple times when changes are made. Let's enter the command below to install these dependencies:

npm install jsonwebtoken dotenv mongoose express bcryptjs pino express-pino-logger
npm install nodemon -D

To configure nodemon, Open package.json file in the root directory file and enter the code below:

 "scripts": {
    "dev": "nodemon index.js",
    "start": "node index.js"
  }

Creating a Nodejs Server

In the previous sections, we have setup your entry point and database connection file. Furthermore, we created subdirectories: controllers, models, middlewares, config, services, utils and routes. Then, we created model files for our collections.

Now, let's open the index.js file in the root directory and enter the code below:

const express = require("express");
const PORT = process.env.PORT || 5000;
const app = express();

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

app.get("/", (req, res) => {
  res.send("Welcome to Blog API")
});

app.all("/*", (req, res, next) => {
  next(new Error("Resource unavailable"));
});

app.listen(PORT, (err) => {
    console.log(err || `Listening on ${PORT}`);
});

module.exports = app;

With the code above, you have setup a basic server for our application.

Now, run the command below to start the server:

npm run dev

You can test endpoints with any REST client of our choice. I'll be using Thunder client throughout this article. It's a lightweight REST API client extension available in Visual Studio Code. You can learn more about it here.

To test the server, simply make a GET request to the endpoint below from the REST client:

http://localhost:5000

This code should return this:

Hurray! Your Nodejs server is now working perfectly as expected. Now, it's time to setup database.

Setting up Database

In the previous section, we have successfully set up our Nodejs server. Now, we will be configuring the database for our project.

To interact with our database locally, we will be using MongoDB Compass. Download and install it on your local machine. If you have installed MongoDB Compass properly, the interface should look like this:

Next, click on "connect" at the top left corner and edit the connection string as shown below:

Next, click the "Connect" button to connect to the new MongoDB deployment.

In the root directory, let's create a .env file to keep the project credentials. Go to your commandline and enter the command below:

touch .env

Now, open the .env file and declare a variable to hold the connection uri

MONGO_URI=mongodb://localhost:27017/blog-db

Now that we have created a new MongoDB deployment and saved the connection string in .env file, we would enter the code below to connect to MongoDB database through mongoose. Then, open db.js and enter this code:

const mongoose = require("mongoose");

const connectDB = async () => {
  try {
    await mongoose.connect(process.env.MONGO_URI, {
      useNewUrlParser: true,
    });
    console.log(`Connection to database successful`);
  } catch (error) {
    console.error(error.message);
    process.exit(1);
  }
};

module.exports = connectDB;

The code above will enable the server to connect to the MongoDB database. Now, let's call the connectDBfunction to connect to the database.

If the connection was successful, the terminal should look like this:

Implementing Features

In this section, we will start implementing our application features. In most applications, users need to register and login to perform other actions in the application. Therefore, we will be implementing the Authentication feature first.

Authentication

We will accept user information and save it in the database. Then, they will be authenticated based on the credentials when logging in.

Let's start by creating the user model:

Open models/user.js and enter the code below:

const mongoose = require("mongoose");
const userSchema = new mongoose.Schema(
  {
    username: { type: String, required: true, unique: true,},
    email: { type: String, required: true, unique: true,},
    password: { type: String, required: true },
  },
  { toJSON: { virtuals: true }, toObject: { virtuals: true }, timestamps: true }
);

const User = mongoose.model("User", userSchema);
module.exports = User;

The code above will instruct MongoDB to create a user collection in our database. Notice above that we added these options:

 { toJSON: { virtuals: true }, toObject: { virtuals: true }, timestamps: true }

The above indicates that when an instance of the MongoDB model was converted to JSON and Javascript Object, the virtual properties should be included. Also, we want MongoDB to add two more fields (createdAt and updatedAt) and manage them.

Signup:

Feature Checklist:

Get user input
Validate user input
Check if user record does not exist in the system already.
Encrypt user password
Save user data in the database.
Return response

Now, let dive right in.

Create a file named auth.js in the controller directory. This file will contain our signup and login controller.

The best practice is to create separate files for each feature controller. Making each file have single responsibility.

In ./src/controllers/auth.js enter the code below:

const bcrypt = require("bcrypt");
const User = require("../models/user");

const signup = async (req, res, next) => {
  try {
    //Validate user input
    if (!req.body.username && !req.body.email && !req.body.password) {
      res.status(400).send("Complete user information required");
    }
    //Check if user is an existing user
    const existingUser = await User.findOne({ email: req.body.email });
    if (existingUser ) {
      res.status(400).send("User acount already exists.");
    }
    // //Hash user password
    const hashedPassword = await bcrypt.hash(req.body.password, 10);
    // //Save user record into the db
    const newUser = await User.create({
      username: req.body.username,
      email: req.body.email,
      password: hashedPassword,
    });
    let newUserObj = newUser.toObject();
    const { password, id, ...rest } = newUserObj;
    //Return response
    return res.send({
      status: "success",
      user: rest
    });
  } catch (e) {
    console.log(e.message)
  }
};

module.exports = { signup };

To be able to test the signup logic, we have to create a route:

Create a new file named auth.js in the routes "./src/routes/auth.js", enter the following code:

const { signup } = require("../controllers/auth");
const router = require("express").Router();

router.post("/auth/signup", signup);

module.exports = router;

Now, let update our index.js file as shown below:

As shown above, we attached our authentication route to our application, making it possible to make request to it through the REST client.

Ensure that your server is running properly

Now, Open your REST client and make a POST request to: http://localhost:5000/blog/api/auth/signup

Also, pass this body to it:

{ "username": "temi", "email": "abc@xyz.com", "password": "abc@xyz" }

It should return this response:

It works! Now let's implement the login feature:

Login

Feature Checklist

Get user input
Validate user input
Check if user has an account in the system
Validate password
Create access token
Return response

To create the login controller, enter this code in the auth.js file:

const bcrypt = require("bcrypt");
const jwt = require("jsonwebtoken");

const User = require("../models/user");
const { listeners } = require("../..");

const signup = async (req, res, next) => {
  try {
    //Validate user input
    if (!req.body.username && !req.body.email && !req.body.password) {
      res.status(400).send("Complete user information required");
    }
    //Check if user is an existing user
    const existingUser = await User.findOne({ email: req.body.email });
    if (existingUser) {
      res.status(400).send("User acount already exists.");
    }
    // //Hash user password
    const hashedPassword = await bcrypt.hash(req.body.password, 10);
    // //Save user record into the db
    const newUser = await User.create({
      username: req.body.username,
      email: req.body.email,
      password: hashedPassword,
    });
    let newUserObj = newUser.toObject();
    const { password, id, ...rest } = newUserObj;
    //Return response
    return res.send({
      status: "success",
      user: rest,
    });
  } catch (e) {
    console.log(e.message);
  }
};

const login = async (req, res) => {
  const { email, password } = req.body;
  try {
    //Validate user input
    if (!email && !password) {
      return res.status(400).send("Please enter email or password");
    }
    //Check if user has an account
    const user = await User.findOne({ email });

    console.log(user, "USER");

    if (!user) return res.status(404).send("User not found");

    //Check if password is valid
    const isPasswordValid = await bcrypt.compare(password, user.password);

    if (!isPasswordValid) res.status(401).send("Invalid password");

    //Generate access token
    const token = jwt.sign(
      { user_id: user._id, email },
      process.env.JWT_SECRET,
      {
        expiresIn: "2h",
      }
    );

    user.accessToken = token;
    await user.save();

    res.status(200).send({
      status: "success",
      accessToken: token,
    });
  } catch (e) {
    res.send(e.message);
  }
};

module.exports = { signup, login };

With the code above, we have create a login logic that'll enable our blog users login. Open ./src/routes/auth.js and enter as shown code below:

Notice that we only use access token. In real world applications, you will also require a refresh token too to generate new access token whenever it expires.

Now, let's test the endpoint using your REST client. The response should look like this:

Congratulations on getting this far. Now, it's time to start building the main features of our Blog Application.

Before implementing the logic to enable user create article, we need a way of authenticating users. i.e only authenticated users should be allowed to perform other activities except the viewing articles.

Firstly, open the .env file and enter the code below:

JWT_SECRET=xx-xx-xx

Enter a secret code of your choice.

Next, create verifyToken.js in the middlewares directory. Now, open verifyToken.js and enter the code below:

const jwt = require("jsonwebtoken");
const { User } = require("../models");

const { TokenExpiredError } = jwt;

const catchError = (error, res) => {
  if (error instanceof TokenExpiredError) {
    return res.status(401).send({ message: "Unauthorized! Access Token has expired!" });
  }
};

const verifyToken = async (req, res, next) => {
  try {
    const token = req.headers.authorization;
    const tokenString = token.split("Bearer")[1].trim();
    if (!tokenString) {
      return res.status(403).send({ message: "No token in header!" });
    }
    const decoded = jwt.verify(tokenString, process.env.JWT_SECRET);
    const user = await User.findOne({ email: decoded.email });
    if (!decoded || !user) {
      res.status(404).send({ message: "Invalid token!" });
    }
    if (user) {
      req.user = user;
    }
    next();
  } catch (error) {
    return catchError(error, res);
  }
};

module.exports = { verifyToken };

The code above is a middleware function to verify users to ensure that only logged in user can perform operations such as post article, update article and so on.

Post Article

This is one of the most important features of any blog application. In our blog application, we expect all users to be able to post and read articles and comments.

We wouldn't be handling roles in this application. We assume there is only one role i.e user.

Feature Checklist:

Validate user (check if they are still logged in).
Validate article title to know if nobody has posted the exact same article before.
Check if user has entered the required data.
Save article in the database

Let's start by creating our model.

Open models/article.js and enter the code below:

const mongoose = require("mongoose");

const articleSchema = new mongoose.Schema(
  {
    title: { type: String, required: true },
    body: { type: String, required: true, },
    author: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true },
    category: { type: mongoose.Schema.Types.ObjectId, ref: "Category", required: true },
    comments: [{ type: mongoose.Schema.Types.ObjectId, ref: "Comment" }],
    upvotes: { type: mongoose.Schema.Types.Number, default: 0 },
    downvotes: mongoose.Schema.Types.Number,
  },
  { toJSON: { virtuals: true }, toObject: { virtuals: true }, timestamps: true }
);
const Article = mongoose.model("Article", articleSchema);
module.exports = Article;

The above code creates a schema for the article collection by defining its fields and their properties: title, body, author, category, comments, upvotes, and downvotes. The author field references a specific user in the User collection. While, the category field references a category in the Category collection. While, comments reference an array of comments in the Comment collection.

Our Article model is highly dependent on three other models (user, category and comment). We only have user model setup. Now, let's setup category and comment model. Now enter models/category.js and enter the code below:

const mongoose = require("mongoose");
const categorySchema = new mongoose.Schema(
  {
    name: { type: String, required: true, },
  },
  { toJSON: { virtuals: true }, toObject: { virtuals: true }, timestamps: true }
);
const Category = mongoose.model("Category", categorySchema);
module.exports = Category;

Now, let's create a model for Comment collection. Comment model also has fields which reference user and article collections. Since, you have already created models for user and article. We can now create models for comment.

Comments just like article model also references two other field. So, Open models/comment.js and enter the code below:

const mongoose = require("mongoose");
const commentSchema = new mongoose.Schema(
  {
    content: { type: String, required: true, },
    author: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true,
    },
    article: { type: mongoose.Schema.Types.ObjectId, ref: "Article", required: true,
    },
  },
  { toJSON: { virtuals: true }, toObject: { virtuals: true }, timestamps: true }
);

const Comment = mongoose.model("Comment", commentSchema);
module.exports = Comment;

In the above model declaration, the article field references a specific article in the Article collection through its _*id field. Also, the author field references a specific author in the User model through its _*id field.

Since the article model requires the category field, it'll be best for us to create a category controller first, to be able to create category. Then, we would create our article controller.

Open controllers/category.js

const Category = require("../models/category");
const createCategory = async (req, res, next) => {
  const { name } = req.body;
  try {
    if (!name) {
      return res.status(400).send("Please provide category name");
    }
    const categoryExist = await Category.findOne({ name: name });
    if (categoryExist) {
      return res.status(400).send("Category already exists");
    }
    const category = new Category({ name });
    await category.save();
    res.status(201).send({ success: true });
  } catch (error) {
    res.send(error);
  }
};

module.exports = { createCategory };

The above code would enable us create new category.

Also, enter the code below to test the createCategory controller.

const { createCategory } = require("../controllers/category");
const router = require("express").Router();
const { verifyToken } = require("../middlewares/verifyToken");

router.post("/", verifyToken, createCategory);
module.exports = router;

Note that we passed verifyToken middleware to the above request. We want only authenticated users to be able to create categories.

Also, let's modify our auth routes and create index.js too in the routes directory:

../routes/auth.js

../routes/index.js

Finally, go to index.js file in the root directory, update the file as shown below:

Now, make a GET request to http://localhost:5000/blog/api/categories in your REST client to create a new category. The request and response of testing the endpoint is shown below:

Create as many categories as much as you can for testing purposes

Now, let's create a controller to implement the logic for creating new article:

Open ../controllers/article.js too and enter the code below:

async postArticle(req, res) {
    const { title, body, category, author } = req.body;
    try {
       //Check if user is already logged in
      if (!req.user) {
        throw new Error("User not found!");
      }
      //Check if there is no already-existing article with the provided title
      const articleExist = await Article.findOne({ title: req.body.title });
      if (articleExist) res.status(400).send("Article already exists");
       //Check if user has filled all fields 
      if (!title && !body && !category && !author) {
        res.status(400).send({ message: "One or more fields missing!" });
        return;
      }

      const newArticle = new Article({
        title: title,
        body: body,
        category: category,
        author: author,
      });
      const data = await newArticle.save();
      res.status(200).send(data);
    } catch (error) {
      throw new Error(error);
    }
  },

The code above will enable user post a new article on the blog.

To test this feature, create a file named article.js in the routes directory. We will be setting up the route for postArticle feature in it. Then open article.js and enter the code below.

const { postArticle} = require("../controllers/article");
const router = require("express").Router();

router.post("/", createArticle);

module.exports = router;

Before testing this feature, we would pass the verifyToken middleware to the postArticle route. This serves as a gatekeeper that checks if users are logged in and that their token is still valid before allowing them to post an article. Modify the code above to look like this:

const { postArticle } = require("../controllers/article");
const router = require("express").Router();
const { verifyToken } = require("../middlewares/verifyToken");

router.post("/", verifyToken, postArticle);
module.exports = router;

Now open ../routes/index.js and modify the code to look like this:

Ensure you pass the access token returned when you logged in to the request header before making the request.

Now, its time to test our new endpoint. Open your REST client and make a POST request as shown below:

Awesome! We can now post articles on our blog.

Next, Let's build the feature to view an article.

Read an Article

With the exception of a few cases where regular users are restricted from accessing specific premium contents on sites like Medium, all users should be able to read articles on blogs. Therefore, we will develop a feature that allows users to view a specific article.

Feature Checklist:

Match article Id extracted from query parameter with the article id's in the database to check for its existence.
If its exists, return the article. Else, return an error.

Now, open the ../controllers/article.js and enter the code below:

async getArticleById(req, res) {
    try {
      const article = await Article.aggregate([
        {
          $match: {
            _id: new mongoose.Types.ObjectId(String(req.params.articleId)),
          },
        },
      ]);

      if (!article) return res.status(404).send("Article not found!");
      return res.status(200).send({
        status: true,
        article,
      });
    } catch (error) {
      throw new Error(error || "Article not found");
    }
  },

The code above returns an article by matching the articleId provided by the user through the query parameter with the article ids in the database.

Why did we use $match here instead of a simple Mongoose findOne function?

$match, gives us the flexibility of attaching more stages. Therefore, we won't have to write separate queries to match, join and group our data. We only write only one query. Whereas, findOne on the other hand doesn't offer this kind of flexibility.

Next, open ../routes/article.js and modify it as shown below:

Now, open your REST client and test the new feature as shown below:

Awesome! We can now get each article by its ID field. But, we still need to modify our query to make it return a more comprehensive author data. Instead of just the author's id. Same for the category and comment fields. For now, we'll focus on populating the author and category information.

To achieve this, we need a way to relate the collections involved (user, article and category). Then we can populate the author information for each article. We will relate the article and user collection by declaring the $lookup stage and passing it to the $match stage.

const article = await Article.aggregate([
        {
          $match: {
            _id:new mongoose.Types.ObjectId(req.params.articleId),
          },
        },
        {
            $lookup: { 
                from: "users",
                let: { authorId: "$author"}
            }    
        }
]);

In the code above, we defined the collection we are fetching data from using the "from" property. Next, we declared the authorId variable using "let" to store the value of the author field.

To learn more about $lookup, check the first article in this series.

Next, we create a subpipeline using the pipeline keyword to specify an array of aggregation stages. The pipeline field is not a required field for the $lookup stage. We used it to transform user collection documents before joining.

The first stage in this array is to match the authorIdof the current collection (article) with the user collection's _id field using the code below.

 [{
     $match: {
         $expr: { $eq: ["$_id", "$$authorId"] },
        },
  }]

This query instructs MongoDB to check through the user collection for the user with the specified _id.

We used $expr to define aggregation expressions. And $eq to specify equality expression.

We used $$ to refer to the authorId field that we declared in the let field of the $lookup stage. This notation helps to distinguish between regular fields and variables within the context of the aggregation pipeline.

Also, we need to add the "as" field to specify our desired name for the array returned as a result of the $lookup. This field is strictly required. Without it, MongoDB will throw an error. Add the "as" field to the query as shown below:

{
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
            ],
            as: "author", //Specifies the name of the resulting object
          },
}

The modified version of the getArticleById controller should look like this:

async getArticleById(req, res) {
    try {
      const article = await Article.aggregate([
        {
          $match: {
            _id: new mongoose.Types.ObjectId(req.params.articleId),
          },
        },
        {
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
            ],
            as: "author",
          },
        }
      ]);

      if (!article) throw new Error("Article not found");
      return res.status(200).send({
        status: true,
        article,
      });
    } catch (error) {
      throw new Error(error || "Article not found");
    }
  },

Now, let's test to see if our code works. Open your REST client and make a request as shown below.

Awesome! Our code works. But, there is a little problem. Our query populated the entire author data, including the password field. Also, it returned user data as an array. The data has to be looped through from the client to extract the user information. This could hurt the performance of our application. We'll be fixing these next.

How can you solve these problems?

Firstly, we should extract only the needed data from the user's object instead of the entire fields. To achieve this, we would introduce the $project stage to our sub-pipeline to specify only fields we want to return. Let's implement the $project stage as shown below:

{
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
              {
                $project: {
                  _id: 1,
                  username: 1,
                },
              },
            ],
            as: "author",
          },
        },

To learn about the $project stage, refer to the first article of this series

Re-test the endpoint as shown below:

We have successfully extracted only fields we needed from the author information.

Next, we will transform the author field into an object. To turn the author field into an object, we will use $unwind stage of the aggregation pipeline.

Note that we didn't use $unwind stage in the subpipeline. The $unwind stage is not added to the subpipeline of $lookup because it is a separate stage that comes after the $lookup stage in the aggregation pipeline. It is used to transform the data structure after the join has been performed.

Modify the query to add the $unwind stage as shown below:

async getArticleById(req, res) {
    try {
      const article = await Article.aggregate([
        {
          $match: {
            _id: new mongoose.Types.ObjectId(req.params.articleId),
          },
        },
        {
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
            ],
            as: "author",
          },
        },
        {
             $unwind: "$author",
        }
      ]);

      if (!article) throw new Error("Article not found");
      return res.status(200).send({
        status: true,
        article,
      });
    } catch (error) {
      throw new Error(error || "Article not found");
    }
  },

Now open your REST client to test the endpoint as shown below:

Good! It works.

To populate the category information into each article, we will follow the exact approach used when populating the author's information. Add the code below to the existing query as shown below:

{
          $lookup: {
            from: "categories",
            localField: "category",
            foreignField: "_id",
            as: "category",
            pipeline: [
              {
                $project: {
                  _id: 1,
                  name: 1,
                },
              },
            ],
          },
        },
}

The code above populates only the required fields of category collection. Now, test the code as shown below:

Awesome! We have successfully implemented a feature to allow our users to view specific article with its author and category information.

Comment on Article

In the last section, we have successfully implemented the feature to fetch an article with its author and category information. But, we still need to populate comments associated with each article.

In this section, we will be implementing the endpoint to allow users comment on specific article.

Feature Checklist:

Check if author id is valid
Check if article id is valid
Check if comment's content is not empty
Save comment

Firstly, create comment.js file in controllers directory and enter the code below:

const Comment = require("../models/comment");
const Article = require("../models/article");
const User = require("../models/comment");
const { default: mongoose } = require("mongoose");

const createComment = async (req, res, next) => {
  const { content, article } = req.body;
  const { email } = req.user;

  try {
    const isAuthorValid = await User.aggregate([
      {
        $match: { email: String(email) },
      },
    ]);

    if (!isAuthorValid) {
      return res.status(404).send("Author not found");
    }

    if (!content) {
      return res.status(400).send("Content cannot be empty");
    }

    const isArticleExist = await Article.findOne({ _id: article });
    if (!isArticleExist) {
      return res.status(400).send("Invalid article provided");
    }
    const newComment = await Comment.create({
      article,
      author: req.user._id,
      content,
    });
    return res.status(201).send({ comment: newComment, success: true });
  } catch (error) {
    throw new Error(error);
  }
};

module.exports = { createComment };

Now, navigate to routes directory and create comment.js. Then enter the code below:

const { createComment } = require("../controllers/comment");
const router = require("express").Router();
const { verifyToken } = require("../middlewares/verifyToken");

router.post("/", verifyToken, createComment);

module.exports = router;

Now modify ../routes/index.js file to look like this:

You can now test the new functionality. Open your REST client and make a request to the defined endpoint as shown below:

Awesome, our users can now comment on a specific article.

Now, let's write the logic to populate the comments array in our article object.

Open ../controllers/article.js. Navigate to getArticleById function, After the { $unwind: "$category" }, add the code below:

We use the code above to populate an array of comments in our article by introducing another $lookup stage . Also, we used $project stage to specify the structure of the resulting article object.

Now, open your REST client and test the endpoint as shown below:

Cool! That works too.

View All Articles

Access to all blog posts is one of the most critical features of any Blog API. Users shouldn't see a complete blog post with its comments until they click on the article to read it.

Feature Checklist

Check whether there are already existing articles.
Implement a logic that provides appropriate responses when no article exists.
Write a query to retrieve all articles.
Return data with response message

Now, let's get started

Open ../controllers/article.js and create a new controller function named "getAllArticles" and enter the code below:

 async getAllArticles(req, res) {
    try {
      // Retrieve all articles
      const allArticles = await Article.aggregate([
        {
          $match: {},
        },
        {
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
              {
                $project: {
                  _id: 1,
                  username: 1,
                },
              },
            ],
            as: "author",
          },
        },
        {
          $unwind: "$author",
        },
        {
          $lookup: {
            from: "categories",
            localField: "category",
            foreignField: "_id",
            as: "category",
            pipeline: [
              {
                $project: {
                  _id: 1,
                  name: 1,
                },
              },
            ],
          },
        },
        {
          $unwind: "$category",
        },
      ]);
      //Check if there are existing articles
      if (allArticles.length.length === 0) {
        return res.status(404).send({
          status: false,
          message: "No article found!",
        });
      }
      console.log(allArticles);
      return res.status(200).send({ status: true, articles: allArticles });
    } catch (error) {
      throw new Error(error.message);
    }
  },

The code above retrieves all articles through a query. And if there are no existing articles, a suitable response will returned.

Note: We do not have to use aggregation pipeline for all scanerios, the find() method of mongoose could have return all articles. But, we needed to populate other information (author and user) through the same query, using $match became inevitable.

Also, open ../routes/article.js and define a route to make GET request to retrieve all articles as shown below:

Open your REST client and make a GET request to http://localhost:5000/blog/api/articles to this feature as shown below:

Cool! Our users can now view all articles on our blog. Before we implement the next feature, let's group our articles by their category. To achieve that, modify "getAllArticles" controller function by adding the code following after { $unwind: "$category" }

{
      $group: {
         _id: "$category._id",
         category: { $first: "$category.name" },
         articleCount: { $sum: 1 },
         articles: { $push: "$$ROOT" },
      },
  },

Your "getAllArticles" controller should now look like this:

async getAllArticles(req, res) {
    try {
      // Retrieve all articles
      const allArticles = await Article.aggregate([
        {
          $match: {},
        },
        {
          $lookup: {
            from: "users",
            let: { authorId: "$author" },
            pipeline: [
              {
                $match: {
                  $expr: { $eq: ["$_id", "$$authorId"] },
                },
              },
              {
                $project: {
                  _id: 1,
                  username: 1,
                },
              },
            ],
            as: "author",
          },
        },
        {
          $unwind: "$author",
        },
        {
          $lookup: {
            from: "categories",
            localField: "category",
            foreignField: "_id",
            as: "category",
            pipeline: [
              {
                $project: {
                  _id: 1,
                  name: 1,
                },
              },
            ],
          },
        },
        {
          $unwind: "$category",
        },
        {
          $group: {
            _id: "$category._id",
            category: { $first: "$category.name" },
            articleCount: { $sum: 1 },
            articles: { $push: "$$ROOT" },
          },
        },
      ]);
      //Check if there are existing articles
      if (allArticles.length.length === 0) {
        return res.status(404).send({
          status: false,
          message: "No article was found!",
        });
      }
      console.log(allArticles);
      return res.status(200).send({ status: true, data: allArticles });
    } catch (error) {
      throw new Error(error.message);
    }
  },

The code above should return data containing categories of articles. Open your REST client to test this feature:

View Most Recent Article

This feature will enable users to view the most recent article.

Feature checklist

Fetch and count the number of articles in the database.
Check if there is article in the database.
Write a query to get the latest article in the database.
Return data

Now open ../controllers/article.js and enter the code below:

 async getMostRecentArticle(req, res) {
    try {
      const articles = await Article.find();
      if (articles.length === 0)
        return res.status(404).send("No article found!");
      const article = await Article.aggregate([
        {
          $sort: {
            createdAt: -1,
          },
        },
        {
          $limit: 1,
        },

      ]);
      return res.status(200).send({ status: true, article: article });
    } catch (e) {
      throw new Error(e.message);
    }
  },

To retrieve the latest article from the database, we used an aggregation pipeline query with two stages - $sort and $limit. Firstly, the articles were sorted in descending order based on the createdAt field by using the $sort stage with a -1 value.

While this approach works, it may be considered an overkill for a simple task like this. Instead, the findOne method of Mongoose can be used to achieve the same result. The aggregation pipeline framework should be reserved for more complex tasks. The code above is provided as a proof of concept to demonstrate how $sort and $limit work.

Next, open .../routes/article.js and add a new route as follows:

Now, open your REST client to test the new feature as shown below:

Hurray!! It works.

Congratulations! You now have a good understanding of how you can use stages and operations of aggregation pipeline framework in real-world applications.

Conclusion

Throughout this article, we have demonstrated how to utilize the powerful capabilities of the MongoDB Aggregation Pipeline framework to create various features of a blog application. By following this guide, you have learned about some of the most essential stages and operations of the aggregation pipeline framework, including $match, $lookup, $group, $sort, $limit, $project, $unwind, and $expr. Although this article does not cover all of the aggregation pipeline stages and operations, it provides a solid foundation that will allow you to be more productive when working on future MongoDB projects.

Next Steps

Remember the popular saying "practice makes perfect". You have to practice to have an absolute understanding of the concepts. I could not build the last three features I mentioned due to the size of the article.

Attempt these features:

Limit the results to a specific number of articles
Retrieve the most commented articles.
Retrieve articles with their comment count.

Also, try out whatever other features you can think of. Let me know what you can learn in the comment section below. I look forward to hearing from you soon. Until the next article, take care.

References:

HTTP: The Fundamentals

Temiogundeji — Wed, 02 Aug 2023 02:51:55 +0000

This article gives a detailed explanation on http, why you should understand it and how important it is in web development.

Introduction

HTTP (Hypertext Transfer Protocol) is the protocol that powers web communication and serves as the backbone of information exchange on the Internet. In this article, we explore the fundamentals of HTTP, its role in web development, and its significance in facilitating seamless interactions between clients and servers. Also, we dive deep into HTTP requests and responses, and the components of each that makes it essential in web development.

Who is this article for

This article is for readers at all levels who want to have an intricate understanding of HTTP.

Prerequisites

An ability to comprehend English writing.
A basic understanding of the world wide web and the Internet.

Learning Objectives

At the end of this article, you will:

Understand what HTTP is
Understand the characteristics of HTTP
Understand the importance of HTTP
Understand how HTTP works.
Understand HTTP functions that make it essential in web development.
Understand the Anatomy of an HTTP request and Response
Gain a deep understanding of HTTP status codes and their importance in troubleshooting problems in web applications.

What is HTTP?

HTTP is an Application-Layer protocol that enables the communication between clients and servers. It is the foundation of data exchange on the World Wide Web, enabling the retrieval and delivery of resources such as HTML pages, images, videos, and more between clients and servers.

Characteristics of HTTP:

HTTP (Hypertext Transfer Protocol) exhibits several key characteristics:

Stateless: It is stateless, so it doesn't keep track of past requests or sessions. The server also doesn't store client-specific information between requests. Cookies and session tokens are used to maintain the state instead.
Connectionless: It is connectionless. Each request-response exchange is a separate transaction, and once the response is delivered, the client-server connection is closed. This allows for efficient resource allocation on servers.
Text-Based: It is a text-based protocol, where messages exchanged between clients and servers are in human-readable format. Both requests and responses consist of plain text lines containing headers, status codes, and optional message bodies. This text-based nature makes it easy to read and debug HTTP traffic.
Extensible: It is an extensible protocol, allowing for the development of additional features and protocols built upon its foundation. It supports the addition of custom headers, methods, and protocols to cater to specific requirements or enhance functionality. This extensibility has facilitated the growth of web technologies and APIs built on top of HTTP.
Flexible Content Handling: It can handle various types of content, including HTML pages, images, documents, videos, and more. It supports content negotiation, allowing clients and servers to agree on the most appropriate representation of a resource based on factors such as content type, language, or encoding.
Uniform Resource Identification: Uses Uniform Resource Identifiers (URIs) to identify and locate web resources. URIs (It identifies a resource and differentiates it from others by using a name, location, or both.) specify the address and path to a specific resource on the web. They provide a standardized way to reference and access resources across different web platforms.
Scalability: It is designed to be scalable, allowing for a large number of clients to interact with servers concurrently. It supports parallel processing of multiple requests and responses, enabling efficient handling of high-traffic loads.
Caching: It includes mechanisms for caching resources, allowing clients to store copies of resources locally. Caching reduces the need for repeated requests to the server, thereby improving the performance of web applications and reducing network traffic.

These characteristics make HTTP a versatile and widely adopted protocol for web communication, enabling the retrieval, delivery, and exchange of resources over the Internet.

Importance of HTTP

How HTTP works can be likened to sending a letter through a postal worker. It's like putting a letter in an envelope with the recipient's address written on it. The envelope represents the HTTP protocol, a set of rules for transmitting information over the Internet. Just as a postal worker reads the destination address and delivers the letter, web browsers and servers handle HTTP requests and responses, acting as the digital equivalent of postal workers. The internet serves as the network infrastructure, similar to the postal system, enabling the transmission of information between computers. HTTP facilitates the proper addressing, delivery, and understanding of data, making clients request resources from servers and receive appropriate responses.

Therefore, HTTP is pivotal in facilitating web communication and enables clients to request and receive web resources from servers. Its standardised nature, request-response cycle, extensibility, and the introduction of HTTPS make it a fundamental protocol for web browsing, application development and secure online interactions.

Functions of HTTP

So far, we have looked at what HTTP is and why it is essential. Next, we will be exploring some of its functions that makes it essential in web development.

HTTP (Hypertext Transfer Protocol) performs several important functions in web communication:

- Resource Retrieval: It allows clients (such as web browsers) to retrieve resources from web servers. Clients send HTTP requests to servers, specifying the desired resource's URL (Uniform Resource Locator). The server processes the request and returns the requested resource by the client, such as a web page, image, document, or video to it. To learn about HTTP, first had to arrive at this page by either making an HTTP request to Google which returns a myriad of results or getting redirected from a website or making an HTTP through your browser to this site directly. And then you get served an HTML page by the server when you click on the link to this article.

- Client-Server Communication: It enables communication between clients and servers in a client-server architecture. Clients initiate requests to servers, and servers respond with the requested resources accompanied by the appropriate status codes indicating the status of the request. This communication allows the exchange of data and information over the internet.

- Provision of Request Methods: It provides various request methods, also known as HTTP verbs, to perform different actions on resources. Common methods include:

GET: Retrieves a resource from the server.
POST: Submits data to the server, typically to create or update a resource.
PUT: Updates or replaces a resource on the server.
DELETE: Deletes a resource from the server.
HEAD: Retrieves only the headers of a resource, without the message body.

More details on HTTP methods will be provided in the later part of the article.

Specification of Request and Response Information: HTTP headers carry additional information and instructions in both requests and responses. Headers providing metadata about the content type, caching directives, authentication details, cookies, and more. They enable customization, control, and optimization of the communication process between clients and servers.
- Indication of Request Status Through Status Codes: HTTP status codes are three-digit numbers returned by servers in response to client requests. These codes indicate the outcome of the request and provide information about whether the request was successful, encountered an error, or requires further action. Common status codes include 200 (OK), 404 (Not Found), 500 (Internal Server Error), and more.
- Identification and Location of Web Resources Through URLs: URLs (Uniform Resource Locators) are used in HTTP to identify and locate web resources. A URL consists of the protocol (e.g., "http://" or "https://"), domain name, port number, path, and optional query parameters. URLs serve as addresses for accessing specific resources on the web.
Content Negotiation: It supports content negotiation, allowing clients and servers to agree on the most appropriate representation of a resource based on factors such as content type, language, or encoding. This flexibility allows for delivering customized content to clients based on their preferences and capabilities.

These functions collectively enable the retrieval, delivery, and exchange of resources over the internet, forming the foundation of web communication and powering various web applications, APIs, and services.

How HTTP Works

HTTP works through a mechanism called HTTP messages. There are two types of HTTP messages:

- Request: They are messages sent by clients to the server to trigger an action.
- Response: They are messages sent to the client by the server in response to the request made by the client.

Client-Server Model

HTTP Request Messages

HTTP request is composed of three different components:

An HTTP client sends an HTTP request to a server in the form of a request message which includes the following format:

Request Line:

A request line contains three components:

- HTTP method to be used.
- URI of the requests.
- HTTP protocols version to be used.

They have this structure:

HTTP-method URI HTTP protocol.

For now, just know that the HTTP method specifies the kind of action the user wants to perform. Actions include: Reading a resource, updating a resource, storing a resource or deleting it on the server. We will discuss the HTTP method in great detail in the later part of this article. The URI refers to the address where the resource is located on the server, it is also known as the request target. HTTP protocol refers to the version of the HTTP protocol to be used. E.g. HTTP/1.1, HTTP/2.0 revision. A typical Request line looks like the below:

POST /API/books HTTP/1.1

The above request line simply shows that a client wants to send data to the server.

A set of header fields are simply metadata sent with a request to provide information about the request. Each header is specified using this format.

Host: en.wikipedia.com.

Connection: Keep-Alive.

The two examples (Host and Connection) above are some of the important request headers that should be used in our HTTP requests. Also, we can introduce our headers too.

- A body (optional): The request body is where we put additional information we want to send to the server. The request body may become important depending on the kind of request method we want to use. When making a POST request (using the POST method in a request), the body is important as it indicates the data we are trying to send to the server. However, the GET request does not require a body. We do not want to send complex information to the server when trying to get data from it. A typical request body for a POST request would look like this:




{
    username: “adam”,
    password: “123”
}

That said, an HTTP request with three parts looks like this:

POST /API/books HTTP/1.1

`Host: api.myapp.com

Content-Type: application/json

Cache-Control: no-cache
`



{
     "title": "The nice housemate",                                                                                                                                                                                                                                                                                                           
     "author": “Christopher Veebute“
}

HTTP Request Methods:

HTTP methods (sometimes called verbs) are used to define actions that should be performed on the resource identified. What the resource represents depends on the implementation of the server. It could be a file, pre-existing data generated, or data generated as a result of executables that reside on the server. In HTTP/1.0, only GET, HEAD, and POST methods are defined in its specification. And then HTTP/1.1 comes with 5 additional methods namely: PUT, DELETE, CONNECT, OPTIONS, and TRACE methods. Method names are case-insensitive, unlike header names. Below are some of the available methods:

i. GET:

The GET method is used to retrieve data from the server without any changes to it. It is also preferred over the POST method as it can be addressed over the URL. This enables bookmarking and sharing and makes GET responses eligible for caching, which can save bandwidth.

Example use-cases for GET requests are: Getting the list of blog posts by a particular author in a blog app. Getting the list of products added to the shopping cart by a user.

ii. POST:

POST method is used when sending data to the server. Some of its use cases are file upload, form submission and so on. Every time you post a message to a forum, subscribe to a mailing list or complete an online shopping transaction. You make use of the POST method.

iii. PUT:

The PUT method asks the target resource to establish or modify its state according to the representation provided in the request. The client defines the server's target location, which sets it apart from POST. Also, it is used to update an existing resource on the server. It is typically used when the client wants to send data to the server to replace or modify an existing resource. If you retry a request numerous times, that will be equal to a single request conversion i.e. It is idempotent.

iii. PATCH:

The PATCH method makes partial modification to a target resource. It does this without completely replacing the resource. Sending the same request to a resource using patch method does not make changes to the state of the server or the resource. Unlikely PUT, which acts exactly opposite to that. To learn more about the differences between both methods

Request Headers

Request Headers are used in HTTP requests to provide information about the HTTP requests so that the server can tailor the response accordingly. Headers are specific in their functions. For example, there is a header whose function is to supply authentication credentials. Also, Accept-* headers are used to specify the format of the response acceptable by the client. Other functions of headers are to control caching, get information about the user-agent or referrer etc. Note, some headers exist in the request header but are referred to as representation headers by the specification. An example is the popular Content-Type header. Below are some of the request headers passed with a GET request.

`GET /about.html HTTP/1.1

Host: https://www.freecodecamp.org/news/about/

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0

Accept: text/html, application/xhtml+xml,application/xml;q=0.9,/;q=0.8

Accept-Language: en-US, en;q=0.5

Accept-Encoding: gzip, deflate, br

Referer: https://www.freecodecamp.org/news

Connection: keep-alive

Upgrade-Insecure-Requests: 1

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"

Cache-Control: max-age=0
`

HTTP Response

HTTP response is how a server responds to a client's request. The response aims to provide the client with the resources it requested, send an error to the client in case an error occurs in the processing of its request, or inform the client that the action it requested has been carried out. Below is the component of an HTTP response:

A status line:

The status line is the first line in the response message. It consists of three items:

The HTTP version number shows the HTTP specification to which the server has tried to make the message comply.

A status code, which is a three-digit number indicating the result of the request.

A reason phrase, also known as status text, is human-readable text that summarizes the meaning of the status code.

The status line can be summarized below:

HTTP/1.1 200 OK

Response Status Codes

HTTP response status codes specify whether a request is successful or not. There are classified into 5 groups:

** - Informational responses (1xx):**

This interim response instructs the client to proceed with the request or, if the request has already been completed, to disregard the response.

** - Successful responses (2xx):**

This indicates that the request made by the client to the server has been successful. Or that the server returned the right response to the client’s request. A successful response can have different meanings depending on the type of request method used. For example: for the GET request method: It means that the client has successfully fetched the requested resources from the server, for the POST method, it could mean that a resource password to the request body has been stored on the server in the DB.

** - Redirection messages (3xx):**

The HTTP redirection error messages are the responses that are given by the server side to guide the client to a new location by providing the URL of that specific place. These codes are returned if the request has more than one possible response.

** - Client Error responses (4xx):**

These are error messages that occur as a result of a client's request. It means the request contains incorrect syntax or cannot be fulfilled. It could be that the user sent too many requests in a lesser amount of time which is not in line with the server’s rate-limiting configuration, It could be as a result of the client not authenticating and many other reasons. The client error code returned by the server indicates the cause of the error.

** - Server Error responses (5xx):**

Server error codes are also considered errors. However, they denote that the problem is on the server’s end. This can make them more difficult to resolve.

Understanding HTTP response status codes is essential for debugging web applications and for understanding the results of HTTP queries. These codes enable developers and system administrators to quickly locate and fix problems, resulting in a smooth user experience and improved program stability.

For a more detailed explanation of the error status code, please go through these guides:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses

https://kinsta.com/blog/http-status-codes/

Response Headers:

The response header is a component of a network packet sent by a server to a client in response to the request sent by the client. It is utilized in web communication to deliver web pages and other resources to clients. The information embedded with the HTTP response header includes the destination IP address, data type, host address and more. HTTP headers include the following:

` Accept-Ranges

Age

ETag

Location

Proxy-Authenticate

Retry-After

Server

Vary

WWW-Authenticate

Response Body:`

The HTTP response body is the data that is sent from a server to a client as part of an HTTP response. It contains the content or payload that the client requested from the server. The response body can include various types of data, such as HTML, XML, JSON, images, videos, or plain text.

Below are a few examples of HTTP response bodies:



<!DOCTYPE html>

<html>

<head>

<title>Example Page</title>

</head>

<body>

<h1>Hello, World!</h1>

<p>This is an example HTML response.</p>

</body>

</html>

In this example, the response body contains an HTML document with a title, heading, and paragraph. Below is another example of a response body in json format.

JSON Response Body:



{
    "name": "John Doe",
    "age": 30,
    "email": "johndoe@example.com"
}

This JSON response body provides information about a person, including their name, age, and email.

Plain Text Response Body:

This is a plain text response.

Here, the response body consists of simple plain text.

Image Response Body:

Making a GET request to an image hosting service or cloud object storage, such as Amazon S3, Cloudinary, or Dropbox, to retrieve a specific image hosted on it would result in an image response. For example, when making a GET request to this endpoint, it returns an image hosted on Cloudinary:

(You may need to provide the actual endpoint URL for clarity or context.)

https://res.cloudinary.com/demo/image/upload/sample.jpg

In this case, the response body contains the binary data of an image file. The client can interpret this data to display the image.

XML Response Body:

`<?xml version="1.0" encoding="UTF-8"?>

Jane

John

Reminder

Don't forget to submit the report.

This XML response body represents a note with a recipient, sender, heading, and body.

These examples illustrate the variety of data that can be included in an HTTP response body, depending on the type of content requested and the server's response.
Where to go from here

Congratulations, you have gained a fundamental knowledge of HTTP, if you are keen on diving deeper into its advanced concepts. Below are a few suggestions.

- The evolution of HTTP from HTTP/1.0 to HTTP/2.0


Understanding of HTTP and HTTPS.
Features of different HTTP versions such as caching, pipelining, multiplexing, header compression, stream prioritization, server push and many other features. These features bring improvements in terms of performance, efficiency, and functionality to enhance the web browsing experience. As an engineer, they will help contribute to the development of high-quality, efficient, and responsive web applications.

Conclusion

In conclusion, the Hypertext Transfer Protocol (HTTP) serves as the backbone of communication on the World Wide Web, enabling the exchange of information between web browsers and servers. Throughout this article, we have explored the key aspects such as: what it’s all about, its importance, methods, request, response and so on.

It is worth noting that HTTP is not static but continually evolving. As new challenges and requirements arise, the protocol continues to be refined and enhanced. Keeping up with the latest developments and emerging standards will be essential for staying at the forefront of web development and ensuring optimal performance for users.

HTTP remains an indispensable protocol that enables seamless communication between clients and servers on the web. By understanding its features, implementing best practices, and leveraging additional tools and technologies, web developers can create faster, more efficient, and more reliable web experiences for users around the globe.

Build and Test a NodeJs API with ES6

Temiogundeji — Tue, 09 Mar 2021 06:26:59 +0000

Just like me, you must have attempted to build your Nodejs application using ES6 and beyond. In this article, I'll be taking you through the process of building and testing a basic API using ES6. Trust me, you will be amazed by the end of this post.

How it started

I had built some Nodejs API using the ES5, and everything works perfectly well, but I wasn't satisfied as I was unable to make use of some syntaxes which are somehow cool to me whenever I go through javascript code online. I found out I could actually do more with lesser code by writing my code in ES6 and beyond.

Wait a minute! What is ES6 (ECMAScript 2015) ?

ECMAScript is based on several originating technologies, the most well-known being JavaScript (Netscape) and JScript (Microsoft). It is a JavaScript standard meant to ensure the interoperability of Web pages across different Web browsers.

While the definition may seem bookish, ES6 and beyond come with lots of cool features from which I'll mention just a few. You must have come across or used some of the following syntaxes in your code:

The use of const and let, instead of var.

const is used to declare constants i.e. variables that are not meant to change through the program. It used to create immutable variables.

    `const tax_rate = 2.50;`

    let is used to declare mutable variables

    var is hoisted, using it may cause a program to behave unexpectedly at runtime, if care is not taken.

- The use arrow function.

// ES5
function shout() {
  console("Hurray!")
}

// ES6
const shout = () => console.log("Hurray!")

Writing a basic function in one line is cool. Isn't it? It also makes the code more readable and clean when using javascript built-in functions like map, reduce, filter, and so on. For example:

//ES5

var arr = [1,2,3,4,5,6];
var arrElements = arr.map(function (item) {
   return item;
})

//ES6

const arr = [1,2,3,4,5,6];
const arrrElements = arr.map(item => return item);

And lastly, you can make use of import and export keywords, as opposed to module.export and the require keyword.

You can read more on ES6 here, If you wish to learn more about it, in order not to digress from the purpose of this article, we have to proceed.

Setting up our project

Firstly, create a new folder from your editor of choice (mine is VSCODE!) and enter the following command in the terminal to generate a package.json file for our app:

npm init -y

This will generate a package.json file for you without any further questions.

{
  "name": "hasnode",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

next, we need to install some dependencies to set up our app. Enter the following command in your terminal:

npm install --save express morgan nodemon

Then, create an app.js file at the root directory and type the following command:

const logger  = require('morgan');
const express = require('express');

const app = express();

app.use(logger('dev'));
app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.get('/', (req, res) => {
    res.status(200).json({
        message: "Welcome to Express"
    });
})

app.listen(8000, () => console.log('Server running at 8001'));

In your package.json, add the following in your "script"

"scripts": {
 "start": "node app.js"
}

and remove "main": "index.js"

To test our code, open your browser (Chrome, Mozilla, or any other browser), go to this address:

localhost:8000

Your browser should return this:

message "Welcome to Express"

Let's play with our code a bit:

Go into your app.js and replace the following code:

const logger  = require('morgan');

const express = require('express');

with this:

import logger from 'morgan';

import express from 'express';

What did you see? An Error? If that's true, it's very much expected, you can only use the import statement when you have configured your app to use it. And that's what we are about to do now.

In order to configure our project to make use of ES6 syntax, we need to install some dependencies and do some configurations. Follow the steps below to get things working.

Before that, create an src folder and move the app.js file into it.

Firstly, we have to install babel and some of its modules as seen below:

npm install @babel/cli @babel/core @babel/plugin-transform-runtime @babel/preset-env @babel/register @babel/runtime @babel/node --save-dev

@babel/cli: A required install for using babel. It allows the use of Babel from the terminal and is available as ./node_modules/.bin/babel.
@babel/core: Core Babel functionality. This is a required installation.
@babel/node: This works exactly like the Node.js CLI, with the added benefit of compiling with babel presets and plugins. This is required for use with nodemon.
@babel/plugin-transform-runtime: This helps to avoid duplication in the compiled output.
@babel/preset-env: A collection of plugins that are responsible for carrying out code transformations.
@babel/register: This compiles files on the fly and is specified as a requirement during tests.
@babel/runtime: This works in conjunction with @babel/plugin-transform-runtime.

{
  "name": "hashnode-es6-node",
  "version": "1.0.0",
  "description": "",
  "scripts": {
   "start": "node app.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1",
    "morgan": "^1.10.0"
  },
  "devDependencies": {
    "@babel/cli": "^7.13.0",
    "@babel/core": "^7.13.10",
    "@babel/node": "^7.13.10",
    "@babel/plugin-transform-runtime": "^7.13.9",
    "@babel/preset-env": "^7.13.9",
    "@babel/register": "^7.13.8",
    "@babel/runtime": "^7.13.9"
  }
}

Next, add the following to the "script" section of your package.json.

"babel-node": "babel-node --presets='@babel/preset-env'"

In the root directory, create a babel.config.js file as opposed to .babelrc. that only applies to a single part of your project.

It is recommended that you use babel.config.json, since babel itself uses it.. Then enter the following code in the newly-created babel.config.json file.

{
    "presets": ["@babel/preset-env"],
    "plugins": ["@babel/transform-runtime"]
}

Babel won't work without the code above

From the earlier explanation, we now understand the purpose of adding the code above.

Next, we will configure babel to run our app by adding the following code to the script section in our package.json file.

"dev": "nodemon --exec npm run babel-node -- src/app.js"

In your package.json file, the script section of your code should look exactly like this:


"scripts": {
    "start": "node app.js",
    "babel-node": "babel-node --presets='@babel/preset-env'",
    "dev": "nodemon --exec npm run babel-node -- src/app.js"
  }

Then, enter this in the terminal to run your code: npm run dev

You should get the following output, by navigating to HTTP:localhost:8000.

message "Welcome to Express"

Whaoo!! You are awesome, you've successfully completed the first part of this article. It took you through the process of configuring a nodejs app for ES6 using babeljs.
Configure our setup to write unit tests for the basic API we created in the last section.

We will not be writing some sophisticated tests. Instead, I'll take you through the basic concepts you can easily build on as you write more complex apps in production.

In this section, we will be making use of mocha to run our unit tests, coupled with chai for our assertions. Type the following command in the terminal to install the mentioned modules.

npm install --save-dev mocha chai sinon-chai supertest

Awesome! you have installed all the necessary dependencies for our unit test to work.

Next, create a .mocharc.yaml file and paste the code below in there.

 require:
  - '@babel/register'

Some features may require polyfill, therefore install the following:

# Polyfills for builtin methods
npm install --save core-js
# Polyfills for generator function
npm install --save regenerator-runtime

Then, add import polyfills before '@babel/register'

Your .mocharc.yml should now look like this:

 require:
  - 'core-js'
  - 'regenerator-runtime'
  - '@babel/register'

The configuration above works fine with mocha 8.

Then, update the script section of your package.json:

` "scripts": { "start": "node app.js", "babel-node": "babel-node --presets='@babel/preset-env'", "dev": "nodemon --exec npm run babel-node -- src/app.js", "test": "mocha" } `

Lastly, create a test folder in the root directory, and create two new files in the newly created folder: setup.js and index.test.js.

In your setup.js, paste the code below:

`
import supertest from 'supertest';
import chai from 'chai';
import sinonChai from 'sinon-chai';
import app from '../src/app';

chai.use(sinonChai);
export const { expect } = chai;
export const server = supertest.agent(app);
`

In your index.test.js, paste the code below:

`
import { expect, server } from './setup';

describe('app page test', () => {
it('should return status code 200', done => {
server
.get('/')
.expect(200)
.end((err, res) => {
expect(res.status).to.equal(200);
done();
});
});

it('should return a message', done => {
server
.get('/')
.expect(200)
.end((err, res) => {
expect(res.body.message).to.equal(
'Welcome to Express'
);
done();
});
});
});
`

Run this command in your terminal to check if it worked.

npm run test

Your test result should look like this:

test result.PNG

With this, we have come to the end of this tutorial. But wait! You might want to run your app in production.
Bonus

Open your package.json, and update it:

` "babel-node": "babel-node --presets='@babel/preset-env'", "prestart": "babel ./src --out-dir build", "start": "node ./build/app", "dev": "nodemon --exec npm run babel-node -- src/app.js", "test": "mocha" } `

prestart script builds the content of the src/ folder and puts it in the build/ folder. When you issue the npm start command, this script runs first before the start script.
start script now serves the content of the build/ folder instead of the src/ folder we were serving previously. This is the script you’ll use when serving the file in production. Cloud services like Heroku automatically run this script when you deploy.
npm run dev is used to start the server during development. We have been using this script to run our app. Notice that we’re now using babel-node to run the app instead of the regular node. The --exec flag forces babel-node to serve the src/ folder. For the start script, we use node since the files in the build/ folder have been compiled to ES5.

Thank you so much for following through with this tutorial from the beginning, you are an awesome learner like me. Leave your comments below so that I can learn from it and make clarifications if there is a need for it.

DEV Community: Temiogundeji

How to Build a Blog API using MongoDB Aggregation Pipeline Framework

Introduction

Prerequisites

Overview of the Project

What is a Blog?

What is an API?

Project Goal

User stories

Designing the Structure for the Blog API

Setting up the Project

Initializing the project

Creating files and directories

Installing dependencies

Creating a Nodejs Server

Setting up Database

Implementing Features

Authentication

Signup:

Login

Post Article

Read an Article

Comment on Article

View All Articles

View Most Recent Article

Conclusion

Next Steps

References:

HTTP: The Fundamentals

Introduction

Who is this article for

Prerequisites

Learning Objectives

What is HTTP?

Characteristics of HTTP:

Importance of HTTP

Functions of HTTP

How HTTP Works

Client-Server Model

HTTP Request Messages

Request Line:

HTTP Request Methods:

Request Headers

HTTP Response

A status line:

Response Status Codes

Response Headers:

Further Reading

Conclusion

Build and Test a NodeJs API with ES6

How it started

Setting up our project