DEV Community: mech2dev

Deploying your API to the web

mech2dev — Mon, 19 Dec 2022 11:23:33 +0000

Overview

In previous articles, we have built APIs and tested them in our local environment. In this article we will deploy a back-end to the internet.

Here's the project we will be deploying:

DanielStai / jwt_auth

Authentication in an Express app

Implementing user authentication in an express app.

Technologies used

Authentication done using jwt (json web token). Passwords are hashed using bcrypt. The API uses a MongoDB database.

Endpoints

URL	METHOD	DESCRIPTION
api/users/	POST (public)	register a user
api/users/login	POST (public)	logs in a user
api/users/me	GET (private)	gets the info of the logged in user

How to run

Clone the repository on your local computer
Do npm run install to install the required dependencies
Set up your MongoDB collection
Do npm run dev to start the API

Test the API with Postman

View on GitHub

We will use Railway as our preferred hosting provider. There are many considerations when choosing a provider. Some considerations include cost, ease of scaling, customer support amongst many more.

Why Railway?

They provide a free basic tier which is perfect for learners who want to experiment and learn how to deploy our projects. For more traffic heavy applications, you may have to upgrade your plan. Read more about Railway here.
Railway makes deployment for learners easy since it takes care of most of the infrastructure (servers, load balancing, reverse proxies etc) behind the scenes.
The skills acquired when deploying on Railway are transferable and can be used on other popular hosting sites

Preparing for deployment

So far, we have been working on our projects in our local environment. We now want to deploy our API to the web and to do so, we need to make some changes to our API to make it 'production ready'.

First we will set NODE_ENV to 'production' in our .env file.

This will result in less verbose error messages being displayed to the user of the API, increasing efficiency.

This error handling feature is defined in our error handling middleware (in this case it's in the file jwt_auth/middleware/errorMiddleware.js).

Second we will install compression and helmet.

Compression enables us to compress the response sent back to the client making our app more efficient. Once installed, we will use compression in the root of our project as we do with other middleware.

We will also install helmet in the root of our project. Helmet provides additional HTTP headers that protect our app from some vulnerabilities.

To install both helmet and compression, run npm install helmet compression. Import and chain to your project in server.js as below.

app.use(helmet())
app.use(compression())
app.use(cors())
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended:false}))

We can also make some changes to how we handle logging in our project but that will be covered in a later article.

Creating a new project on Railway

Our project is ready to be deployed. Let's head over to the Railway website.

Create an account on Railway and start a new project by clicking on new project:

Click on deploy from GitHub repo and install the Railway app to your GitHub account:

Select on the repos you gave railway access to. In my case, this is the jwt_auth repo:

Click on deploy now and wait for the project to build and deploy. You might get an error since we haven't set our environment variables yet:

Set environment variables. Remember these are the variables we had defined in our .env file:

Wait for the build and deploy process to finish and if successful, you will get a success message as below:

Since our aim is to expose our API to the world, we then generate a domain name for our API:

This is what we get when we click on generate domain:

With that done, we have successfully deployed our API. You can monitor your deployment logs every once in a while since if an error occurs you can get the details there.

Conclusion

We have successfully build an API with jwt authentication and deployed it to the web. In the next article, we will test our API and debug some of the common issues encountered when deploying.

User authentication in an Express app

mech2dev — Mon, 19 Dec 2022 10:20:01 +0000

Overview

In this article we will delve into authentication using json web token (JWT). User authentication is the process of verifying a user attempting access to an application or part of an application.

In the API we will build, we will implement authentication by building middleware and using the middleware to protect the routes we need to limit access to.

DanielStai / jwt_auth

Authentication in an Express app

Implementing user authentication in an express app.

Technologies used

Authentication done using jwt (json web token). Passwords are hashed using bcrypt. The API uses a MongoDB database.

Endpoints

URL	METHOD	DESCRIPTION
api/users/	POST (public)	register a user
api/users/login	POST (public)	logs in a user
api/users/me	GET (private)	gets the info of the logged in user

How to run

Clone the repository on your local computer
Do npm run install to install the required dependencies
Set up your MongoDB collection
Do npm run dev to start the API

Test the API with Postman

View on GitHub

How does JWT work

Let's see how the JWT approach to authentication works.

Say a user gives the correct credentials and logs in. The server will generate a token and send it back in the response. Subsequent requests will have the token in the authorization header.

If the token is missing or expired, the user will not be able to continue accessing protected endpoints.

The token consists of three parts i.e. the header, payload and the signature. You can read more about what each of the parts of a jwt do here.

Below is an overview of the JSON web authentication process

We will also use the package bcrypt.

Project set up

To show how to implement jwt authentication, we will use a simple API that implements login functionality for the users of a blog. Here are the endpoints of the API:

URL	METHOD	DESCRIPTION
api/users/	POST (public)	register a user
api/users/login	POST (public)	logs in a user
api/users/me	GET (private)	gets the info of the logged in user

As described above, we don't need to implement authentication to register a user and to login the user. We however need to ensure that when returning user info, we only do so for the current logged-in user. This will require some form of authentication.

We will create a folder named jwt_auth. This is where all our API code will reside.

Lets create the config (where our models reside), routes (where we define the various routes in our API), middleware
(where we will build error handling and authentication middleware) and controllers (where we will define the callback functions fired when the routes in the Routes directory are matched) directories.

To set up the whole project you can refer to my articles on how to build a REST API and how to set up MongoDB for your project.

Here's the structure of our project at the end:

Implementing `bcrypt` and `jwt`

Now that we've seen our project structure, we will implement our authentication in 3 steps:

Encrypt password after logging in and generate token
Create middleware to check if token exists and its validity
Chain authentication middleware to the routes you need to protect

You can view the full project before and after adding authentication here (the version with authentication is on the branch 'authentication'):

DanielStai / netninja-react-backend

REST API for a React FrontEnd

This is an express rest api for a simple blog app that enables one to manage a simple blog.

You can view the client app here .

Endpoints

URL	METHOD	DESCRIPTION
api/blogs/	GET	fetches all blogs
api/blogs/{id}	GET	fetches a single blog
api/blogs/	POST	post a blog
api/blogs/{id}	DELETE	delete a single blog

View on GitHub

This project has been discussed over several blog posts hence we will only concern ourselves with implementing some authentication

Let's view our jwt_auth/controllers/userController.js file and see how we hash our passwords and generate our tokens.

const asyncHandler = require('express-async-handler')
const User = require('../models/userModel')
const mongoose = require('mongoose')
const bcrypt = require('bcryptjs')
const jwt = require('jsonwebtoken')

const registerUser = asyncHandler(async (req, res) => {
    const { name, email, password } = req.body

    if(!name || !email || !password){
        res.status(400)
        throw new Error ('Please fill in all fields')
    }

    const userExists = await User.findOne({ email })

    if(userExists){
        res.status(400)
        throw new Error ('User already exists')
    }


    const salt = await bcrypt.genSalt(10)
    const hashedPassword = await bcrypt.hash(password, salt)

    const user = await User.create({
        name,
        email,
        password:hashedPassword
    })

    if(user){
        res.status(201).json({
            _id:user.id,
            name:user.name, 
            email:user.email,
            token:generateToken(user._id)
        })
    } else{
        res.status(400)
        throw new Error ('Invalid user data')
    }

})

const loginUser = asyncHandler(async (req, res) => {
    const { email, password } = req.body

    const user = await User.findOne({email})

    if(user && await bcrypt.compare(password, user.password)){
        res.status(201).json({
            _id:user.id,
            name:user.name,
            email:user.email,
            token:generateToken(user._id)
        })
    }else{
        res.status(400)
        throw new Error ('Invalid credentials')
    }
})


const getThisUser = asyncHandler(async (req, res) => {
    res.status(200).json(req.user)
  })


const generateToken = (id) => {
    return jwt.sign({id}, process.env.JWT_SECRET, {
        expiresIn:'30d'
    })
}


module.exports = {
    registerUser,
    loginUser,
    getThisUser
}

Encrypting the password with bcrypt is as follows:

const salt = await bcrypt.genSalt(10)
const hashedPassword = await bcrypt.hash(password, salt)

We first create a salt with bcrypt's genSalt method and use this salt and the inputted password by the user to generate the hashedPassword. This is the password that will be stored in the database and not the user's real password. This is a security measure to prevent malicious parties from accessing passwords stored in a database.

One would then ask, how can we confirm a user's password if we don't have the raw password stored in the database? In our case, we will use bcrypt's handy compare() method. Let's see it in action in our userController.js file when we to log in a user.

