DEV Community: Atul Kumar

JWT Authentication in Node.js

Atul Kumar — Sun, 16 May 2021 16:10:56 +0000

Hola Amigos!

I was learning about JWT and its application in Node.js and now I'm pleased to share my learnings with ya'll. I hope you guys enjoy reading it. In this post, I'll talk about:

What exactly is a JSON web token
Why do we need JSON web token
JWT authentication in Node.js with Express.js

01 What exactly is a JWT?

According to the official website of JWT:

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

WHATTTT?

Okay! In simple words, JWT is a token that allows secure transmission of data between the same or different web servers.

But how is it different from the traditional session-based approach?

Traditional session-based user authorization

In the traditional approach whenever the user sends a request to a server with user credentials, the user information is stored in the session on the server, and the server will now send a session ID as a cookie. This will authorize the client and this cookie can be attached to all the future requests to the server by the client. With every request, the server has to look up the session ID and validate the user before sending back a response.

JSON Web Tokens (JWT)

In the JWT approach, after the client requests for access, a JWT corresponding to the user is generated which has encrypted user information in it. So basically the server doesn't have to store any user information, the user is stored on the client. This JWT is sent back to the client, and each subsequent request that the client makes will include this JWT. The browser will check the JWT signature to check which user does it corresponds to, and send a response back to the client.

The JWT Structure

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

Header
Payload
Signature

Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

The following is a sample JWT,

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdXRoX2lkIjoiMzIxNjA1MTA1NDEyQUM2QUVCQzQyOTBERUIxMUJENkEiLCJjbGllbnRfaWQiOiIiLCJjc3JmX3Rva2VuIjoiNHJWMGRuWmpJbEdNOFYrNHN3cFZJQkN0M054SjArYlVkVldTdkNDQUJoaz0iLCJpYXQiOjE2MjA4MzQwNjYsInVzZXJfaWQiOiIyYmJlN2QxMC1hYzYxLTQ2NDItODcyMC04OTI1NGEyYzFhYTgiLCJ1c2VyX3R5cGUiOiJndWVzdF9wYXJlbnQiLCJpc19ndWVzdCI6ZmFsc2V9.FNQFIm0_a7ZA5UeMAlQ1pdKS9r6dbe7ryKU42gT5nPc

Let's go to jwt.io debugger, to play around with a sample JWT token, following is the screenshot of the debugger.

If you see, there are three parts to the key

The Header, has the information to the algorithm and the type of token.
The Payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data.

For more about types of claims, you can follow the official doc: https://jwt.io/introduction

You may have noticed the iat key, which stands for issued at, as in when was this token issued. This is mostly used for expiring tokens after a certain amount of time.
The Verify Signature, this part is basically used to verify the signature by the server. We need to add a secret key to this to make it secure.

Suppose the client tries to infringe the token and removes a character, then this token will instantly become invalid as the red and the pink part won't match the signature that is the blue part.

02 Why do we need JWT?

It is stored on client side

Let us assume that there is a Yahama Music Store server that the client needs to access but he can only access this server through Yamaha's main server. In this case, if we go with:

a) The traditional session-based approach, where the user info is stored at the server level, the Music Store server will not have this information and the user will have to log in and authenticate himself again to access Yamaha Music Store. The same goes for the Motor Store server (refer to the image).

b) JWT based approach, since the user is stored at the client-end, even after the redirection with the JWT, the user can request to the Music Store server or the Motor Store server through the main server without getting logged out in between. One thing to note: the servers should share the same secret key among them to be accessible to the clients while using JWT.
More compact

If we compare it with SAML, as JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.
Ease of use

JSON parsers are common in most programming languages because they map directly to objects. This makes it easier to work with JWT

03 JWT authentication in Node.js

Now let's try to build a simple JWT authentication service in Node.js

1. Setup

To showcase the cross-server application of JWT, I'll be making two different servers, one for all the requests related to authentication and name it authServer.js and the second will be any other API requests to get some information from the server and we will simply name server.js

authServer.js will listen to port 5000 and server.js will listen to port 4000

To start, let's install few modules

npm install express jsonwebtoken

Note: We have installed express as a framework on top of node to handle all the server-related actions and jsonwebtoken for signing a jwt against a user, or simply getting a jwt for a user.

After installing we'll just call these modules in both our files i.e authServer.js and server.js

const express = require('express');
const jwt = require('jsonwebtoken');

const app = express();

