Forem: Duc Le

Reduce Docker Image size for your Next.js App

Duc Le — Fri, 28 Apr 2023 09:28:20 +0000

Introduction

First thing first, I expect you to know what is Docker, but if you don’t:

Docker is an open platform for developing, shipping, and running applications

NextJS, in other hand, is a flexible React framework that gives you building blocks to create fast web applications.

Dockerize your App

Before we optimize anything, we have to dockerize the application first. Let’s say our application name is my-space . Starting with:

Create the Dockerfile :



touch Dockerfile

Ignore unnecessary files in dockerignore:



node_modules
.next
.vscode
.gitignore
README.md
.dockerignore
.git

Dockerize it:

This is the most basic example on how to dockerize your app, now let’s build it with:



docker build -t my-space .

Now look at the size:

*That’s just crazy, 2.42gb!!
*

Unbelievable right, we can’t publish this image, it’s just too heavy !

Reduce the image size

Use alpine

The Node.js Docker team maintains a node:alpine image tag and variants of it to match specific versions of the Alpine Linux distributions with those of the Node.js runtime. The original version size is about 1gb.

Now we will move to the alpine version:

Now the size shrank to 1.65gb, 800mb smaller. That’s a good start !

Multi-stages builds

Multi-stage builds are useful to anyone who has struggled to optimize Dockerfiles while keeping them easy to read and maintain.

We will create 2 stages in the Dockerfile . I will call it builder and runner

In this way we can get rid of unnecessary files in our image:

We will pick files from the builder and move it to the runner that we will eventually use:

*The size comes down to 1.36gb, about 300mb smaller, we are doing good !
*

Remove duplicate layers

You can see something is duplicating. Yes, we install the dependencies twice for each stage. Although this works and the project size is still the same. The image size is still big because of caching and layers.

So we can pick the node_modules from the build stage:

The size now is quite decent for a NextJS app, below 500mb

But we can still make it lighter !

Output File Tracing

During a build, Next.js will automatically trace each page and its dependencies to determine all of the files that are needed for deploying a production version of your application.

This feature helps reduce the size of deployments drastically. Previously, when deploying with Docker you would need to have all files from your package’s dependencies installed to run next start. Starting with Next.js 12, you can leverage Output File Tracing in the .next/ directory to only include the necessary files.

In your next.config.js file, enable the standalone output



experimental: {
    outputStandalone: true,
  },

This will create a folder at .next/standalone which can then be deployed on its own without installing node_modules.

*The size is now 176mb! Small enough for most cases
*

Conclusion

This is just a simple example on how to optimize your docker image sizes, you can look deeper in Docker docs to find the most suitable treatment for your app!

Costly CSS Properties and How to Optimize Them

Duc Le — Thu, 13 Apr 2023 04:10:29 +0000

Introduction

Some CSS properties are more costly than others in terms of performance. When used improperly, they can slow down your webpage and make it less responsive for your users. In this article, we’ll explore some of the most costly CSS properties and how to optimize them.

Box-Shadow

The box-shadow property is a popular way to add a shadow effect to an element, but it can be very costly in terms of performance. When used on a large number of elements or with a large blur radius, it can significantly slow down your webpage.

Here are some ways you can do to reduce the cost of box-shadow :

Use a smaller blur radius — A smaller blur radius will reduce the amount of processing required to render the shadow. Instead of using a large blur radius, try using a smaller value that still gives you the desired effect. Use a solid color instead of a gradient — A gradient box-shadow can be very costly in terms of performance. Instead of using a gradient, try using a solid color for your box-shadow.
Use the inset keyword for inner shadows — If you’re using box-shadow to create an inner shadow, use the inset keyword. This will improve the performance of your webpage because it doesn’t require rendering an extra layer.
Use the will-change property to improve performance when animating box shadows — If you’re animating box-shadow, use the will-change property to tell the browser that the box-shadow property will be changing. This will help the browser optimize the rendering of the animation.

Overall, optimizing the box-shadow property involves reducing the processing required to render the shadow. By using these techniques, you can create a box-shadow that looks great while minimizing the impact on your webpage’s performance.

Background Image

The background-image property is used to add an image to an element, but it can be very costly in terms of performance. Large images or a large number of images can significantly slow down your webpage.

To optimize the background-image property, you can use the following techniques:

Use smaller image file sizes
Use image compression techniques like JPEG or PNG optimization
Use image sprites to reduce the number of HTTP requests
Use lazy loading techniques to load images only when they are needed