const loginUser = asyncHandler(async (req, res) => {
    const { email, password } = req.body

    const user = await User.findOne({email})

    if(user && await bcrypt.compare(password, user.password)){
        res.status(201).json({
            _id:user.id,
            name:user.name,
            email:user.email,
            token:generateToken(user._id)
        })
    }else{
        res.status(400)
        throw new Error ('Invalid credentials')
    }
}

Above is the loginUser function which is called when the route /api/users/login is matched. We first obtain the email and password from destructuring the request body. We then use the Mongoose method findOne() to find the exact user with the specified email address. To verify the user, we compare the inputted password and the password in the database using bcrypt.compare(). It takes the keyed in password and the password in the database as arguments and if the passwords match it returns true.

If the user exists in the database and the password is verified, loginUser returns the user's details including a token that we can use to access some restricted content.

Let's see how we generate the token:

const generateToken = (id) => {
    return jwt.sign({id}, process.env.JWT_SECRET, {
        expiresIn:'30d'
    })
}

Our generateToken function takes in the user's id as an argument. We will then use jwt's sign() method to create and return the token. sign() takes in 3 arguments:

id: The id of the user logging in
secret: This is a private signing key that we store in our dotenv file. It confirms the origin of the token
expiring time: We can add an optional argument to specify when the token expires

We will now create our authentication middleware which will make sure that protected routes are accompanied with a valid token. This is how we implement authentication with jwt in express apps.

Authentication middleware

Some routes need to be accessed privately (as specified in the API definition) and the way we do so is by chaining some middleware to the route definition.

We will create our authentication middleware in our middleware directory in the file authMiddleware.js.

Let's take a look at our auth middleware:

const jwt = require('jsonwebtoken')
const asyncHandler = require('express-async-handler')
const User = require('../models/userModel')

const protect = asyncHandler(async(req, res, next) => {
    let token

    if(req.headers.authorization && req.headers.authorization.startsWith('Bearer')){
        try {
            //Get token from header
            token = req.headers.authorization.split(' ')[1]

            //Verify token
            const decoded = jwt.verify(token, process.env.JWT_SECRET)

            req.user = await User.findById(decoded.id).select('-password')

            next()
        } catch (error) {
            console.log(error)
            res.status(401)
            throw new Error ('Not authorized')
        }
    }
})

module.exports = {
    protect
}

The code above might seem like alot but it's actually quite simple. We are simply using javascript methods to get a token from the request header and verifying this token. We also set the error message if token doesn't exist or isnt valid ('Not authorized').

At the end we export our authentication function as protect.

How can we the utilize this protect function to protect some routes?

Let's have a look at our routes file now:

const express = require('express')
const router = express.Router()
const { registerUser, loginUser, getThisUser } = require('../controllers/userControllers')
const { protect } = require('../middleware/authMiddleware')

router.post('/', registerUser)
router.post('/login', loginUser)
router.get('/me', protect, getThisUser)

module.exports = router

The only route we need to protect is the api/users/me route
and we do so by including protect in the route definition as seen above. It's that easy!

Testing our authentication

Let's do a recap of what we have so far. We have defined several routes for a REST API that implements some login functionality. For one specific route that returns a specific user's info, we need to do some form of authentication to prevent unwanted access. To do so we implement some middleware and chain it to our route definition.

Now that we have added authentication to our project, lets test if it works

We will start by creating a new user called Daniel with the email address of daniel@yahoo.com and a password of 1234:

Note that a token is generated when we create a user.

Now let's login using the user details we have created:

To confirm our error handling works, lets use a wrong password and see the response generated:

We get the error message of "Invalid credentials" as desired

Let's now try accessing GET api/users/me without using our token:

We get an error message that we are not authorized to access that particular route

Let's try accessing the same route but this time pass in the correct token:

As you can see, we have no error messages and we get the content we want back from a protected route. Success!

Conclusion

In this article, we implemented authentication using jwt. In the next article we will deploy our express app to the internet using Railway. You can read that article here.

Setting up MongoDB and Mongoose for your project

mech2dev — Wed, 07 Dec 2022 05:29:28 +0000

Overview

In this tutorial, we will look at how to set up our project from my previous tutorial to use MongoDB.

In the previous article, we built a REST API that served data to our blog application. We build out endpoints to create, read, update and delete data. This data however is stored in an array in our blogController.js file.

This works when testing the application but all the changes made are temporary. If you create a new blog entry, this blog entry will remain visible but disappears when you restart the server.

We will now introduce a database to our project so as to persist our data. There are many different choices for a database depending on your applications needs.

For our application, we will use MongoDB with Mongoose.

MongoDB is a NoSQL document database used to build highly available and scalable applications.

Mongoose is an ODM (Object Data Modelling) library used to make it easier to connect to MongoDB by providing functions to manipulate the documents in collections.

DanielStai / netninja-react-backend

REST API for a React FrontEnd

This is an express rest api for a simple blog app that enables one to manage a simple blog.

You can view the client app here .

Endpoints

URL	METHOD	DESCRIPTION
api/blogs/	GET	fetches all blogs
api/blogs/{id}	GET	fetches a single blog
api/blogs/	POST	post a blog
api/blogs/{id}	DELETE	delete a single blog

View on GitHub

Project Structure

We have already built out the skeleton of this project in my previous article. As a recap, here's what we have so far.

We created a directory called server. In this server directory we have our server.js file which is our entry point to our API. We also have routes and controllers directories which hold the routes and the controllers (callback functions that are fired when these routes are matched) respectively.

That's the structure we have so far. Next we will do the database configuration.

Connecting to MongoDB

As described before, MongoDB is a document based database that allows us to build highly scalable applications. You can install MongoDB server locally but for our case, we will use MongoDB Atlas.

MongoDB Atlas is a fully-managed cloud database that handles all the complexity of deploying, managing, and healing your deployments on the cloud service provider of your choice (AWS , Azure, and GCP).

To get started, lets navigate to MongoDB homepage, create an account and login.

Click on "Create new organization" and give your organization a name. Let's call our organization tutorials and choose MongoDB Atlas as our preferred Cloud Service. Click on next and confirm organization creation on the next page.

Once the organization is created, we need to initialize a new project. Once you click on "create organization" you will be redirected to a projects page which is empty so far. Let's create a new project. Click on new project as below and name it dojo-blog-app. This is in line with the name of the blog app we are creating this database for. Confirm project creation on the subsequent pages.

With our project up and running, we now need to create a database. Indeed after confirming project creation, we are now redirected to a "Create database" page. Let's click on "Build Database" and create a database for our project.

We are now redirected to choose a hosting plan. We, for the purposes of this tutorial, will use the free shared plan.

We will now be required to do some configuration for our shared cluster. As a tip, most of the recommended settings here can do. The only change we will make is naming our cluster something memorable than cluster0. Lets call our cluster dojo-cluster. Click on "Create".

Next up is a few more settings to configure the security of our database and clusters. You'll be asked how you would like to authenticate your connection (username and password) and where you would like to connect from (local environment).

Create a username and password.

Select "My local environment" as where you want to connect from and also add your current IP address to the list of whitelisted IP addresses.

Click on finish and close and we are now done setting up our database. Under our created project, we can now see the cluster we have created (dojo-cluster).

With the clusters up and running, let's now focus on connecting our database to the rest of our REST API (no pun intended). Navigate to your cluster (like in the above screenshot) and click on "Connect".

There are several options to connect. Primarily, we want to get a connection string that will be domiciled in our dotenv file that will enable us to connect to our database.

Let's click on the second option which is "Connect your application to your cluster using MongoDB's native drivers". Here we can now get a string that we will copy and paste in our dotenv file in our application code.

Copy the connection string and save it somewhere as we will need it up next as we refactor our existing code to use our database.

Connecting MongoDB to our project

In my previous tutorial/article, we saw how we can set up a REST API for a simple blog app to give it some CRUD functionality without having a functional database.

We are now implementing the database in this phase of the project.

In the previous section, we created a MongoDB Atlas account and set up a cluster. In this section, we will now connect our app to the cluster.

Create a new directory inside the server directory and lets name it config. Inside config lets create a file called db.js and this is where we will write all our database connection code.

Copy and paste the code below into your db.js file.

const mongoose = require('mongoose')

const connectDB = async() => {
    try {
        const conn = await mongoose.connect(process.env.MONGO_URI)
        console.log(`Database connected ${conn.connection.host}`.cyan.underline)
    } catch (error) {
        console.log(error)
        process.exit(1)
    }
}

module.exports = {
    connectDB
}

We begin by importing mongoose into our project (do npm install mongoose if not installed yet). We will then create a function called connectDB. This is the function we will call when we want to connect to our database in our main server.js file. This is an asynchronous function since we are now working with a database.

In connectDB, we will use the Mongoose method mongoose.connect to connect to our cluster. This method takes in a connection string as an argument.

Remember the connection string we copied and stored somewhere safe? We will now create an environment variable MONGO_URI and give it the value of the stored string as seen below.

NB: Remember to replace password with the actual password to the cluster that you created.

We then log a statement to our console to show that our connection is successful. The cyan.underline appended to the console.log() statement changes the color of the logged statement to cyan and is a feature of the colors package (do npm install colors if not installed yet).

The catch part of our try catch statement simply logs an error if any and exits the process. Lastly, we do a module.exports statement so as to export the function connectDB to be used elsewhere, in this case the server.js file.

Creating models

Now that we have the connection to the database up and running, let us create models for our database. We will first define the structure of our database using a schema.

Generally speaking, a schema is a structured framework or an outline. A database schema therefore defines how data is organized within a database including logical constraints such as, collection names, fields, data types, and the relationships between these entities.

Create a new directory named models where we will store our various data models. For our blog app, create a new file in the models directory called blogModel.js.

At the moment we are only concerned with a simple blog app but later we may need to add more functionality such as users etc and thus we may need to create new models. These models will be created in separate files eg userModel.js. Keeping each model separate is a good practice that ensures modularization of our code.

Let's have a look at blogModel.js.

const mongoose = require('mongoose')

const blogSchema = mongoose.Schema({
    title:{
        type:String,
        required:[true, 'Please add a title']
    },
    body:{
        type:String,
        required:[true, 'Please add a story']
    },
    author:{
        type:String,
        required:[true, 'Please add an author name']
    }
},{
    timestamps:true,
})

module.exports = mongoose.model('Blog', blogSchema)

As usual, we start by importing Mongoose. Each schema maps to a MongoDB collection and defines the shape of the documents within that collection.

To create our database schema, we will use the very handy Mongoose.schema() method to define blogSchema. Our blog entries have 3 fields i.e. title, author, and the blog body. MongoDB adds a unique ID field for us so we wont add that in our schema definition.

Read more about mongoose and schemas here.

After defining our fields and the data types in the schema, we can add another argument to our Mongoose.schema() method that adds timestamps for when we create or update posts.

As always, don't forget to export the model so that we can use it in our controller functions. We will use the mongoose.model() method. The mongoose.model() function of the mongoose module is used to create a collection of a particular database of MongoDB.

Creating controllers

Now that we have a single function we can fire up to connect to the database, let us re-purpose our controller functions to read, write or delete data from our database and not the array we were using before.

Let's see how our controllers/blogControllers.js file will now look like and then we will discuss the code below.

const asyncHandler = require('express-async-handler')
const Blog = require('../models/blogModel')


// @desc Get all blogs
// @route /api/blogs/
// @access public
const getBlogs = asyncHandler(async(req, res) => {
    const blogs = await Blog.find()
    res.json(blogs)
})


// @desc Get single blog
// @route /api/blogs/{id}
// @access public
const getBlog = asyncHandler(async(req, res) => {

    const blog = await Blog.findById(req.params.id)

    if(!blog){
        res.status(400)
        throw new Error('Blog not found')
    }

    res.json(blog)

})


// @desc Post a blog
// @route /api/blogs/{id}
// @access public
const postBlog = asyncHandler(async(req, res) => {

    if (!req.body.title || !req.body.body || !req.body.author){
        res.status(400)
        throw new Error ('Please fill all the required fields')

    } else{
        const blog = await Blog.create({
            title: req.body.title,
            body: req.body.body,
            author: req.body.author
        })

        res.status(200).json(blog)
    }
})


// @desc Delete a blog
// @route /api/blogs/{id}
// @access public
const deleteBlog = asyncHandler(async(req, res) => {

    const blog = await Blog.findById(req.params.id)
    if(!blog){
        res.status(400)
        throw new Error('Blog not found')
    }

    await blog.remove()

    res.status(200).json({message:"blog deleted"})
})


module.exports = {
    getBlogs,
    getBlog,
    postBlog,
    deleteBlog
}

We have 4 controller functions which are fired up when specific routes are matched. Our API has the following endpoints:

URL	METHOD	DESCRIPTION
api/blogs/	GET	fetches all blogs
api/blogs/{id}	GET	fetches a single blog
api/blogs/	POST	posts a new blog
api/blogs/{id}	DELETE	deletes a single blog

In blogController.js, we start by importing asyncHandler. asyncHandler wraps async functions and saves you writing your own try/catch for async/await and passes errors on to next.

We will also import the Blog model we created in our models directory

To get all blogs, we have:

const getBlogs = asyncHandler(async(req, res) => {
    const blogs = await Blog.find()
    res.json(blogs)
})

Using the Blog model, we will use the find() method provided by mongoose. find() returns all records found. Sometimes you may need to return a particular record by id etc and there are methods to do that. Read more about mongoose queries here.

To get a specific blog, we have the following code:

const getBlog = asyncHandler(async(req, res) => {

    const blog = await Blog.findById(req.params.id)

    if(!blog){
        res.status(400)
        throw new Error('Blog not found')
    }

    res.json(blog)
})

To return a specific blog post, we make use of the mongoose query findById(). We then check whether the blog with the requested id exists. We get the id from the request using req.params.id. If not we show an error message of 'Blog not found'. Otherwise we return the requested post.

To post a blog we have the following code:

const postBlog = asyncHandler(async(req, res) => {

    if (!req.body.title || !req.body.body || !req.body.author){
        res.status(400)
        throw new Error ('Please fill all the required fields')

    } else{
        const blog = await Blog.create({
            title: req.body.title,
            body: req.body.body,
            author: req.body.author
        })

        res.status(200).json(blog)
    }
})

We will use an if/else block to take care of empty entries. After checking that all fields have been filled, we then use the Model.create() method to create a new document in our collection. If successful, we return the created blog with a status code of 200.

To delete a blog, we have:

const deleteBlog = asyncHandler(async(req, res) => {

    const blog = await Blog.findById(req.params.id)
    if(!blog){
        res.status(400)
        throw new Error('Blog not found')
    }

    await blog.remove()

    res.status(200).json({message:"blog deleted"})
})

We target the post we want to delete using findById(). Once located, we use mongoose's remove() method to remove it.

Custom error handling middleware

One advantage of using Express.js is that it is unopinionated and allows us the flexibility to tackle challenges using custom solutions.

This is in contrast to opinionated frameworks (e.g. Django) which have set rules to tackle most problems.

To illustrate the unopinionated nature of express, we will build a custom error handler and chain it to all our requests as middleware.

In our root directory of server, lets create a middleware directory and inside it create the file errorHandler.js. In this file, we will implement some custom error handling. This will include the option to have verbose or abbreviated error messages depending on whether the app is in development or production mode.

Let's have a look at errorHandler.js and discuss it below:

const errorHandler = (err, req, res, next) => {

    const statusCode = (res.statusCode ? res.statusCode : 500)

    res.status(statusCode)

    res.json({
        message: err.message,
        stack: process.env.NODE_ENV === 'development' ? err.stack : 'null'
    })
}

module.exports = {
    errorHandler
}

We will define an error handler function which takes in 4 arguments (i.e. err, res, req and next).

In the callback, we check whether the response has a statusCode. If not we return a generic 500 (Internal server error). We then want to return an error message (from err.message) and a full description of the error (from err.stack) when process.env.NODE_ENV === 'development'. If we are in production, we want to see a more abbreviated description of the error (in this case null).

Testing the API

Congratulations. We have built a fully functional REST API complete with a supporting MongoDB database. In my previous article, we tested our API using Postman and all the endpoints worked as they should.

We shall follow a similar approach and retest our endpoints seeing as we have made significant changes to our API.

Lets fire up Postman and start by testing GET /api/blogs/:

As expected, we retrieve all blogs we have at the moment i.e. 2 blog posts.

Next we will use one of the blog id's we get from requesting all blogs above to test our endpoint that retrieves a single blog i.e. GET /api/blogs/{id}:

Voila. Both retrieving all blogs and retrieving a single blog work as expected.

I will leave the two remaining methods i.e. POST and DELETE for you the reader to test them out tell me what you get by leaving a comment.

Conclusion

That's the end of this particular article. We have come a long way from building dummy express apps to now building a fully functional rest api.

To build further on this, we will add some type of authentication to our app in the next article.

Till then, adios.

Setting up MongoDB

Connecting MongoDB to our project

Changing code to fit MongoDB (creating schemas etc)

Testing with Postman

How to build an Express REST API for a simple blog app

mech2dev — Wed, 23 Nov 2022 07:06:44 +0000

Introduction

In this article I will build a simple express server for the React tutorial by Net Ninja on YouTube. Here's a link to that tutorial. Here's how the front-end client we are building the API for looks like:

The front-end app enables one to view blogs, click on a blog to view a single blog, delete a single blog and post a new blog. The YouTube tutorial uses json server which is an important tool for front end developers to simulate calls to a REST API.

We will use this as the motivation to build and test a fully functional REST API with Express.js to serve this blog app.

The code for this tutorial can be found at the repo below.

DanielStai / netninja-react-backend

REST API for a React FrontEnd

This is an express rest api for a simple blog app that enables one to manage a simple blog.

You can view the client app here .

Endpoints

URL	METHOD	DESCRIPTION
api/blogs/	GET	fetches all blogs
api/blogs/{id}	GET	fetches a single blog
api/blogs/	POST	post a blog
api/blogs/{id}	DELETE	delete a single blog

View on GitHub

Endpoints

As described above, we are building an express api that will serve data to a simple front end blog app.

Users will be able to view all posts, view a single post, post a new blog and finally delete a blog post. Our task will therefore to build the endpoints that will actualize this functionality.

Let's discuss the endpoints we will build out:

URL	METHOD	DESCRIPTION
api/blogs/	GET	fetches all blogs
api/blogs/{id}	GET	fetches a single blog
api/blogs/	POST	posts a new blog
api/blogs/{id}	DELETE	deletes a single blog

Project setup

In my previous articles, we have built out all our API functionality in our server.js file.

For this tutorial, we will adopt some best practices and separate our routes and logic into separate folders. More on that later

Let's create a folder to host our project. I'll call mine server. Let's cd into the server folder. In the terminal, we will runnpm init -y to build a skeleton node project.

Lets create the js file that will hold all our API code and call it server.js. This will be the 'entry point' to our API.

While still in your project directory, lets run npm install express cors body-parser in the terminal.

This will install express, cors and body-parser, packages that will make our API development process smoother.

To read further on the same you can read an article I wrote about setting up a simple express server that explains how the above packages are used.

While we are at it, lets also install nodemon by running npm install -D nodemon.

Nodemon refreshes our server for us. Otherwise we would be forced to stop and start our server every time we make a change.

The -D flag ensures nodemon is installed as a dev dependency

In package.json, we will edit "main":"main.js" to "main":"server.js". Last but not least, under scripts we will add a new script to run nodemon as follows "dev":"nodemon server.js". Lets start writing our api code in server.js

As stated earlier, we will have our routes and logic in different folders. Lets create a 2 new directories in our server directory and name them routes and controllers

Defining Routes

We will start by importing express, cors and bodyparser and mounting all the required middleware. Here's what we have so far in server.js:

const express = require('express')
const cors = require('cors')
const bodyParser = require('body-parser')

const app = express()
const port = process.env.PORT || 4000

app.use(cors())
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended:false}))