app.use(express.json());

2. Generating JWT on login

Let's write the first API call which will be a POST request to log in a user in the authServer.js file.

app.post('/login', (req, res) => {
  // ...
  // Suppose the user authentication is already done

  const username = req.body.username;
  const user = {name: username};

  const accessToken = generateAccessToken(user);
  res.json({accessToken: accessToken});

});

app.listen(5000);

Let's define generateAccessToken function which will basically return the JWT

const generateAccessToken = (user) => {
  return jwt.sign(user, process.env.ACCESS_TOKEN_SECRET, {expiresIn: '30s'});
}

Here is the definition of jwt.sign,

jwt.sign(payload, secretOrPrivateKey, [options, callback])

The callback can be of two types:

(Asynchronous) The callback is called with the err or the JWT.
(Synchronous) Returns the JWT as a string.

Note: To use the environment variable we need to configure it first, for which we need to install another module called dotenv; We'll install it with npm install dotenv

After running this command, we need to make a .env file and place our ACCESS_TOKEN_SECRET secret key there, the value should be something unguessable. for eg:

"0704d2bf835240faffab848079ce73ccf728ffd833e721afd4d7184845b5fc8f00e9f4e2baa87f9d77432f06f0f0384c736d585dacf3f736d8eda3b740c727dea7291542235fe02d75e6ba755307e2546408cffce0b210b4834ea5eff2587859d101bf94aac0f062036662f279ce6f12d84b890a0eaa357b70a01c6922621591"

This can be anything random, you can generate it by running the following script in the node terminal:

require('crypto').randomBytes(64).toString('hex');

After putting the key in the .env file, what we need to do is add the following line on top of both our server files, so that it can access process.env variables.

require('dotenv').config();

3. Getting data from Server

Let's make a GET request to get some data from the server corresponding to the logged-in user, in the server.js file:

const articles = [
  {
    id: 1,
    name: "Atul Kumar",
    title: 'First Article',
  },
  {
    id: 2,
    name: "John Doe",
    title: 'Second Article',
  },
  {
    id: 3,
    name: "Don Joe",
    title: 'Third Article',
  },
];

app.get('/articles', authenticateToken, (req, res) => {
  res.json(articles.filter(article => req.user === article.name));
});

As you can see we have used a custom middleware authenticateToken for our /article request.

Following is the definition of authenticateToken:

Note: I've used the ES6 fat arrow function so you need to write this function before you make a GET request.

const authenticateToken = (req, res, next) => {
    // getting the authorization information
  const authHeader = req.headers['authorization'];
    // In our case It's JWT authantication
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) return res.sendStatus(401); // No token found;

    // verify if there is a user corrosponding to the token found in the 
    // authorization header.
  jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, (err, user) => {
    if (err) return res.sendStatus(403); // The token is there but it's not valid;
        // if the token is valid, i.e the user is present, then in the request we are 
        // attaching the user name, so that it can be used in other action controllers.
    req.user = user.name;
        // proceeding to the next action controller.
    next();
  })
}

Why did we do authHeader.split(' ')[1];?

Since JWT is a bearer token, req.headers['authorization']; will give us a string having a value that would look like:

"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiQXR1bCBLdW1hciIsImlhdCI6MTYyMTAwOTEzMCwiZXhwIjoxNjIxMDA5MTYwfQ.fxDe0Q2S_G5M0qq1Lo91sz2Od9hBS12226Utq0LJ9jY"

We just need the token part of the string.

We are basically checking whether the client that made the GET request for /articles has access to it or not. We do this by checking if there is a valid token attached to the request. While making the GET request we need to make sure that we include the JWT in the authorization header.

But what if we don't?

Well if we don't, then we'll get 'Unauthorized' in the response body because if you look at the code a 401 status code is sent when the token is not found.

Let's try to play with what we have made until now, on the Postman app.

Let's try to access the articles with the GET request
1. Without a bearer token :
  
  As you can see, we are getting a 401 Unauthorized Status, like we discussed earlier, it's because we didn't give a token at all (you can see the Token field is empty).
2. With an invalid bearer token :
  
  We'll just give a random JWT token to check what happens in this case.
  
  This time we are getting a 403 Forbidden status, i.e we have a token but this token seems to be invalid.
  
  But Atul how can my token be invalid?
  
  Well, there could be two reasons -
  
  a) The token has been tampered with, or you might have just put a random string for the token.
  
  b) The token has expired.
  
  If you look at the code,jwt.verify() first checks if this token is a valid token or not. If it is valid, it returns the user object. If it is not, it gives us a 403 status.
  
  How can we access the articles of a particular user?
  
  To be doing this, we need to first log in with a user so that a new JWT could be generated.