Border-Radius

The border-radius property is used to create rounded corners on an element, but it can be very costly in terms of performance. When used on a large number of elements or with a large radius, it can significantly slow down your webpage.

To optimize the border-radius property, you can use the following techniques:

Use smaller border radius values
Use the border-image property instead of border-radius for complex border designs
Use SVG graphics for complex border designs

Transforms

The transform property is used to apply transformations to an element, such as rotation, scaling, or skewing. When used improperly, it can be very costly in terms of performance.

To optimize the transform property, you can use the following techniques:

Use 2D transforms instead of 3D transforms when possible
Use the will-change property to improve performance when animating transforms
Use hardware acceleration by using the transform-style: preserve-3d property

Filters

The filter property is used to apply visual effects to an element, such as blurring, color adjustment, or brightness. When used improperly, it can be very costly in terms of performance.

To optimize the filter property, you can use the following techniques:

Use simpler filter effects
Use the will-change property to improve performance when animating filters
Use hardware acceleration by using the transform-style: preserve-3d property

Original CSS code:

div {
  filter: blur(5px);
}

Optimized CSS code:

div {
  filter: blur(1px);
  transform: translateZ(0);
}

Explanation:

Instead of using a larger blur radius, we are using a smaller value of 1px. This reduces the amount of processing required to render the blur effect.

We are also adding a transform property with the translateZ(0) value. This creates a new layer for the element, which can help with GPU acceleration and improve performance.

By using this optimized CSS code, we can achieve the same visual effect while reducing the impact on our webpage’s performance.

Conclusion

By optimizing CSS properties like box-shadow, filter, and border-radius, we can improve our webpage’s performance. Techniques include using smaller values, simpler shapes, and creating new layers with the transform property. These optimizations help create webpages that look great and perform well.

P/s: Thumbnail Image from https://kinsta.com/ , please check the page out, It has a lot of cool articles

Understanding Critical Rendering Path (CRP)

Duc Le — Tue, 11 Apr 2023 03:39:21 +0000

What is Critical Rendering Path?

The Critical Rendering Path are the steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. The critical rendering path includes the Document Object Model (DOM), CSS Object Model (CSSOM), render tree and layout.

The DOM is created as the HTML is parsed. The HTML may request JavaScript that might alter the DOM. The HTML includes or makes requests for styles, which builds the CSSOM.

The browser engine combines the two to create the Render Tree. Layout determines the size and location of everything on the page. Once layout is determined, pixels are painted to the screen.

Critical Rendering Path Deep dive

We can go into the details of the CRP with these steps:

A request for a web page or app starts with an HTML request The server returns the HTML
The browser then begins parsing the HTML, converting the received bytes to the DOM tree
The browser initiates requests every time it finds links to external resources, that would be stylesheets, scripts, or embedded image references, some requests are blocking, which means the parsing of the rest of the HTML is halted until the imported asset is handled, this in when requests optimization comes in
The browser continues to parse the HTML making requests and building the DOM, until it gets to the end, at which point it constructs the CSS object model.
With the DOM and CSSOM complete, the browser builds the render tree, computing the styles for all the visible content.
After the render tree is complete, layout occurs, defining the location and size of all the render tree elements
Once complete, the page is rendered, or ‘painted’ on the screen.

Document Object Model

DOM construction is incremental. The HTML response turns into nodes which turn into the DOM Tree. Nodes contain all relevant information about the HTML element. .

The more nodes we have, the longer the following events in the critical rendering path will take. Remember A few extra nodes won’t make a big difference, but keep in mind that adding many extra nodes will impact performance.

CSS Object Model

The DOM contains all the content of the page. The CSSOM contains all the styling information. CSSOM is similar to the DOM, but different.

While the DOM construction is incremental, CSSOM is not. CSS is render blocking: the browser blocks page rendering until it receives and processes all the CSS. CSS is render blocking because rules can be overwritten, so the content can’t be rendered until the CSSOM is complete.

Render Tree

The render tree captures both the content and the styles: the DOM and CSSOM trees are combined into the render tree.

To construct the render tree, the browser checks every node, starting from root of the DOM tree, and determines which CSS rules are attached.

The render tree only captures visible content. The head section (generally) doesn’t contain any visible information, so it’s not included in the render tree.

If there’s a display: none; set on an element, neither it, nor any of its descendants, are in the render tree.