For a simple API, we could in server.js define all the endpoints and the functions that are fired when a request is made to that endpoint, but for this tutorial, we will take a different approach.

Let's assume your API serves a huge front end application and many different endpoints for different features are needed. It would be very messy and difficult to maintain if all this functionality was in the server.js file

It's for this reason that we will create a blogRoutes.js file in our routes folder for all the routes in our blogs feature.

If, for instance, we added users to our app and needed to provide authentication etc, we would create a file for those routes in our routes folder and name it, say, userRoutes.js.

This will be our file structure:

Let's add the following line in server.js

app.use('/api/blogs', require('./routes/blogRoutes'))

This defines our base route as /api/blogs and also tells us that the various routes for our API are set in our /routes/blogRoutes path.

Now let's see what we have in blogRoutes.js file:

const express = require('express')
const router = express.Router()

const { getBlogs, postBlog, getBlog, deleteBlog} = require('../controllers/blogControllers')


router.get('/', getBlogs)
router.post('/', postBlog)
router.get('/:id', getBlog)
router.get('/:id', deleteBlog)

module.exports = router

We will import express and the router method to use in our blogRoutes file. We will also import some functions from ../controllers/blogControllers (which we haven't built out yet)

From our server.js file, we know that our base API route is /api/blogs.

Here in blogRoutes.js, we will define what happens when we access the endpoints api/blogs/ and /api/blogs/{id} with either GET, POST or DELETE requests.

Let's take a look at router.get('/', getBlogs). When the endpoint /api/blogs/ is accessed, it will fire a function getBlogs which retrieves all blog posts.

We can further clean up our code by condensing the four lines that define our routes as follows:

router.route('/').get(getBlogs).post(postBlog)
router.route('/:id').get(getBlog).delete(deleteBlog)

Up next we will have a look at blogControllers.js and see what the functions getBlogs, getBlog, postBlog and deleteBlog do.

Don't forget to module.exports = router as this line enables us to export the routes we have created to be used in our server.js file.

Defining controllers

Let's recap what we have so far.

In our server.js file, we added this line of code (app.use('/api/blogs', require('./routes/blogRoutes'))) that instructs our API to look in the folder ./routes/blogRoutes for the specific implementation of our endpoints.

In blogRoutes.js, we defined what happens when we hit various endpoints with various request methods.

We specifically looked at what happens when we get a GET request to /api/blogs/. We saw that a function called getBlogs (that has been imported from ../controllers/blogControllers) is fired and it returns all the blog posts in our data storage.

This is the same for all the other routes in blogRoutes.js

Recap done! Now let's have a look at the four functions we imported into blogRoutes.js namely getBlogs, getBlog, deleteBlog and postBlog. These are what we'll call our controller functions.

let blogs = [
    {
      title: "My First Blog",
      body: "Insert some text here",
      author: "mario",
      id: "1"
    },
    {
      title: "My Second Blog",
      body: "Insert some more text here",
      author: "yoshi",
      id: "2"
    }
  ]

// @desc Get all blogs
// @route /api/blogs/
// @access public
const getBlogs = (req, res) => {
    res.json(blogs)
}


// @desc Get single blog
// @route /api/blogs/{id}
// @access public
const getBlog = (req, res) => {
    const id = req.params.id 

    for (let blog of blogs){
        if (blog.id===id){
            res.json(blog)
            return
        }
    }
    res.status(404).send('Blog not found')
}


// @desc Post a blog
// @route /api/blogs/{id}
// @access public
const postBlog = (req, res) => {
    const blog = req.body
    blogs.push(blog)

    res.send('New post has been added')

}

// @desc Delete a blog
// @route /api/blogs/{id}
// @access public
const deleteBlog = (req, res) => {
    const id = req.params.id

    blogs = blogs.filter(i => {
        if (i.id !== id){
            return true
        }
        return false
    })

    res.send('Blog has been deleted')
}

module.exports = {
    getBlogs,
    getBlog,
    postBlog,
    deleteBlog
}

Pasted above is the entirety of our blogControllers.js file.

Let us discuss the code.

We start with creating an array called blogs which acts as our data storage for our blogs for now. This means our data is temporary. In a later tutorial we will implement a database which will help make our data persist.

We then define four functions i.e. getBlogs, getBlog, postBlog, deleteBlog. These functions hold the logic that makes our endpoints do exactly what we want them to do.

After defining these functions, we export them to blogRoutes.js file where we will combine the path, the request method and logic to return or receive the data we want

Let's take a look at getBlog for instance:

const getBlog = (req, res) => {
    const id = req.params.id 

    for (let blog of blogs){
        if (blog.id===id){
            res.json(blog)
            return
        }
    }
}

This function returns a single blog post which matches the id in the request.

As specified in blogRoutes.js, the function is fired when we get a GET request to the route defined as /blogs/:id.

The : indicates that the id variable can take any value. We then use req.params.id to retrieve the id from the incoming request and we store it in a variable id.

We will then check our blogs array for blog.id === id. Once we have it, we will send a response back in the form of a json object. If it doesn't exist, we will send back an error message indicating the same.

Have a look at the rest of the functions and try and figure out what each does.

Each controller function has a comment with a description, route and who can access that route.

Do not forget to export the functions created (using module.exports) so that we can be able to use them elsewhere in our app.

Testing the API

We now have all the 4 endpoints we set out to build from the start.

How can we tell if they work as we want them to?

One way is to integrate them with our frontend app (which has already been built out in this tutorial)and see if we get the desired results.

However, a better way to test your APIs as a backend developer is using Postman to test your endpoints.

Let's test two of our endpoints namely GET api/blogs/ and GET api/blogs/{id}

First you need to start your server if it wasn't running already with npm run dev. If you get errors in your terminal, you can always go through the tutorial again or check out the code in its GitHub repo.

Fire up Postman in your computer. If not yet installed, you can find instructions to do so here.

Open a new tab, choose GET as the method you want to use and in the query box alongside it, type in your API link in this case http://localhost:4000/api/blogs/. Click on send:

Both our objects in the blogs array are returned. Success!

Let's try returning the blog with the id of 1:

Again, success.

What happens if you try to access a blog that doesnt exist in our blogs array? Lets try fetching a blog with an id of 3:

We don't get a blog object back. As expected, we get a message back that the blog has not been found.

What about our post and delete endpoints? If you've followed along so far, please test them out and let me know in the comments section.

Conclusion

That's the end of our tutorial on how to build a REST API for a simple client. To take this to the next level, we will add a database so as to make our data persist in subsequent articles.

How to connect a React frontend to an Express server

mech2dev — Wed, 16 Nov 2022 12:08:35 +0000

Introduction

In this post we will create a skeleton react app and connect it to an express rest API.

This is intended to be an entry point for beginner frontend or backend devs who want a sneak peek into how they can build fullstack apps.

Without further ado, lets get right into it

Project setup

We will create a folder called fullstack which will host both our client and server apps. In your terminal or through your OS's GUI, create the following project structure

Lets set up the server side code first.

Server code

In your code editor of choice, cd into the server directory and run npm init -y.

This will initialize a node project for us and create a package.json file.

I have written a previous article on how to set up a basic express server and so we delve into the details of that. You can read that article here.

In your server dierctory, create a server.js file. Make sure you update your package.json file to reflect that the entry point to our server is server.js rather than the default index.js.

This is the code we have in our server.js file

import express from 'express'
import cors from 'cors'
import bodyParser from 'body-parser'

const app = express()
const PORT = process.env.PORT || 4000

app.use(cors())
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended:false}))