Now let's login with a given username

We'll request for /login with the body being a JSON object having the key username.

We have successfully logged in and have gotten our accessToken (JWT),

Now we can use this accessToken in our GET /articles request.

As you can see, we got the articles for this particular user as we used the JWT which has the payload information of this very user. If you log in with a different user, then you can access their articles too.

Note: We have used {expiresIn: '30s'} as the option to the jwt.sign() method, so if you try to access with the same accessToken after 30 seconds, you'll get Forbidden in the response, since the token has been invalidated now. But, generally, we wouldn't limit expiration time to 30 seconds (this was only an example).

So should the user log in again after every 30 seconds to access her articles?

Of course not, we would need to add another kind of token to our application called a Refresh Token.

4. Refresh Token

The concept is simple: after every 30 seconds, we'll generate a new access token for the user with the help of the refresh token of the user.

Ideally, we'll need to store our refresh token in cache memory or some database so that we can validate which users need a new access token. But in our example here, let's not waste time in storing it in a database; we'll just focus on the concept.

Let's keep it in a variable then;

let refreshTokens = [];

Note: Bad practice, should not be done on a production build, because every time the server will restart this will make refreshTokens empty. I'm using it so that we can focus on the concept.

In our .env file we'll add a new secret key REFRESH_TOKEN_SECRET and assign it some encrypted value, just like how we did for ACCESS_TOKEN_SECRET

Now, in our /login action controller we will basically push the refreshToken in the refreshTokens array that we created.

app.post('/login', (req, res) => {
  // ...
  // Suppose the user authentication is already done

  const username = req.body.username;
  const user = {name: username};

  const accessToken = generateAccessToken(user);
  const refreshToken = jwt.sign(user, process.env.REFRESH_TOKEN_SECRET)
    // pushing the refreshToken generated for this particular user.
  refreshTokens.push(refreshToken);
  res.json({accessToken: accessToken, refreshToken: refreshToken});

});

Now we will need to create a new POST request to generate a new access token for a particular refresh token in our authServer.js file

// generates a new access token with the help of the refresh token;
app.post('/token', (req, res) => {
    // getting the token value from the body
  const refreshToken = req.body.token;
  if (!refreshToken) return res.sendStatus(401);
    // if it doesn't belong to the array we created to store all the refreshTokens
    // then return Unauthorized.
  if (!refreshTokens.includes(refreshToken)) return res.sendStatus(403);

  jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET, (err, user) => {
    if (err) return res.sendStatus(403);
        // if the user is found generate a new access token
    const accessToken = generateAccessToken({ name: user.name});
    res.json({ accessToken: accessToken });
  })
});

Why are we not passing the user object directly to the generateAccessToken?

It is because there is some additional information that is stored in the user object that we get in return, the following is the user object we get,

{ name: 'Atul Kumar', iat: 1621086671 }

the problem is if we use the whole user object, jwt.sign() will generate the same accessToken every time because we are passing the user object having the exact same iat

Now let's check if everything is working on Postman

We'll log in and look for the access token and the refresh token in the response
We'll get all the articles for this particular user
Now if we make a request after 30 seconds with the same accessToken we'll get Forbidden.
We'll now generate a new token for this user, we make a POST request to /token passing the refresh token we obtained in the first step.

We'll get a new accessToken.
Now we'll use this newly generated accessToken to access the articles again.

We are able to access articles again, we can do this every time the token expires.

So does this mean users having the refresh token will have the access to the app forever? Can they generate a new accessToken whenever they want?

Right now, yes, but we need to stop this from happening, by invalidating the refresh token. But when is the right time to invalidate a refresh token?

We'll invalidate a refresh token on the /logout URL. Let's make a delete request for this.

5. Invalidating a refresh token

app.delete('/logout', (req, res) => {
  refreshTokens = refreshTokens.filter(token => token !== req.body.token);
  res.sendStatus(204);
})

This will take the refresh token as the body param that we would want to free from the cache storage, or in our case, the array.

Whenever the user logs out, the refreshToken will basically expire (no more in the storage). The user will have to log in again to get a fresh pair of refreshToken and accessToken assigned to her.