Layout

Once the render tree is built, layout becomes possible. Layout is dependent on the size of screen.

The layout step determines where and how the elements are positioned on the page, determining the width and height of each element, and where they are in relation to each other.

Paint

The last step is painting the pixels to the screen.

Once the render tree is created and layout occurs, the pixels can be painted to the screen.

On load, the entire screen is painted. After that, only impacted areas of the screen will be repainted, as browsers are optimized to repaint the minimum area required. Paint time depends on what kind of updates are being applied to the render tree.

While painting is a very fast process, and therefore likely not the most impactful place to focus on in improving performance, it is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take.

Why you shouldn't use slow regular expressions

Duc Le — Sun, 26 Feb 2023 04:41:22 +0000

Introduction

Most of the regular expression engines use backtracking to try all possible execution paths of the regular expression when evaluating an input, in some cases it can cause performance issues, called catastrophic backtracking situations.
In the worst case, the complexity of the regular expression is exponential in the size of the input, this means that a small carefully-crafted input (like 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application. Super-linear regex complexity can lead to the same impact too with, in this case, a large carefully-crafted input (thousands chars).

Why it happens ?

Ask Yourself Whether

The input is user-controlled.
The input size is not restricted to a small number of characters.
There is no timeout in place to limit the regex evaluation time. There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

To avoid catastrophic backtracking situations, make sure that none of the following conditions apply to your regular expression.

In all of the following cases, catastrophic backtracking can only happen if the problematic part of the regex is followed by a pattern that can fail, causing the backtracking to actually happen.

If you have a repetition r* or r*?, such that the regex r could produce different possible matches (of possibly different lengths) on the same input, the worst case matching time can be exponential. This can be the case if r contains optional parts, alternations or additional repetitions (but not if the repetition is written in such a way that there’s only one way to match it).
If you have multiple repetitions that can match the same contents and are consecutive or are only separated by an optional separator or a separator that can be matched by both of the repetitions, the worst case matching time can be polynomial (O(n^c) where c is the number of problematic repetitions). For example a*b* is not a problem because a* and b* match different things and a*_a* is not a problem because the repetitions are separated by a '' and can’t match that ''. However, a*a* and .*_.* have quadratic runtime.
If the regex is not anchored to the beginning of the string, quadratic runtime is especially hard to avoid because whenever a match fails, the regex engine will try again starting at the next index. This means that any unbounded repetition, if it’s followed by a pattern that can fail, can cause quadratic runtime on some inputs. For example str.split(/\s*,/) will run in quadratic time on strings that consist entirely of spaces (or at least contain large sequences of spaces, not followed by a comma).

In order to rewrite your regular expression without these patterns, consider the following strategies:

If applicable, define a maximum number of expected repetitions using the bounded quantifiers, like {1,5} instead of + for instance.
Refactor nested quantifiers to limit the number of way the inner group can be matched by the outer quantifier, for instance this nested quantifier situation (ba+)+ doesn’t cause performance issues, indeed, the inner group can be matched only if there exists exactly one b char per repetition of the group.
Optimize regular expressions by emulating possessive quantifiers and atomic grouping. Use negated character classes instead of . to exclude separators where applicable. For example the quadratic regex .*_.* can be made linear by changing it to [^_]*_.*

Sometimes it’s not possible to rewrite the regex to be linear while still matching what you want it to match. Especially when the regex is not anchored to the beginning of the string, for which it is quite hard to avoid quadratic runtimes. In those cases consider the following approaches:

Solve the problem without regular expressions
Use an alternative non-backtracking regex implementations such as Google’s RE2 or node-re2.
Use multiple passes. This could mean pre- and/or post-processing the string manually before/after applying the regular expression to it or using multiple regular expressions. One example of this would be to replace str.split(/\s*,\s*/) with str.split(",") and then trimming the spaces from the strings as a second step.
It is often possible to make the regex infallible by making all the parts that could fail optional, which will prevent backtracking. Of course this means that you’ll accept more strings than intended, but this can be handled by using capturing groups to check whether the optional parts were matched or not and then ignoring the match if they weren’t. For example the regex x*y could be replaced with x*(y)? and then the call to str.match(regex) could be replaced with matched = str.match(regex) and matched[1] !== undefined.

Sensitive Code Example

The regex evaluation will never end:

/(a+)+$/.test(
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaa!"
); // Sensitive

Compliant Solution

Possessive quantifiers do not keep backtracking positions, thus can be used, if possible, to avoid performance issues. Unfortunately, they are not supported in JavaScript, but one can still mimick them using lookahead assertions and backreferences:

/((?=(a+))\2)+$/.test(
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"+
"aaaaaaaaaaaaaaa!"
); // Compliant

*References:
*
OWASP Top 10 2017 Category A1 — Injection
MITRE, CWE-400 — Uncontrolled Resource Consumption
MITRE, CWE-1333 — Inefficient Regular Expression Complexity
owasp.org — OWASP Regular expression Denial of Service — ReDoS
stackstatus.net(archived) — Outage Postmortem — July 20, 2016
regular-expressions.info — Runaway Regular Expressions: Catastrophic Backtracking
docs.microsoft.com — Backtracking with Nested Optional Quantifiers

Things you should look for in a Code Review

Duc Le — Sun, 05 Feb 2023 03:51:39 +0000

Code review, or you can call it Peer review, is an activity for Software Quality assurance, which one or several people involve to check parts of the code.

This article is sort of a guide on what to look for in a code review, so the code base can have better quality, reviewers and the author can learn from it.

Functionality

The first thing to look for in a code review is the functionality. For a feature, reviewers can look for edge cases, potential problems, to make sure no obvious bugs are visible just by looking at the code.

You can have a validation on the changes. Try the feature, or run a demo to see if there is any bugs for performance issues.

Complexity

Have you ever seen a function or a component that is too complex to even understand it in a quick look ? Even though the code can run fine, but reviewers can’t understand it quick enough might be a logic problem. There would be potential bugs if a piece of code is too complex too, and debug it will be even more painful.

We can call it Over-engineering, when a piece of code has things that isn’t presently needed by the system, engineers should be focused on things that they need to do at the moment first, not problems that might be needed to solve in the future.

Naming

Did the variables name are good ? Did functions name are good ? Did classes name are good ? A good name is long enough to fully communicate what the code is or does, without being so long that it becomes hard to read.

Comments

In my opinion, comments are commonly bad. So whenever I see comments while doing code review, I often have a lot of question for the existence of it. I wrote an article about it, right here

In short, did the developer write clear comments without errors ? Are all of the comments actually necessary? If the code isn’t clear enough to explain itself, then the code should be made simpler.

There are some exceptions (regular expressions and complex algorithms often benefit greatly from comments that explain what they’re doing, for example) but mostly comments are for information that the code itself can’t possibly contain, like the reasoning behind a decision.

Styling

Coding conventions are a set of guidelines for a specific programming language with recommended programming style and practice.

Reviewers need to make sure the changes follows the appropriate style guides.

Tests

Unless the changes are hot fixes, reviewers should ask for unit or integration or end-to-end tests.

Reviewers need to make sure the tests are useful, clear, and correct.
Don’t forget that tests are also code, we should look for all of the things above when review tests

Compliments

If the code looks good, don’t be shy, we can tell the author about it. This can encourage the developers to continue doing good stuffs

Create your first WebSockets-based application in NestJS

Duc Le — Fri, 03 Feb 2023 08:17:53 +0000

Introduction

What are Websockets

Websockets is a communication protocol which provides full-duplex communication channels over a single TCP connection established between a web browser and a web server. This allows the server to sent to the browser without being called by the client. There are many usages of Websockets, like chat app, or account balance,… Where everything needs to be update in real time

Websockets in NestJS

According to NestJS, a gateway is simply a class annotated with @WebSocketGateway() decorator. Technically, gateways are platform-agnostic which makes them compatible with any WebSockets library once an adapter is created.

Before we dive in writing the application, I assume you already know how to create a NestJS application with TypeORM implemented, if not, you can check out my tutorial right here

Set up

We are going to build a simple send and receive message app

First, we need to install some dependencies

yarn add socket.io @nestjs/websockets @nestjs/platform-socket.io

Then we will create a Gateway called MessageGateway

export class MessageGateway
  implements OnGatewayInit, OnGatewayConnection, OnGatewayDisconnect
{

}

Don’t forget to add it to our providers in MessageModule

@Module({
  imports: [TypeOrmModule.forFeature([Message])],
  controllers: [MessagesController],
  providers: [MessagesService, MessageGateway],
})
export class MessagesModule {}

Build the Server

Right now the IDE will tell you that you need to have some methods called afterInit handleDisconnect handleConnection in MessageGateway

Because this is just a simple app, and we don’t actually need to do anything in these methods, we will simply log the data out

  private logger: Logger = new Logger('MessageGateway');

  @WebSocketServer() wss: Server;

  afterInit(server: Server) {
    this.logger.log('Initialized');
  }

  handleDisconnect(client: Socket) {
    this.logger.log(`Client Disconnected: ${client.id}`);
  }

  handleConnection(client: Socket, ...args: any[]) {
    this.logger.log(`Client Connected: ${client.id}`);
  }

With this, we will know when the Server started, which client is connected and disconnected

Handle events

We need 2 events in this app, first is the sendMessage event and the second is receiveMessage event

@SubscribeMessage('sendMessage')
  async handleSendMessage(client: Socket, payload: string): Promise<void> {
    const newMessage = await this.messagesService.createMessage(payload);
    this.wss.emit('receiveMessage', newMessage);
  }

With this piece of code, we will use SubscribeMessagedecorate to subscribe to the sendMessage event. Whenever a sendMessage event occured, we will create a new message through messageService .

Then we emit this created message through receiveMessage event

Build the Client

To test the gateway, we need a client, I will use the most popular UI library out there to test it, React

We need to install socket.io since the server uses socket.io

yarn add socket.io-client

Next we will create a socket with it

import io from "socket.io-client";
const socket = io("http://localhost:3000");

Then we will implement the socket:

  useEffect(() => {
    socket.on("receiveMessage", (msg) => {
      receiveMessage(msg);
    });

    getInitialMessages();
  }, []);

  function getInitialMessages() {
    fetch("http://localhost:3000/messages")
      .then((res) => res.json())
      .then((data) => {
        setMessages(data);
      });
  }

  function receiveMessage(msg: Message) {
    const newMessages = [...messages, msg];
    setMessages(newMessages);
  }

  function sendMessage() {
    socket.emit("sendMessage", newMessage);
    setNewMessage("");
  }

You can see that on first render, I will subscribe to the receiveMessage event, to listen if there is any new event and take action with receiveMessage method. Then I get the initial messages through the get api

On receiveMessage method, I append new message to the state.

Every time we need to send a new message, we will emit sendMessage event

This will be the result:

Conclusion

This is the most basic example on how to create your first websockets app. You will know how to send and receive messages through the gateway. If the article is not that clear to you, just check out the source code

Last Words

Although my content is free for everyone, but if you find this article helpful, you can buy me a coffee here

Set up a PostgreSQL database and connect to NestJS with TypeORM

Duc Le — Mon, 30 Jan 2023 04:40:29 +0000

Introduction

The most important thing when learning backend development is how to store the data. In this article, we look into how to create a database with PostgreSQL and connect it to NestJS. To manage a database easier, we’ll use an Object-relational mapping (ORM) tool called TypeORM.

Create the database

PostgreSQL, often simply “Postgres”, is an object-relational database management system. To quickly create a PostgreSQL database, we will use Docker ( make sure you installed Docker )

First, we create the docker-compose.yml file with these configurations

Then we create the docker.env file to store environment variables:

Okay, so now we have Docker and PostgreSQL, the next thing we want to do is to connect the database with NestJS

Connecting database

Before connecting NestJS app with the database, we need to install some dependencies:

@nestjs/typeorm typeorm : 2 libraries about TypeORM
pg : PostgreSQL client
@hapi/joi @types/hapi__joi : schema validation

Then, we need to create .env file with more variables about our database and the database.module.ts to get all of the env and config TypeORM:

Beside the MessageModule , you can see I configured the schema validation with Joi and the database’s module and import them all to our root module ( app )

Entity

If you know about databases, you’ll probably know about tables, in TypeORM, the most important concept about it is Entity, it maps to a database table:

I created a simple entity called Message , you can think about it like a message table with ID is its primary key and another column is content

Let’s write some APIs

Enough of the setup, we have connected NestJS with the database and create a table. Next thing we want to do is creating the controller and the service

With TypeORM’s repository, I created some RESTful APIs with simple methods:

getAllMessages : I used the find method, you can pass a lot of options to it, if not, It will get all of the records in the table
getMessageById: we can use the find method above, but I suggest the findOne method that only return the first record that match our criteria
createMessage: a simple create method to create new message

Testing

First, we need to start Docker with docker-compose up

Then, we start our NestJS server with yarn start:dev

I used Postman to create new message, it works fine

Conclusion

In this article, we’ve gone through the basics of connecting our NestJS application with a PostgreSQL database and used TypeORM for easily managing queries.

You can find the source code here if the article isn’t clear

Last Words

Although my content is free for everyone, but if you find this article helpful, you can buy me a coffee here

How to Add JWT Authentication to NestJS Apps

Duc Le — Sat, 28 Jan 2023 05:25:06 +0000

Introduction

Authentication is an important part of our applications. From time to time, there are many ways to handle authentication. With each requirement, we find the suitable approach to handle authentication.

This article is a simple tutorial on how to implement authentication with NestJS, before go into the guide, I’m going to demonstrate the technologies that are going to be used in the guide
JWT or JSON Web Token is an industry standard RFC 7519 method for representing claims securely between two parties.
Passport is the most popular Node authentication library, well-known by the community and successfully used in many production application, NestJS has supported it outside the box with @nestjs/passport

Installation

First, we create the project

nest new your-project-name

Then we add the dependencies

yarn add @nestjs/passport passport passport-local passport-jwt @nestjs/jwt

We are going to use mongoose to store the data

yarn add mongoose @nestjs/mongoose

Generate modules, services and controllers

For the authentication, we need 2 modules AuthModule and UserModule , each of them need controller and service files

Auth module:

nest g module auth
nest g service auth
nest g controller auth

User module

nest g module users
nest g service users
nest g controller users

Define schema and interface

We need an UserSchema and an User interface, let’s create the user.model.ts file

Create User Service

We created the users.service.ts before, next we create 3 methods for the sign up ( createUser ), get all users ( getUsers ) and get an user ( getUser )

Create User Module an Controller

Nothing much to say about these files, I created 2 routes in the UsersController to sign up and get all users and import all we have with users to the users.module.ts file

Only thing to keep in mind is the @UseGuards(AuthGuard('jwt)) part, which means we can’t access this route without logged in and have the jwt

Auth Service

There are 2 methods in the AuthService , one is to validate if the user exist in our database with correct credentials, the other one is to return an access_token which is a JWT assigned with an username

Strategies

We have to create the strategies, in this guide I will create 2 strategies, one is LocalStrategy and the other is JwtStrategy

The LocalStrategy serves a purpose when we need to validate the username and password before going deeper into the controller. In this case, I create the built-in validation method with the validateUserCredentials from the AuthService

For the JwtStrategy we extend the PassportStrategy from the @nestjs/passport library just like above, then we return an object consists the username . The constructor need to extract the JWT from Header Bearer token (the access_token). We also need a secret key for JWT Strategy, mine is SECRET_KEY but I suggest you to use a more secure way to store keys.

Auth module and controller

Like the UserController above, we define the route for authentication, in this controller is the login route. You can see I used AuthGuard('local') from the LocalStrategy above. So we only proceed to login after the validation succeeded.

Nothing much to say about the auth.module.ts file, we import all the modules we need assign the providers , controllers

App module

Every NestJS project comes with the app.module.ts file that centralizes all the modules

Note: I used MongoDB Atlas to create a cloud database, but you can decide what database to use

Conclusion

Let’s try our APIs in Postman to see if it works

First, start the server with:

yarn start:dev

Then open Postman, we’re gonna start with the login route

We can see the server returns access_token for us, we will copy this into every guarded API, like the getUsers from UserController

That’s all, isn’t that hard right, you can check out my source code here.

Last Words

Although my content is free for everyone, but if you find this article helpful, you can buy me a coffee here

Why Cookie is preferable compared to localStorage when it comes to authentication

Duc Le — Tue, 27 Dec 2022 07:49:49 +0000

Introduction

We know about JWT, or JSON Web Token, as an industry standard RFC 7519 method for representing claims securely between two parties. JWT is very common nowadays. But where should we store them in the front end?

In this article, I will break down 2 common places to store tokens. Cookies and LocalStorage

Comparison

Local Storage

To use localStorage, just simply call use the localStorage object

localStorage.setItem("yourTokenName", yourToken)
localStorage.getItem("yourTokenName", yourToken)

Pros:

Very convenient, don’t need any backend, just pure JavaScript.
Big Data size, about 5mb.

Cons:

Vulnerable to XSS attacks. An XSS attack happens when an attacker can can take the access token that you stored in your localStorage because they can run JavaScript on your website.

Cookies

To set cookie , we can do:

document.cookie = "cookieName=value"

or do this with http request:

Set-Cookie: <cookie-name>=<cookie-value>

Pros:

If you’re using httpOnly and secure cookies this means that your cookies cannot be accessed using JavaScript so even if an attacker can run JS on your site, they can't read your access token from the cookie.
Can set expiration date

Cons:

Only 4kb of storage

Security concerns

XSS Attacks

Like I said above, local storage is vulnerable because it’s easily accessible using JavaScript and an attacker can retrieve your access token. However, while httpOnly cookies are not accessible using JavaScript, this doesn't mean that by using cookies you are safe from XSS attacks involving your access token.

If an attacker can run JavaScript in your application, they can just send an HTTP request to your server which will automatically include your cookies; It’s just less convenient for the attacker because they can’t read the content of the token although they might don’t have to.

CSRF Attacks

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.

However, this can be mitigated easily using sameSite flag in your cookie by including an anti-CSRF token.

Conclusion

Cookies still have some vulnerabilities but it’s preferable compared to localStorage whenever possible. Because:

Both localStorage and cookies are vulnerable to XSS attacks, but it's harder for the attacker to do the attack when you're using httpOnly cookies.
Cookies are vulnerable to CSRF attacks, but it can be mitigated using sameSite flag and anti-CSRF tokens.
You can still make it work, even if you need to use the Authorization: Bearer header or your JWT is larger than 4KB.

Improve Your Next.js App’s Performance in 10 Minutes

Duc Le — Mon, 19 Dec 2022 08:00:33 +0000

Introduction

We all know Next.js is quite heavyweight, especially compared to Svelte Kit or Nuxt.js and optimization is not everyone’s favorite thing. Your product owner might not want to waste time on optimization and prefer shipping features. Your QA and tester might not want to regression-test all the features that might be affected.

This article is a simple tutorial on Next.js optimization, so you can achieve better performance, lighthouse score… in the shortest amount of time

Relocate your third party scripts

If your app has Google Analytics, Hotjar, Facebook Pixel…or any third-party scripts. You might want to relocate those scripts onto service workers and off the main thread.

I have an article about this right here

Trust me, it won’t take long and the results might surprise you.

Use dynamic imports

Next.js supports lazy loading external libraries with import() and React components with next/dynamic. Deferred loading helps improve the initial loading performance by decreasing the amount of JavaScript necessary to render the page. Components or libraries are only imported and included in the JavaScript bundle when they're used.

next/dynamic is an extension of React.lazy. When used in combination with Suspense, components can delay hydration until the Suspense boundary is resolved.

For instance, my home page has 4 big blocks, but only one of them shows at the first load, user has to scroll to see other blocks. So I don’t want all 4 to load at first:

const Overview = dynamic(() => import('./Overview'));
const Project = dynamic(() => import('./Projects'));
const Contact = dynamic(() => import('./Contact'));

Now let’s look at the results

Before:

After:

You can see the first load JS is reduced from 115kb to 100kb, not much, but it is honest work

Preact instead of React

Next.js is built on top of React, but Preact is a JavaScript library, considered the lightweight 3kb alternative of React with the same modern API and ECMA Script support.

So if your app is just a common Next.js app, I don’t see any reason to not use Preact. Its downside is just a lack of community support.

How to implement:

First, you have to install Preact
Open your next.config.js file and reassign react:

 webpack: (config, { dev, isServer }) => {
    if (!dev && !isServer) {
      Object.assign(config.resolve.alias, {
        react: 'preact/compat',
        'react-dom/test-utils': 'preact/test-utils',
        'react-dom': 'preact/compat',
      });
    }
    return config;
  },

Now look at the performance:

The bundle size is significantly smaller.

But not just that, let’s see it in production:

Before

After

You can see all JS files are smaller.

Conclusion

There are many other ways to improve your app performance out there, but they require more work and research.

I hope the methods above work for you, if not, please comment down below and we can find the best way!

Last Words

Although my content is free for everyone, but if you find this article helpful, you can buy me a coffee here

Use your third-party scripts without the performance hit with Partytown

Duc Le — Fri, 16 Dec 2022 03:27:46 +0000

Introduction

Partytown is a lazy-loaded library to help relocate resource intensive scripts into a web worker, and off of the main thread. Its goal is to help speed up sites by dedicating the main thread to your code, and offloading third-party scripts to a web worker and optimize your page speed and lighthouse score.

Even when your website following all of today’s best practices and has the perfect lighthouse score. It’s very likely that your performance wins will be wiped out when third-party scripts are added.

Set up

According to Partytown:

Partytown is fairly different from most web development libraries in mainly what’s required for its setup and configuration. At the lowest level, Partytown can work with just vanilla HTML, meaning it doesn’t need to be a part of a build process, doesn’t need a bundler, doesn’t require a specific framework, etc. Because it can integrate with any HTML page, it also makes it much easier to then create wrapper components or plugins for almost any ecosystem, such as Shopify, WordPress, Nextjs, Gatsby and much more.

You can install the package with:

yarn add @builder.io/partytown

Example

Although Partytown can work with just vanilla HTML, but in this example, I will show you how to use Partytown with a very common frontend library that is React, or NextJS specifically and a very common third party script is Google Tag Manager for analytics.

Let’s look at my website performance at the moment ( mobile ):

You can see although other scores are high, the performance only react 69 and Lighthouse points the third party script is the main factor. So we will optimize it with Partytown right now

First, from the root index page, we only have to include type="text/partytown" for our script:

<script
 async
 type="text/partytown"
 src="https://www.googletagmanager.com/gtag/js?id=G-BDYELQMSCB"
></script>
<script type="text/partytown" id="gtm">
 {`
   window.dataLayer = window.dataLayer || [];
   window.gtag = function gtag(){window.dataLayer.push(arguments);}
   gtag('js', new Date());
   gtag('config', 'G-BDYELQMSCB',{ 'debug_mode':true });
 `}
</script>

Because gtag add a global variable to window which user code calls in order to send data to the service.

Since GTM was actually loaded in the web worker, then we need to forward these calls. The forward config is used to set which window variables should be patched and forwarded on. The forward string value is of the function to call:

<Partytown debug={true} forward={['gtag']} />

Now you can safely call window.gtag in your app.

Let’s look at the score after we implement Partytown:

The performance score is now 93, highly improved and the suggestion Lighthouse gave us is no longer there.

Conclusion

Third-party scripts are very common nowadays, especially when websites need trackers and ads like Hotjar, Google Analytics or Facebook Pixel.

I hope this article can help you improve your website performance in a very short time

Add Google Analytics to React/Next in 5 minutes

Duc Le — Tue, 13 Dec 2022 03:24:01 +0000

Introduction

Websites and applications have tons of trackers, but they serve many purposes, and some are good purposes.

Let's say you want to track how many users went to your websites, how many users actually use a feature, or how many users drop when doing certain actions.

One of the most outstanding tracking tool out there is Google Analytics. So I'm writing this article to show you how to integrate Google Analytics to your React apps.

Set up

First, you need to create a google account, which you probably have.

Then you need to inject some scripts for Google Tag Manager to your apps:

      <Script
        async
        strategy="afterInteractive"
        src="https://www.googletagmanager.com/gtag/js?id=YOUR ID"
      ></Script>
      <Script strategy="afterInteractive" id="gtm">
        {`
           window.dataLayer = window.dataLayer || [];
           function gtag(){dataLayer.push(arguments);}
           gtag('js', new Date());
           gtag('config', YOUR ID,{ 'debug_mode':true });
        `}
      </Script>

The first Script tag is to install GTM, the second tag is to config Google Tag, you need to provide your GTM id, you can enable the debug mode to inspect the actions.

Sending Events

Although by default, Google provided some events built in, like page view event or scroll to bottom event. And we can create custom events on the dashboard

But in my opinion, we should fire custom events from our code, for better behavior customization. So I created a utility for this:

type WindowWithDataLayer = Window & {
  gtag: Function;
};

declare const window: WindowWithDataLayer;

type TrackerProps = {
  eventName: string;
};

export const tracker = ({ eventName }: TrackerProps) => {
  window.gtag('event', eventName);
};

With the tracker function, we will be able to fire any event we like with a custom event name ( you can even provide parameters, just customize my function above ). This is how it can be called:

          onClick={() => {
            tracker({ eventName: 'open_projects' });
            set(open => !open);
          }}

I fired an event name open_projects on click.

I tried to fire the event multiple times to see if it works, as you can see, it works perfectly.

Conclusion

This is just a very basic tutorial on how you can implement Google Analytics to your app, you can modify the example above to send parameters, or go to google’s dashboard to create advanced events.