app.get('/api', (req, res) => {
    res.json({"names":["Daniel","Theodore","Jackson"]})
})

app.listen(PORT, () => {
    console.log(`Server running on localhost: ${PORT}`)
})

As per the above code block, you need express, cors, bodyparser and nodemon installed. All the details you'll need to get your simple express server up and running can be found here.

Let's look at one code bock though:

app.get('/api', (req, res) => {
    res.json({"names":["Daniel","Theodore","Jackson"]})
})

In the above code snippet from our server.js file, we are setting the route /api.

When the client app sends a GET request to that route, the response will be a json object names which is an array of names as seen above.

Browser code

We will now create a react front end that will connect to our express server and display our names object to the screen.

cd into our client directory and run the command npx create-react-app .

This will create a react app in the current directory in this case the client directory.

To start the development version of your react app in the browser, run npm start in the terminal

Lets go ahead and get rid of the contents of App.css as we wont be needing them. In App.js, lets also just remain with a boilerplate component as seen below

We will start by using the useState hook to define backendData and setBackendData.

We will then use the useEffect hook to pull in the data using Fetch API.

You can read more about react hooks here

Finally, we will define how we want our data rendered our browser. We do this inside the div tag in the return statement in App.js.

We've done so much but this is the entirety of our App.js file in our client/src directory so far