Trying this out:

And now we can no longer generate any new access tokens by hitting /token API, with this refreshToken that we passed in the logout request.

That's it on JWT from me!

If you found this useful, have any suggestions or thoughts to share, do let me know in the comments below :)

Adios until the next article,

atulkumar:5000/logout

Did you webPACK your assets yet? - Getting Started with Webpack

Atul Kumar — Thu, 03 Sep 2020 22:13:51 +0000

Hola folks!

Here's a documentation of my explorations with setting up Webpack. I checked out Webpack for the first time when I just needed to handle some SVG assets for a react project. But the more I read, the more I realized how beautiful and useful it is. I'm really pumped up to share my take-aways with y'all. Hope this helps other FE devs who want to get started.

As per Webpack's official doc,

Webpack is a static module bundler for modern JavaScript applications

But what does that mean? And how is it even useful?

Here's what I'll cover in this post.

The what's and why's of Webpack
Advantages of using it over traditional react-scripts of CRA (create-react-app)
Setting up Webpack
Loaders and Plugins
Optimizing

01 The what's and why's of Webpack

Webpack is a bundler which manages the resources and assets of our project (like a CSS/SASS file, an image, or fonts) at compile time. It does so by making a dependency graph to refer to, for every node it visits while processing. That is how it makes sure that code that needs to load first, loads first.

Imagine you have a project where multiple javascript files depend on each other, like this very simple one here.

In calculateBattleIndex.js

function calcBattleIndex(hero) {
    return (hero.strength * 2 + hero.defence * 3) / 10;
}

In calculatePower.js

function calcPower(hero) {
    return hero.money / 100 + calcBattleIndex(hero);
}

In index.js

var batman = {
    money: 100,
    strength: 70,
    defence: 92,
}

var superman = {
    money: 50,
    strength: 99,
    defence: 80,
}

calcPower(batman);
calcPower(superman);

As you can see, the caclPower function is dependent on calcBattleIndex function.

So, in order to properly execute the index.js file, we would need to include calculateBattleIndex.js and calculatePower.js in the following order.

<script src="calculateBattleIndex.js"></script>
<script src="calculatePower.js"></script>
<script src="main.js"></script>

If we mess up with the order (that is, if we chose to include calculatePower.js before calculateBattleIndex.js), then we might get a function undefined error.

But our project might not be as simple and small, so managing dependencies would be a hell of a task. That is one reason why people have started moving to component-based libraries built on javascript, like React.js and Angular.js, because they offer built-in modules to compile code.

Let's see how React does it.

02 Advantages of Webpack over react-scripts of CRA

I'm sure people who've worked on React might already know create-react-app, which has some built-in react-scripts to run the app, to make a production build, or to even test it.

But one major problem is that these are built-in script commands, so they are not really customizable. This is where you'll really feel the need to substitute it with Webpack.

Here are some more advantages of Webpack that I've come across:

Configurability

create-react-app offers you minimum configuring build settings. They go by 'You Might Not Need a Toolchain' in their official doc. Although there is a way - by running npm eject to get all the configuration files and editing them yourself - you'll still feel like it takes away the control Webpack provides, where you can really play with different environment configurations as per your needs.

SSR (server side rendering)

Ultimately server-side rendering is very hard to add in a meaningful way without also taking opinionated decisions. We don’t intend to make such decisions at this time. — Dan Abramov

// Detect dark theme var iframe = document.getElementById('tweet-938505385794818049-562'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=938505385794818049&theme=dark" } // Detect dark theme var iframe = document.getElementById('tweet-953296173116276736-413'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=953296173116276736&theme=dark" }

SSR on a create-react-app is not only complex but it can't be done without the help of third-party support, and CRA's developers are not eager to add this feature either.

But it can be done with Webpack very easily (will not get into that in this post, but you can follow up here: https://blog.jakoblind.no/ssr-webpack-bundle/).

03 Setting up Webpack

You can install Webpack and its command-line interface by:

npm install --save-dev webpack webpack-cli

That's it.

Check your package.json file to see dependencies getting added up there,

"devDependencies": {
    "webpack": "^4.44.1",
  "webpack-cli": "^3.3.12"
}

Now let's make configuration files - these are required to give sets of rules for how certain types of files will be treated during compilation and resolution (before making AST to parse on).

For now, I'm making a common configuration file, which will serve both the dev and the prod environments along with the already existing configurations in them (which I'll add later), and name it webpack.common.js

The directory structure will look somewhat like this:

root
    |_src
    |   |_index.js
    |   |_calculateBattleIndex.js
    |   |_calculatePower.js
    |   |_images
    |_configs
    |   |_webpack.common.js
    |_dist
        |_myProject.js

Supplying configurations to Webpack

Since Webpack needs configuration modules to bundle the code, let's make a basic config (inside webpack.common.js), where Webpack takes in the index.js file, and bundles it in the dist directory.

// webpack.common.js

const path = require('path');

module.exports = {
  entry: '.src/index.js',
  output: {
    filename: 'myProject.js',
    path: path.resolve(__dirname, 'dist'),
  }
}

Add the Webpack start script in package.json

"scripts": {
    "start": "webpack --config webpack.common.js",
}

Now run, npm start

It's quite evident, myProject.js in the final bundle which is generated by Webpack for the JS file. We can now remove all the other script(s) from our index.html file and just use this generated bundle as the only source script.

<script src="dist/myProject.js"></script>

Analysing the bundle

This section of the file is quite interesting, as we can see the functions we made have been minified and have become an argument to the eval function.

The minification is happening because Webpack will run our code in production mode by default. If we don't set the mode manually, the output will be minified.

To set the mode manually, add this to module.exports

mode: "development"

But even in development mode, the argument inside the eval function is still minified, so by adding

devtool: false

in module.exports we can make the content in the bundle readable just like the following screenshot.

On running through the code, you might have these questions in mind.

a) Why are we using path.resolve() ?

This is basically used to resolve the relative path for a particular system. For example, in my machine, the __dirname (a node script to get the complete address of the current directory) is atulkumar/documents/src/dist whereas in some other machine the root directory could be different.

b) What are entry and output points?

In this case, the root javascript file (index.js) becomes the entry point, and the output file is the file generated by the Webpack (myProject.js)

04 Loaders and Plugins

Loaders

Loaders are used by Webpack to pre-process files. This enables us to bundle static resources apart from javascript files as well. There is a well documented official Webpack doc where you can find a lot of different loaders and their use-cases.

I'll call out a few helpful loaders which, according to me, every project must have.

04.01 Loader for CSS `css-loader` , `style-loader` & `sass-loader`

These loaders will handle our CSS and SASS/SCSS files.

To install the loaders,

npm install --save-dev style-loader css-loader sass-loader

and add the following piece of code to the module.exports

module: {
    rules: [
        {
          test: /\.scss$/,
          use: [
            "style-loader",
            "css-loader",
            "sass-loader"
          ]
        }
    ]
}

Note: Here, the order of the use array matters, and the loaders are applied on our CSS/SCSS file in the reverse order, i.e:

a) sass-loader will be applied first which will pre-process the SCSS into CSS

b) and then css-loader will turn CSS into Common JS

c) lastly, style-loader will inject style straight into DOM

04.02 Loader for images and fonts, `file-loader`

Again, we will need to install it first,

npm install --save-dev file-loader

and add the following piece of code in the rules array of module.exports

{
  test: /\.(svg|png|jpg|gif)$/,
  use: {
    loader: 'file-loader',
    options: {
      name: '[name].[hash].[ext]',
      outputPath: 'images/'
    }
  }
},
{
  test: /\.(woff(2)?|ttf|eot|svg)(\?v=\d+\.\d+\.\d+)?$/,
  use: [
    {
      loader: 'file-loader',
      options: {
        name: '[name].[ext]',
        outputPath: 'fonts/'
      }
    }
  ]
}

Running through from the code...

The test will receive a RegEx to match for the type of file (format).
We can also pass an options object along with our loader to customize it further - here, I've set up name and outputPath.
[name] extracts the name of the particular asset being processed. [hash] is a unique hash appended after the dot. This has its own use, I'll talk about it a little later. [ext] as by the name, extracts, and appends the extension of the asset.
We can also give a custom path for the generated asset type by defining the outputPath
file-loader resolves import and require() on a file and converts it into a URL.

04.03 Loader for JS or JSX, `babel-loader`

Install it with:

npm install -—save-dev babel-loader

Also install the presets and plugins it requires, with:

npm install —-save-dev @babel/preset-env @babel/plugin-transform-runtime

{
  test: /\.jsx?$/,
  exclude: /(node_modules)/,
  use: {
    loader: 'babel-loader',
    options: {
      presets: ['@babel/preset-env'],
      plugins: ['@babel/plugin-transform-runtime'],
    }
  }
},