import React, {useEffect, useState} from 'react'

const App = () => {

  const[backendData, setBackendData] = useState([{}])

  useEffect(() => {
    fetch("http://localhost:4000/api").then(
      response => response.json()
    ).then(
      data=> {
        setBackendData(data)
      }
    )
  },[])


  return (
    <div>
      {(typeof backendData.names === 'undefined') ? (
        <p>Loading...</p>
      ):(
        backendData.names.map((name, i)=>(
          <p key={i}>{name}</p>
        ))
      )}
    </div>
  )
}

export default App

Save your App.js file and navigate to http://localhost:3000if not already open

Let's check our react app in the browser and see if we have managed to display our names list.

Voila!

We have managed to build a skeleton react app and a simple express server and integrated them.

To confirm that the fetch request we are making in our useEffect hook works, lets check out the network tab in our browser.

Success!

The fetch request is successful and returns a json object which is displayed on the browser.

Conclusion

The concepts discussed above are basic react and express concepts that can be built upon to create powerful apps that use Javascript for the whole stack.

To further build on the knowledge learnt here, we will create a React frontend for the express REST API we created in this article in my next article.

Till then, adios muchachos

Node + Express Basics Part III: Testing a RESTful API with Postman

mech2dev — Tue, 01 Nov 2022 14:21:02 +0000

Introduction

In Part II of our "REST API with Express" series, we built a simple REST API with Express.js.

In this article we will finish the API development process by testing if our API works as desired using Postman

Postman is an API platform for developers to design, build, test and iterate their APIs.

Go ahead an install Postman as per your operating system requirements. You can get instructions on how to do so here

For Linux users, we will install through the snappy packaging system by running the following in the terminal:

sudo snap install postman

Postman will be installed as a desktop app built with Electron for all operating systems.

Finish setting up your account and open the desktop app

You can check out the code we will be testing here on my github.

We will test the five endpoints we made in the previous article

1. Getting all notes

As you may recall from the previous article, we built an endpoint to fetch all the notes from our array (acting as our data storage at this point).

Lets see whether it serves up the three notes we saved in our notes array.

Get the server up and running by navigating to our project folder that contains note-api.js and run npm run dev.

You should see the following in your terminal:

Fire up Postman and open up a new tab.

Select GET as the method you want to test. In the entry box alongside, type the URL to your API which in this case is http://localhost:4000/notes.

This is what we have so far:

When we click on send, we will get the following response:

Which works as expected by returning all notes in our array as a JSON object.

2. Getting an individual note

The process is similar to the process of retrieving all notes.

Lets try to get back the note with a noteid of 1.

Type in http:localhost:4000/note/1 as the URL we want to send our request to and GET as the HTTP method.

Click on send and this is the response we get:

What happens if we try to get a note with an id that doesn't exist?

Go ahead and replace the previous query with http:localhost:4000/note/4.

Note that in our notes array, no note exists with a noteid of 4. This is the response we get which is in line with our API logic:

Fantastic!!

3. Creating a note

In our API we defined an endpoint for us to create a new note. Lets see if this POST method works correctly.

In the same postman tab, navigate from GET to POST using the drop-down menu. On the panel just below, move your selection from 'Params' to 'Body'. Also click on 'raw' and input type as JSON. In the entry box below, lets make a new entry with id = 4.

That's a lot to take in but this is what we have so far:

When we click on 'Send', we have succesfully created a new note. To confirm this, lets GET all notes and see if our note has been created:

Voila! We now have 4 notes from our previous 3 notes.

You can also confirm by invoking the GET method on our endpoint and see whether you get a response back with our newly created note

4. Editing a note

Editing a note is almost the same as posting a new note. We will simply use the POST method and specify the current noteid of our note as the same as edited noteid.

Not making much sense?

Lets see what all the above looks like:

We are editing the note with id = 1.

To confirm the edits have been done after clicking send, lets GET the note with noteid = 1:

Edit done!

5. Deleting a note

So far we have created a note and saved it in our notes array, retrieved all notes, retrieved an individual note and edited a specific note.

We will finish our tests by testing our deletion endpoint that we created in note-api.js.

As per our API, we simply need to specify the HTTP method as DELETE and then specify the noteid of the note we want to delete.

Lets see all that in action below:

When we click 'send', our note is deleted and we get a response back from the server that 'note has deleted'.

To confirm our data has been deleted, lets GET the note with id = 1 and see if it has been deleted.

The note has been successfully deleted as expected

Conclusion

By the end of Part III of our three part series of articles, we have created a basic HTTP server with express, extended it to a REST API and finally tested it with Postman.

Congratulations to us! In our next series (Node + Express Intermediate), we will dive deeper into middleware and take advantage of middleware to build better REST and GraphQL APIs.

Node + Express Basics Part II: Building a RESTful API

mech2dev — Tue, 01 Nov 2022 14:20:43 +0000

This article is Part II in our ongoing three Part series: Node + Express Basics.

In Part I, we built a basic HTTP server and defined what middleware is, which is how express manages to abstract out all the details of dealing with requests and responses.

In this article we will define what REST APIs are and what they do.

We will then go ahead to extend our basic server from Part I into a fully fledged REST API.

What is a REST API?

According to this article by Amazon, REST stands for Representational State Transfer and defines a set of functions like GET, PUT, DELETE, etc. that clients can use to access server data. Clients and servers exchange data using HTTP.

The main feature of REST API is statelessness. Statelessness means that servers do not save client data between requests.

Client requests to the server are similar to URLs you type in your browser to visit a website.

The response from the server is plain data, without the typical graphical rendering of a web page.

1. Project set up

What are we building?

We will build a REST API that'll serve a front end notebook application. We will build our REST API with end points that correspond to the HTTP methods of GET, POST, PUT/PATCH and DELETE.

We will do that by extending the basic express HTTP server we made in the previous example.

We will then test our API using Postman in Part III.

This is the code we have so far from the previous article. For this tutorial, create a new file and lets name it note-api.js and paste the following starter code.

import express from 'express'
import cors from 'cors'
import bodyParser from 'body-parser'

const app = express()
const port = process.env.PORT || 4000

app.use(cors())
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended:false}))