Running through from the code...

babel-loader is basically used for transpilation. I'm sure you know why we need transpilation.
Why did we exclude the node_module directory?

While transpiling a js file or preprocessing and transpiling the jsx we excluded the node_module directory. And we did this for a very good reason.

When we serve javascript to Webpack or any other asset for that matter, to increase the performance we need to cut down on the amount of code (size of compilation) we give Webpack for transpiling, especially because it's a costly process. So we skip on anything that comes from node_module because these should already be runnable, without transpilation.

But this doesn't necessarily hold true all the time - you may come across a certain third party library, which may require transpilation on your off days. Don't worry, this can be taken care of as well.

Imagine there are two modules amongst all the other modules - module-1 and module-2 which need to be transpiled. We can simply modify our regEx to exclude these modules from being excluded for transpilation, or simply, to include them while transpiling.
```
exclude: /node_modules\/(?![module-1|module-2])/
```
Here, it will skip all the files in node_module except module-1 and module-2
@babel/preset-env

Thanks to this preset, JS developers can write the latest JS code without worrying about browser support.
@babel/plugin-transform-runtime enforces babel helper functions that help save on the code-size. (I would recommend you to read the official doc to know more since it's quite interesting: https://babeljs.io/docs/en/babel-plugin-transform-runtime)

Cache Busting

There are a lot of things a browser does in the background that we sometimes don't observe. But, caching is something most of us are familiar with. A browser caches certain assets like bundled JS, CSS bundles, or even images to reduce load-time for future visits. If you refresh a page and look at the network tab in the developer tools, you'll see all the calls the website makes to get the content.

Here is my final bundle file myProject.js on a hard refresh

To compare here is the same file on a soft refresh (cache disable off)

Look at the difference in the size, astonishing right?

But there is a pitfall.

While caching helps improve the load-time of a website, it hampers the user experience. Whenever the content is loaded from the cache, the user won't see the latest content of our website if we've made an update, and we can't expect them to perform a hard refresh, or to clear the cache regularly.

So busting cache becomes important.

After digging a little deeper, I came to know that the browser depends on the file name when it caches it. So essentially, changing the file-name on every refresh should solve our problem.

But how do we do it?

[contenthash] does it for us. It is basically a hash generated for extracted content.

Lets add it to the output file:

output: {
    filename: 'myProject.[contenthash].js',
    path: path.resolve(__dirname, 'dist'),
  },

Note: We can replace the dot with a dash or any other special character, or we can just skip it altogether and simply write myProject[contenthash].js. This will also work.

Let's start the Webpack again and check,

I've added a few fonts and images, but let's focus on the main bundle.

8dcb493e06ef82c4151b has been appended to the name we provided in the output. This is the contenthash, which like any other hash function gives us a unique hash value, which changes only when the content of any dependency in the bundle changes.

To put in simply, this works like a normal hash function - for a particular value as input the function will always return the same unique output.

Tip: You can also slice the hash to limit it to a certain number of characters only, using:[contenthash:6].

Now we have a unique name on every file change, so the browser will know when to request for this file and when to load it from the disk cache.

A good example to use cache busting would be in vendor.js, where we bundle the code from all the third-party libraries, as it doesn't change frequently.

But how can we link a JS file with a random name in the <script>, when it changes on every update?

Plugins! We can do it with the help of plugins!

Plugins

Plugins are used to customize Webpack's build process and they make Webpack much more powerful.

04.04 Linking bundles with names having random hash values - `html-webpack-plugin`

Let me start with a very important plugin html-webpack-plugin, which will solve the problem of using [contenthash] and linking the output bundle with the main HTML template file.

Let's first install this plugin by running:

npm install —-save-dev html-webpack-plugin

Include it in the webpack.common.js file.

const HtmlWebpackPlugin = require("html-webpack-plugin");

Now add this to the module.exports

plugins: [new HtmlWebpackPlugin()]

This will make a new HTML file with a default <title> tag and a <script> tag linking to the output JS bundle. You'll see your final JS bundle already linked in this newly generated HTML file.

<script src='myProject.8dcb493e06ef82c4151b.js'></script>

But what if we already have an HTML file with some content in it? How do we link all our bundled assets to that particular file?

The answer is fairly simple,

html-webpack-plugin lets us supply our own template using lodash templates so that all the bundles can be sourced to this template.

plugins: [
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, 'index.html'),
    })
  ],