In setting up our project in Part I, we installed express and cors.

We will now install some more middleware and in this case we will install the middleware bodyParser. As the name suggests, we will be using this middleware to get information from the request body of our API calls.

To install bodyparser, go ahead and run the following in our project folder in the terminal

npm install bodyparser

The last three lines of the example code above illustrate how to load our middleware.

In general, we use app.use(<middleware function>) when mounting middleware at root level i.e. to be used on all requests.

If we wanted to say for example mount middleware for post requests only, we would use app.post(<middleware function>)

Now that our app is correctly set up, lets go ahead an start building our API.

2. Defining data storage

For our API, we will make use of temporary data stored in an array. Take note of the temporary nature of the data. This means that any changes or modification done to our array will cease to exist once we restart our server.

Here's a sample of one entry in our array:

{
    noteid: '1',
    title: 'First Note',
    author: 'Daniel Stai',
    content: 'This is my very first note ever',
    date_created: '2022/10/28'
  }

We can see the various fields one note entry has. Lets go ahead and create an empty array called notes and add 3 sample notes to work with.

let notes = [{
    noteid: '1',
    title: 'First Note',
    author: 'Daniel Stai',
    content: 'This is my very first note ever',
    date_created: '2022/10/28'
  },
  {
    noteid: '2',
    title: 'Second Note',
    author: 'Jack Sparrow',
    content: 'This is my second note',
    date_created: '2022/10/28'
  },
  {
    noteid: '3',
    title: 'Third Note',
    author: 'Aegon Targaryen',
    content: 'This is my second note',
    date_created: '2022/10/28'

  }

In subsequent articles, we will make our data persist by using a database such as MongoDB and also generate unique ids to our entries for ease of access.

2. Getting all the notes

Now that we have some sample data to work with, lets go ahead and add a few endpoints to our API.

As we saw in our REST API definition, the requests made by the client to the server (the endpoints) are similar to the URLs we normally type in a browser.

Our server is currently running on port 4000 so what happens when one sends a GET request to http:localhost:4000/notes?

Ideally we want them to get back a list of all the notes currently in our array. Lets go ahead and write that route.

Express routes are of the form app.METHOD(PATH, HANDLER).

METHOD is the corresponding HTTP method in lowercase, PATH is the relative path in our server and HANDLER is the function that Express will call once our route is matched.

In our case to retrieve all notes we have:

app.get('/notes', (req, res) => {
    res.json(notes);
});

And to retrieve a single note, we have:

app.get('/note/:noteid', (req, res)=>{
    const noteid = req.params.noteid

    for (let note of notes){
        if (note.noteid === noteid){
            res.json(note)
            return
        }
    }
    res.status(404).send('Note not found')
})

In the code block above, when for example we get a get request from say http://localhost:4000/note/1, we extract the note id usingreq.params.id.

This enables us to use this id value in the request body to check whether there is a corresponding match in our array notes.

If such a match exists, we return that particular note. If it doesn't exist, we return a 404 error with the custom message that 'Note not found'.

3. Creating a new note

To create a new note, lets create a skeleton html file that we will use to add data to our notes array. Create a new file called new-note.html and paste the following code

<div class="container">
    <hr>
    <h1>Create New Note</h1>
    <hr>

    <form action="http://localhost:4000/note" method="POST">
        <div class="form-group">
            <label for="noteid">Note ID</label>
            <input class="form-control" name="noteid">
        </div>

        <div class="form-group">
            <label for="Title">Title</label>
            <input class="form-control" name="title">
        </div>

        <div class="form-group">
            <label for="Author">Author</label>
            <input class="form-control" name="author">
        </div>

        <div class="form-group">
            <label for="Content">Content</label>
            <input class="form-control" name="content">
        </div>

        <button type="submit" class="btn btn-primary">Submit</button>
    </form>
</div>

I wont go to the details of the html code but if you run the live preview on vscode or go to http://localhost:3000/new-note.html on your browser, you'll see our form that we'll use to post a new note entry.

Back in our note-api.js file, lets deal with the logic of making this happen. Following the same structure for our get requests, lets write our post request

app.post('/note', (req, res)=>{
    const note = req.body

    console.log(note)
    notes.push(note)
    res.send('Note added to notebook')
})

We will assign the request body i.e. req.body to a variable note and then push this new note to our already existing notes array using notes.push(note).

We also log the new note that has been created to the console. This might help when debugging potential issues.

When that is successful, we will send back a response i.e. 'Note added to notebook'.

With your server running, go ahead and fill our form. We will get the following if successful:

4. Editing a note

Once you have created a note, you might need to edit the contents of the note. Let's add that logic to our API.

app.post('/note/:noteid', (req, res)=>{
    const noteid = req.params.noteid
    const newNote = req.body

    for(let i=0; i<notes.length; i++){
        let note = notes[i]
        if (note.isbn === isbn){
            notes[i] = newNote
        }
    }
    res.send('Note has been edited')

})

We will assign the variables noteid and newNote to the note id and request body respectively.

We will then loop through our notes and check if there exists a note with a matching id to the note we want to edit. If it exists, we replace its contents with newNote.

We also send back a response of 'Note has been edited'.

5. Deleting a note

So far we've dealt with creating a new note, retrieving an individual note, retrieving all notes and editing an existing note.

The last part of the logic of our API will deal with deleting a note from our data storage.

app.delete('/note/:noteid', (req, res)=>{
    const noteid = req.params.noteid

    notes = notes.filter(i =>{
        if (i.noteid != noteid){
            return true
        } 
        return false
    })
    res.send('Note has been deleted')
})

With deletion, we need to be careful so as not to inadvertently delete all records in our data store.

To do so, we will filter our notes array looking for a record with a note id equivalent to the note id in the request.

Once found, that record is filtered out, returning the filtered array without the desired record.

Conclusion

And with that we have a fully functional RESTful API. How do we know it does what it says it does? In Part III, we will test our API using Postman. You can go ahead and read the article here.

Node + Express Basics Part I: Building a basic HTTP server

mech2dev — Tue, 25 Oct 2022 03:42:22 +0000

This article is Part I of a three part series in which we will use node + express to learn how to build a RESTful API and test it with Postman.

In Part I we will have a look at how to set up a basic HTTP server with Node and Express

Introduction

We can define a HTTP server as software that understands URLs (web addresses) and HTTP (the protocol your browser uses to view web pages).

A HTTP server can be accessed through the domain names of the websites it stores, and it delivers the content of these hosted websites to the end user's device.

Node is a JavaScript runtime environment that helps us run JavaScript outside the browser. Express is a Node.js framework that makes it easier for us to develop APIs with node, which by itself isn't as friendly for development

You can find the code for this on my Github. Make sure you follow me there too :)

1. Setting up the project

Before we begin, you will need to install Node.js on your system and set up a local development environment.

To do this, you can follow along this tutorial which describes how to install Node.js for different operating systems.

Once you've installed node (and npm by extension), create a directory for the project and cd into it. I'll call my directory node_example

mkdir node_example && cd node_example

Once in our projects directory, we will first run

npm init

to create a package.json file.

We can now go ahead to install the required dependencies. In the terminal, go ahead and run

npm install express cors

This will install Express for us and also install the middleware CORS.

CORS stands for cross origin resource sharing. The CORS package we are installing provides an Express middleware that enables CORS with different options so we can make the right connections on the network.

While we are at it, lets also install nodemon as a dev dependency.

Why nodemon?

Every time you make changes to your files, we will need to restart the server for those changes to take effect.

Nodemon takes care of that for us, saving us from the cumbersome task of always starting and restarting the server. Go ahead and run the following in the terminal

npm install -D nodemon

This will install nodemon as a dev dependency.

Dev dependencies are packages that are installed to aid in the development process hence not needed in the production environment

Now we need to edit the package.json file so as to ensure npm start starts the server. We will do this by adding "start":"node index.js" to the scripts as shown below. Note that we will be creating our server in index.js.

"main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "nodemon index.js",
    "start":"node index.js"
  },

We have also created a script named dev that runs nodemon index.js

To use import statements in index.js instead of the usual 'require', we add a type of module to our package.json file.

},
  "type":"module"
}

2. Writing our server code

We are now all set to start writing code to create our server

import express from 'express'
import  cors from 'cors'

const app = express()
const port = 4000

In the code block above, we will import express and cors using the import statement.

We can import like this since we added "type":"module" to our package.json file.

We then create an express application by invoking express() and designate a port number in our port variable.

We will hard code our port number now but in subsequent examples we will point the port variable to an environment variable in the .env file like so:

const port = process.env.VARIABLE_NAME || 4000

This will tell our application to assign the variable name port to an environment variable VARIABLE_NAME stored in our .env file and default to 4000 if no such environment variable exists in the .env