04.05 Cleaning up unwanted build resources `clean-webpack-plugin`

Another really important plugin you can use in your production build is the clean-webpack-plugin. Whenever you make a production build by running npm run build, you would see new files piling up and increasing the collective size of the build directory. Only the files generated from running the latest npm run build, will be important for us so why should we keep all the other extra files?

Well, we won't be keeping them with clean-webpack-plugin.

Let's start by installing it,

npm install -—save-dev clean-webpack-plugin

Remember, this would be useful for the production environment as there is no build made in the development mode, well there is but not in our project directory, Webpack makes it in the system memory and loads it from there.

So now the webpack.prod.js will look like this:

const common = require('./webpack.common');
const { merge } = require('webpack-merge');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');

module.exports = merge(common, {
  mode: 'production',
  plugins: [new CleanWebpackPlugin()],
});

What clean-webpack-plugin does is, it empties the build directory before making the new build resources. With this, you don't need to worry about the extra unused files now.

Live reloading - the webpack-dev-server

Suppose you change something in the code and on saving it, the website reloads automatically! Wouldn't that be cool?

webpack-dev-server can do it for us and it's quite simple to add it up.

We just need to install it by running this command

npm install —-save-dev webpack-dev-server

and adding to the npm start script in package.json

"scripts": {
    "start": "webpack-dev-server --config src/config/webpack.common.js",
    // other scripts.
}

Yass that's it, that will do the magic.

webpack-dev-server uses webpack-dev-middleware under the hood, which provides fast in-memory access to Webpack assets.

Note: webpack-dev-server should be used in the development mode only.

Tip: You can add —-open to the script to start the Webpack with opening a new window with localhost:[port] every time you run npm start.

Configuring according to the environment (dev/prod)

Like I discussed earlier in this post, we'll be making 3 separate files for webpack config:

One was already made - webpack.common.js - let's make configs for both the production and the development environments too, and name them webpack.prod.js and webpack.dev.js.

Throwing some code in them:

// webpack.dev.js
const common = require('./webpack.common');
const { merge } = require('webpack-merge');
const path = require('path');

module.exports = merge(common, {
  mode: 'development',
  devServer: {
        contentBase: path.join(__dirname, 'build'),
    compress: true,
    port: 3006,
  },
});

// webpack.prod.js
const common = require('./webpack.common');
const { merge } = require('webpack-merge');

module.exports = merge(common, {
  mode: 'production',
});

Running through from the code...

To merge the common module we made earlier with the new ones, we need to install webpack-merge (npm install -—save-dev webpack-merge) and include it in both the files.
mode will govern the built environment for the Webpack
devServer is a set of options picked by webpack-dev-server.
- contentBase holds boolean | string | array value stating the static file location.
- compress: true will enable gzip compression
- port is the localhost port to serve the website content on

Now, in package.json add a build script that would generate the build resources for the production environment.

"scripts": {
    "start": "webpack-dev-server --config src/config/webpack.dev.js --open",
    "build": "webpack --config src/config/webpack.prod.js",
}

05 Optimisations

Before running straight into optimizing Webpack, let us configure a super-cool plugin which will make the Webpack logs look prettier!

The webpack-dashboard plugin.

Let's start by installing it,

npm install --save-dev webpack-dashboard

We'll require the plugin,

const DashboardPlugin = require('webpack-dsahboard/plugin');

Now adding the plugin in the config file and instantiating DashboardPlugin.

plugins: [
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, 'index.html'),
    }),
        new DashboardPlugin()
  ],

We need to edit the start script as well to make sure Webpack starts up with the webpack-dashboard plugin.

"scripts": {
    "start": "webpack-dashboard -- webpack-dev-server --config src/config/webpack.dev.js --open",
}

Run npm start

And Booyah!!

This is your new Webpack log screen 🙌🏻

Note: Just so you don't get lost, these logs are from a different project where I'd already installed a lot more dependencies so that we can go forward with optimizations. A lot has to do with third-party libraries. With npm you'll get all of your 3rd party dependencies nicely clubbed in the node_modules directory.

Splitting chunks with splitChunks

As you can see in the above screenshot, the only bundle that was generated by the Webpack is squaremate.8dcb493e06ef82c4151b.js, having a size of 4.42Mb.

Now consider this - if we have to change something in the code, Webpack will re-bundle the whole file again (not load it from the cache... because we did bust some cache, right?), and serve it to the browser.