3.Configuring middleware

In the next code block, we will configure some middleware.

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

We will not take a deep dive into middleware for now but we will define middleware as functions that execute some code that can have side effects on the app, and usually add information to the request or response objects.

The syntax used to load middleware is:

app.use(<middleware_function>)

This mounts the middleware at root level.

There are other ways to mount the middleware to specific routes or to a specific type of request but those are beyond the scope of this article.

4. Defining app routes

We will now define our app routes and specifically what gets sent with a get request to the root of our app ('/').

app.get('/', (request, response)=>{
    response.send('Hello World')
})

app.listen(port, ()=>{
    console.log(`Server is running on port ${port}`)
})

Express routes can be expressed (pun intended) as app.METHOD(PATH, HANDLER).

METHOD is our http method in lowercase, PATH is our relative path on the server and HANDLER is the function that express calls when the route is matched.

We then use app.listen() to define the port that our API server should be listening on

5. Running the server

And that's it. We have written all the code we need to create a basic http server.

To run our server, type npm run dev in your terminal. If you followed all steps correctly, you should see Server is running on port 4000 in your terminal.

On your browser, visit http://localhost:4000 and you'll see 'Hello World' logged on the screen

In the next article we will define REST APIs and extend this example to a fully fledged REST API. You can read the article here

Getting Started with the Command Line Part 2: Pipes and Redirection

mech2dev — Thu, 13 Oct 2022 15:30:24 +0000

This article is part of a series of articles aimed at getting you, the complete beginner at using the command line, from zero to hero.

This article is a follow up to Command Line basics Part 1: Intro to the Command Line which you can read here

The whole series is based on Meta's Backend developer course (Version Control) on Coursera. You can have a look at the course here

At the end of this article you'll be able to:

Define what a pipe is and how to use it to be more effective on the terminal
Define what redirection is and a use redirection on standard input, standard output and standard error

Pipes

In the previous article, we went through a few basics commands such as cd, ls, pwd and mkdir among others.

We also saw a very simple example of a typical workflow using the command line.

In this article we will take it a little further by discussing pipes.

We use pipes to take the output from one command as the input to another.

The pipe symbol is |. We will use the steps below to illustrate its use.

Step 1. Create sample files to use

We will first create the files we will work on and add some dummy 'lorem ipsum' text to help illustrate our point. This work flow can be seen in the screen grab below

We have created two files i.e. example1.txt and example2.txt. The command cat example1.txt and cat exampe2.txt simple shows us the content of the text file

Step 2. Using a pipe to open the text file and count the words in the file

We will now use a pipe (|) to open the text files and count the words in the file.

We can simply run the command wc cat example1.txt -w and similarly for example2.txt. The -w flag tells the command to return the word count for the example1.txt file.

Say we want the combined word count of example1.txt and example2.txt?

This is where pipes come in. We will run the command cat example1.txt example2.txt | wc -w

All the above steps can be seen in the screen grab below

We have successfully used a pipe to take the output of one command (cat example1.txt example2.txt) as the input of the next command (wc -w)

Lets take a look at redirection now

Redirection

As you may have already noticed, the standard workflow of any linux command is that it takes an input and gives some sort of output or error message.

In most cases, the standard input device is the keyboard while the standard output device is the screen/monitor.

Using redirection, we can change where the standard input comes from or where output and errors go.

We will take a look at the three io (input/output) redirections available i.e. standard input redirection, standard output redirection and error redirection

1. Standard input redirection

The standard input redirection gives you the option to record your input and save it to a file either by overwriting or appending the file.

Lets see this using the example in the image below. We will continue working in the 'tutorial' folder we created in the previous section when discussing pipes.

First we check the existing contents of the 'tutorial' folder by running the already familiar ls tag. We can see our two files from earlier

For user input, the symbol < is used. But first, type the command cat > input.txt. This will create the file 'input.txt' and assign whatever text you type in the console to it. Press CTRL + D to exit the input prompt

Now lets check the contents of the 'tutorial' folder. You can see a new file 'input.txt' has been created. To see the content of the file, we can type in the command cat < input.txt. This will display the text in 'input.txt' that we had typed in earlier.

The above workflow can be seen below:

2. Standard Output redirection

The redirection of standard output allows you to control where output goes.

When you run a simple command like ls -l, the output is normally some text that we can see on the terminal.

We could choose to store this information in a text file for whatever reason.

We will simply run the command ls -l > output.txt.

This will take the output from the ls -l command, create a file called 'output.txt' and write the output there.

Running the ls command we can confirm that indeed the file 'output.txt' has been created. To view the contents of the file, we run the command less output.txt in the terminal.

This is what we get:

As we can see, our 'output.txt' file contains the same message we saw on our terminal when we ran ls -l. Redirection successful!

3. Standard error redirection

The standard error redirect allows you to specify that the error should be written to a file.

As in previous example, lets do it using a real example

Still in the 'tutorial' directory, lets try to open a file/directory that we know obviously doesn't exist there. We are trying to simulate an error message.

We run the command ls -l /bin/usr

We will get the error message that the file/directory doesn't exist.

Our goal is to redirect and write this error message to a text file thus we run the command ls -l /bin/usr 2> error.txt.

The 2> is the symbol used to redirect error output.

Check the contents of the folder to confirm that indeed the file 'error.txt' has been created. To see its contents, run less error.txt

There are instances where you are not sure whether you will get actual output from the command or an error.

That's where 2>&1 comes in. Run the command ls -l /bin/usr > error_output.txt 2>&1.

This will create and write the output or error to the file 'error_output.txt'.

This brings us to the end of this article on using pipes and redirection with Unix commands.

I hope you've learnt something new or brushed up on some knowledge.

In part 3 of our Command Line Basics series we will take a look at Grep (Global regular expression print).

The standard input redirection gives you the option to record your input and save it to a file either by overwriting or appending the file

The standard error redirect allows you to specify that the error should be written to a file.

How I Contributed to my first Open Source project

mech2dev — Sat, 01 Oct 2022 23:21:31 +0000

Many aspiring developers wish to start contributing to open source but they lack a starting point.

Why is contributing to open source important?

Contributing to open source is a way to practice your coding skills as well as a chance to work on real life problems and colalborate with others

In this article, we will go through the steps one can take to contribute to a simple first project.

Some knowledge of Git and GitHub is required.

You can get a refresher by reading my article on Git basics here.

1. Look for a good first issue

For our first issue, we will use the first contributions GitHub repository that is specifically built for beginners to practice contributing to open source.

2. Fork the repository

Click on the fork repository button in the screen below.

This will create a copy of the repository in your GitHub account that you can then work with

3. Clone the repository to your local computer

To have a local copy of the first-contributions repo, run the command git clone https://github.com/firstcontributions/first-contributions.git in the appropriate local folder.

You can copy the link to the repository when when you click on 'code' then 'Copy' on the screen below

4. Create a branch

We now have a copy of the code in our local computer.

Navigate to that directory so that we can make the necessary modifications.

We will create a branch from our master branch so that we can work on changes to our code. It is this branch that will push to GitHub, create a pull request and hope its merged to the main branch.

Let's call our branch 'add_my_name'

To create the branch and check it out at the same time, we run the command git checkout -b add_my_name.

This will create the branch and set it as our current working branch.

5. Make the required changes

For this repository, the extent of changes we can make is editing the 'Contributors.md' file to insert our name.

Open the Contributors.md file and add your name to the file and save it.

Remember we are working on the branch add_my_name. Time to submit our changes

6. Push local changes to GitHub

Run the command git push -u add_my_name. This will sync our local and remote repositories

7. Create pull request

Go to your GitHub page and if you've done everything right, you should see a page with a 'Compare Pull request' button like below. Click it

Click on the 'Create pull request' button as below

A pull request is a notification to the owners of the code that you've made some changes to their code and you'd like them to merge them into their projects

At this point you'll see the following page

And its at this stage where you'll celebrate having done your first contribution to an open source project. Congratulations!!

The purpose of this simple project is to expose you to the tools and the typical workflow of a simple open source contribution.

In subsequent articles, we will get more familiar with the fork-clone-Edit-PR cycle that is typical in any open source contribution workflow.

Adios.

Getting Started with Git and GitHub Part 1: Intro to Git and GitHub

mech2dev — Fri, 30 Sep 2022 09:14:26 +0000

This article is part of articles targeted at getting you, the complete beginner at using the command line and git for version control, from zero to hero.

At the end of this article you'll be able to:

outline the git principles
use a GitHub repository
describe the steps in a standard GitHub workflow
create branches and merge different branches
describe how code goes from local development to version control and then to live production

This article is based on Meta's Back-end Developer Certificate Course 3: Version Control. You can find a link to the course here and a link to my article on Meta Back-end developer Course 1: Introduction to Back-end Development here.