On every change, the browser will be requesting a 4.42Mb of data. That is quite a significant, if not a huge, breach in performance.

But what is in this file that is making it so huge? Of course, the vendor (third party) libraries.

splitChunks enables us to split this file into chunks according to our needs.

Let's configure the basic optimization for Webpack by splitting all types of chunks

optimization: {
    splitChunks: {
      chunks: 'all'
    }
},

Run npm start and notice the magic!

As you can see now we have got 2 bundles squaremate.b9351008d8c24dca3f91.js [119.64Kb] and vendors~main.squaremate.dafe32322b2b203e53da.js [4.31Mb]

Oh hell! This vendor bundle was hiding behind the main bundle and eating up resources of the browser. If you take a closer look at the module section of the logs, you can also infer which module is actually killing up the browser and you can provide special attention to that particular module.

While this little piece of code can do the magic for us, let's try to understand what is actually happening behind the scenes.

Inferences

As per the official docs, there are certain rules according to which Webpack automatically splits chunks
- A new chunk can be shared OR modules are from the node_modules folder
- New chunk would be bigger than 20kb (before min+gz)
- Maximum number of parallel requests when loading chunks on demand would be lower than or equal to 30
- Maximum number of parallel requests at the initial page load would be lower than or equal to 30
As the vendor code tends to change less often, browsers can cache it and load it from the disk cache itself, rather than making calls for it every time we hit refresh.
If you'll do the math you'll notice the gigantic reduction in the main bundle size here, with just the 3 lines of code we added. Isn't that commendable?

Well, this is just basic optimization. You can flex much more with the power that splitChunk provides. I won't get into more details, but I'll link an insane blog post by David Gilbertson from New South Wales, on optimization by splitting chunks on a whole new level [spoiler alert: more bundles incoming...].

https://medium.com/hackernoon/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758

(Highly recommended read)

Conclusion

Webpack takes away the worry of managing resources for a front-end developer. You'll know how smart it is in managing them efficiently only if you choose to go into the depths of it.

The underlying aspects are quite interesting to move forward with, and it's only fair for us to know what has been going behind the scenes because of the sheer power it harbors and gives away to a developer. Do I sound like Alfred from Batman, Master Wayne?

In this particular blog, I tried to give justice to a few of Webpack's important features and tried to explain concepts from my point of view.

We started with why is it even important to have Webpack in our project. The smallest example I could think of, still yielding a huge takeaway. There will be more such examples you'd come across, which would help answer your why's.
We covered the reasons for why would you want to switch to Webpack from a more native react-scripts, when you stumble upon a react project.
We set up our configuration files for the production and development environments and threw in some loaders and plugins in the process.
We talked about how could cache busting solve our caching problems.
We also talked briefly about the optimizations that Webpack provides and how can we save up on the load-time of our website.

DEV Community: Atul Kumar

JWT Authentication in Node.js

01 What exactly is a JWT?

But how is it different from the traditional session-based approach?

The JWT Structure

02 Why do we need JWT?

03 JWT authentication in Node.js

1. Setup

2. Generating JWT on login

3. Getting data from Server

4. Refresh Token

5. Invalidating a refresh token

atulkumar:5000/logout

Did you webPACK your assets yet? - Getting Started with Webpack

01 The what's and why's of Webpack

02 Advantages of Webpack over react-scripts of CRA

Configurability

SSR (server side rendering)

03 Setting up Webpack

Supplying configurations to Webpack

Analysing the bundle

04 Loaders and Plugins

Loaders

04.01 Loader for CSS css-loader , style-loader & sass-loader

04.02 Loader for images and fonts, file-loader

04.03 Loader for JS or JSX, babel-loader

Cache Busting

Plugins

04.04 Linking bundles with names having random hash values - html-webpack-plugin

04.05 Cleaning up unwanted build resources clean-webpack-plugin

Live reloading - the webpack-dev-server

Configuring according to the environment (dev/prod)

05 Optimisations

Splitting chunks with splitChunks

Conclusion

04.01 Loader for CSS `css-loader` , `style-loader` & `sass-loader`

04.02 Loader for images and fonts, `file-loader`

04.03 Loader for JS or JSX, `babel-loader`

04.04 Linking bundles with names having random hash values - `html-webpack-plugin`

04.05 Cleaning up unwanted build resources `clean-webpack-plugin`