Often many beginners get stuck when starting using git and github due to a failure to properly understand git and failing to appreciate the immense power of git and its usefulness to the software collaboration and development cycle.

This article will give a brief but concise introduction to git for beginners to enable them to jump right away and start collaborating and building repositories for their portfolios.

These will the main objectives of this article:

What are Version Control systems and how are they implemented?
Learn how to navigate and configure version control systems using the command line.
Learn how to manage code revisions.
Create and use a GitHub repository.

Git Principles

In their most basic form, version control systems are borne out of a need to have teams collaborate and work on the same codebase.

We can define version control more formally as the practice of tracking and managing changes to software.

Version control systems enable developers to backtrack to previous versions of code if need be.

This is important given that multiple team members might be working on the same source code and without version control, you cannot tell who made what changes and when.

A more catastrophic result is having no way to backtrack to a previous version of software when a change to the existing code introduces bugs or crashes the code altogether.

Benefits of version control:

Long term history of changes
Branching and merging
Traceability

We'll now go through a basic git workflow that will illustrate most of the basics that will get you started with git and GitHub

0.Install git and create a free GitHub account

Install git according to your operating system here and create your free GitHub account here.

Git is a version control system while GitHub is provides an internet hosting service and a user interface to manage and store our git repositories

1.Create a local git repository

Navigate to the folder you want to initialize your git repository. Run the command git init

2.Creating files

In the same folder where you've initialized git, let's create a file and see how git tracks files. Run the command touch example.txt

You can review how to create files among other simple command line commands from my earlier article here.

3.Adding files to the staging environment

You've created a new file but you need to 'add' it to the staging area for git to start tracking changes made to the file. Run the command git add example.txt

4.Create a commit

With a new file already added, we'll now need to commit it thereby saving any changes we'd made on the file.

Commits are accompanied by a commit message to show what changes have been made and to make it easier to review changes made to a file or project.

Run the command git commit -m 'Initial commit'. Here, "initial commit" is the commit message

5.Create a new branch

When you create a repository on git, the branch you work on by default is the main branch, aptly named 'main' or 'master' (to be deprecated soon).

To work on different features and bugs etc, you create new branches on which you can make changes that can be merged back to the main branch after a pull request. More on pull requests later

First, you can check which branch you are currently on by typing the command git status. Then you can use the command git checkout -b feature. This creates a branch named 'feature' and sets it as the current branch to be worked on

6.Create a new repository on Github

We already covered how to create a Github account earlier. Creating a Github repository is quite easy as seen below

GitHub will ask if you want to create a new repo from scratch or push an existing repo. Since we've already created our repo, we'll choose the latter by typing git remote add origin 'link to repo' Replace 'link to repo' with a link to your repository

7.Push your branch to GitHub

Earlier, we created a local git repository, added and committed a file, created a new branch to work on, created a remote GitHub repository.

Now we would like to push our local branch to GitHub by running git push -u origin feature. Go to GitHub and you'll see the new branch appear as shown below

8.Create a pull request

Navigating to the page shown below, click on the create pull request button.

A pull request is a way to notify the code owner (in this case you are the code owner) that you want to make changes in the code. Here, the owner reviews the code and if satisfied, merges the changes to the main branch.

If you are the owner or co-owner of a repository, you may not need to create pull requests to make changes as well as creating branches when working on a feature but its good practice so as to keep a record of changes made.

9.Merge your changes

Click on merge pull request and confirm merge.

Your changes will be merged to the main branch. You can delete the branch that you merged seeing as you no longer need it.

This also helps to make your work neater as too many branches can become messy.

10.Pull the changes to your local computer

If you can recall our workflow so far, we:

initialized a git repository locally
added files and committed them
created a new branch to work on
created a GitHub repository and added it as a remote connection to our local repository
pushed the new branch to the remote repository
created a pull request and merged the pull request.

It's then evident that our local repository is not the same as our remote and therefore to synchronize the changes made, in our terminal we run git pull origin master. We can now git status (to check which branch we are on to make sure we are on the main branch) then git logto see all changes made

In our next article, we will look into more advanced concepts such as going into the details of how git tracks changes to files.

Adios

Getting Started with the Command Line Part 1: Intro to the Command Line

mech2dev — Fri, 30 Sep 2022 04:24:15 +0000

This article is part of a series of articles aimed at getting you, the complete beginner at using the command line, from zero to hero.

At the end of this article you'll be able to:

define what the command line is
advantages of using the command line
various uses of the command line for both basic and advanced users
getting started with basic commands

This article is based on Meta's Back-end Developer Certificate Course 3: Version Control. You can find a link to the course here and a link to my article on Course 1: Introduction to Back-end Development here.

We interact with computers with a daily basis to perform various tasks e.g. editing word documents, listen to music, watch videos, create files etc. At the heart of all these interactions is a process of the computer accepting data and giving some output.

There are various ways we interact with the computer with the most popular one being through the use of graphical user interfaces (GUI).

These are very popular since they are easy to use with little or no training but the have their own limitations including being slow and limiting full interaction with the computer.

Another way to interact with the computer is the command line. Using the command line is faster, less prone to errors and offers a lot of flexibility.

With the command line, we can perform some basic tasks like:

creating directories
creating files
combining directories
copying and moving files
performing advanced searches

Some of the more advanced uses of the command line include but not limited to:

tracking software changes
accessing remote servers
unzipping archives
accessing software manuals
installing and uninstalling software
checking, mounting and unmounting disks
automating tasks with scripts
controlling access to files and directories
containerization (running and controlling self contained virtual software)

Basic Commands

Let's introduce some of the most common and basic commands:

cd - This command is used to change into a directory for example if you wanted to change into the desktop directory you would type cd ~/Desktop. Similarly, to leave that directory you type cd ..
The touch command is used to create files. Say you want to create a file named example.html. This would be the correct command syntax for that - touch example.html
Another basic command is the mkdir command which is used to create a directory. If for instance you wanted to create a directory named project you could type mkdir project into the command line

So how do we put this all together to effectively communicate with the computer? Lets see this in a sample workflow:

Lets say you want to create a folder for your new text project, create an empty text document,add some content into the text document and open the same on a code editor so as to work on it:

cd ~/Desktop - Change into Desktop directory
mkdir myproject - Create a folder called myproject on the desktop
cd myproject - Change into the myproject folder
touch example.txt - Create a file called example.txt
cat > example.txt - This will let us add some text to the file. After typing whichever text you want to go in the file, press CTRL+D to terminate the command
code example.txt - Open example.html on VSCode to edit

And there you go. We have defined what the command line is, its various uses and we've gone through a sample workflow using the command line to create a folder, create a file, add content to the file and finally open a code editor to continue working.

On the next article in this series we will delve further into understanding the command line. We will look at how to:

create, rename and delete files and folders on your hard drive using Unix commands
Use pipes and redirection.

Adios

DEV Community: mech2dev

Deploying your API to the web

Overview

DanielStai / jwt_auth

Authentication in an Express app

Technologies used

Endpoints

How to run

Preparing for deployment

Creating a new project on Railway

Conclusion

User authentication in an Express app

Overview

DanielStai / jwt_auth

Authentication in an Express app

Technologies used

Endpoints

How to run

How does JWT work

Project set up

Implementing bcrypt and jwt

DanielStai / netninja-react-backend

REST API for a React FrontEnd

Endpoints

Authentication middleware

Testing our authentication

Conclusion

Setting up MongoDB and Mongoose for your project

Overview

DanielStai / netninja-react-backend

REST API for a React FrontEnd

Endpoints

Project Structure

Connecting to MongoDB

Connecting MongoDB to our project

Creating models

Creating controllers

Custom error handling middleware

Testing the API

Conclusion

Setting up MongoDB

Connecting MongoDB to our project

Changing code to fit MongoDB (creating schemas etc)

Testing with Postman

How to build an Express REST API for a simple blog app

Introduction

DanielStai / netninja-react-backend

REST API for a React FrontEnd

Endpoints

Endpoints

Project setup

Defining Routes

Defining controllers

Testing the API

Conclusion

How to connect a React frontend to an Express server

Introduction

Project setup

Server code

Browser code

Conclusion

Node + Express Basics Part III: Testing a RESTful API with Postman

Introduction

1. Getting all notes

2. Getting an individual note

3. Creating a note

4. Editing a note

5. Deleting a note

Conclusion

Node + Express Basics Part II: Building a RESTful API

1. Project set up

2. Defining data storage

2. Getting all the notes

3. Creating a new note

4. Editing a note

5. Deleting a note

Conclusion

Node + Express Basics Part I: Building a basic HTTP server

Introduction

1. Setting up the project

Implementing `bcrypt` and `jwt`