DEV Community: Nikhil Malik

mjs vs cjs with Event Loop

Nikhil Malik — Wed, 04 Sep 2024 06:24:55 +0000

Introduction

Hello Fellow Dev!

Today, we'll discuss the differences between .mjs (ECMAScript modules) and .cjs (CommonJS modules) in Node.js. While modern frameworks like React, Next.js, and Vue often handle module support automatically, understanding these differences is crucial when working with Node.js directly, especially regarding the event loop and execution order.

My main goal for this discussion is towards the event loop and in the next sections, we will see some cases.

Basic Information

`mjs` (ECMAScript module) supports,

import fs from 'fs'
import https from 'https'

`cjs` (CommonJS Modules) supports

const fs = require('fs')
const https = require('https')

Event Loop and Execution Order

The Node.js event loop processes different queues with specific roles and priorities. Two important functions that affect execution order are process.nextTick() and setImmediate() and we use these time to time.

process.nextTick vs setImmediate

If you know the difference between process.nextTick vs setImmediate that's great if not then, a very basic idea

process.nextTick ensures that a piece of code runs after the current function but before any asynchronous I/O operations.

setImmediate schedules a callback function to be executed in the next iteration of the event loop, after any I/O events.

So current code -> process.nextTick -> any I/O operations -> setImmediate

Code Example

Let's examine a code snippet that demonstrates the execution order:

//In case of mjs
import https from "https";
import fs from "fs";

//In case of cjs
const https = require("https");
const fs = require("fs");

setImmediate(() => {
    console.log("setImmediate callback");
});

process.nextTick(() => {
    console.log("nextTick callback");
});

fs.readFile("./async.cjs", (err, data) => {
    console.log("file IO Callback");
});

fs.readdir(process.cwd(), () => console.log("file IO Callback 2"));

https.get("https://www.google.com", (res) => {
    console.log("https callback");
});

setImmediate(() => {
    console.log("setImmediate callback 2");
});

Promise.resolve().then(() => {
    console.log("Promise Callback");
});

process.nextTick(() => {
    console.log("Process nextTick console");
    process.nextTick(() => {
        console.log("Process nextTick console 2");
        process.nextTick(() => {
            console.log("Process nextTick console 3");
            process.nextTick(() => {
                console.log("Process nextTick console 4");
            });
        });
    });
});

Promise.resolve().then(() => {
    console.log("Promise Callback 2");
});

console.log("Main thread mjs");

Promise.resolve().then(() => {
    console.log("Promise Callback 3");
});

Expected vs Actual Execution Order

The code should run and execute in this way

Main thread
Promise callbacks
nextTick callbacks
setImmediate callbacks
I/O callbacks and output should be

Main thread mjs
Promise Callback
Promise Callback 2
Promise Callback 3
nextTick callback
Process nextTick console
Process nextTick console 2
Process nextTick console 3
Process nextTick console 4
setImmediate callback
setImmediate callback 2
file IO Callback
file IO Callback 2
https callback

But is it the case with mjs?
Not Really!

This is the output wrt mjs and cjs

Similar to process.nextTick and setImmediate, we can see the same behaviour with Promises as well.

What's the reason?

Apparently, the difference in behaviour we're observing between the mjs (ECMAScript modules) and cjs (CommonJS modules) files regarding setImmediate and process.nextTick is due to how Node.js handles the event loop and microtasks in different module systems.

For ESM (.mjs):

In ESM, Node.js uses a different approach to handle the main module execution.
The main module code is wrapped in an asynchronous function, which is then executed.
This causes setImmediate callbacks to be scheduled for the next iteration of the event loop, after all microtasks (including process.nextTick and Promises) have been processed.

For CommonJS (.cjs):

In CommonJS, the main module code is executed synchronously.
This means that setImmediate callbacks are scheduled immediately and can run before some microtasks if they're queued early enough.

Framework Behaviour

I have tested this behaviour in the Express and Nextjs app (dev mode) and interestingly, Express behaved like cjs and Nextjs behaved like mjs . The first set of logs are from Express and next are from Nextjs

Conclusion

Understanding the differences in execution order between .mjs and .cjs files is crucial when working directly with Node.js. I hope, this will help you understand the difference and execution of these functions wrt files, a little bit better. So next time when you play or try these functions in your app, keep these points in mind :)

For another example, please refer to the official Node.js documentation on the differences between ES modules and CommonJS file execution.

Youtube music light themes

Nikhil Malik — Thu, 25 Apr 2024 16:54:26 +0000

Introduction

Hello fellow members!

In this article, I would like to discuss a solution for the light theme issue on Youtube Music. This article is not technical but rather a practical solution for those who prefer light themes.

I recently started using Youtube Music and noticed that the dark theme was not suitable for my eyes as an avid light theme user. I looked for a solution in the settings, Google Docs, or other resources, but there was none.

Therefore, I decided to build a script that would provide a light theme for myself and others who would like to have this option. My main aim was to create a solution that is easy to use and provides various options to the user, rather than just one. It may not be perfect, but it's a good start and will continue to improve.

Disclaimer

I have only tested this solution on desktop browsers.

(function () {
    "use strict";

    const uLight = {
        count: 0,
        limit: 10,
        currentTheme: 1,
        initStatus: false,
        textBlack: [],
        themes: [
            "#fff",
            "#f1f1f1",
            "#d8b4fe",
            "#a78bfa",
            "#0e7490",
            "#86198f",
            "#94a3b8",
            "#44403c",
            "#f43f5e",
            "#7c3aed",
            "#164e63",
            "#713f12",
            "#c2410c",
            "rgb(111 82 110 / 81%)",
            "rgb(108 165 163 / 82%)",
            "rgb(114 111 64 / 82%)",
            "rgb(151 132 132 / 82%)",
            "rgb(0 0 0)", // Dark | Always Keep it in the last to support default theme
        ],
        init: () => {
            uLight.currentTheme = uLight.localStorage();

            uLight.textBlack = uLight.themes.slice(0, 8);

            uLight.addCss();
            uLight.createThemes();
            if (uLight.currentTheme != uLight.themes.length - 1) {
                uLight.pluginInit();
            }
        },
        pluginInit: () => {
            if (uLight.initStatus) return;

            uLight.initStatus = true;
            setTimeout(() => {
                document
                    .querySelector("yt-page-navigation-progress")
                    .addEventListener("DOMSubtreeModified", () => {
                        uLight.checkProgress();
                    });
            }, 1000);
            uLight.fixBackground();
            uLight.setTheme(uLight.currentTheme);
        },
        localStorage: (theme = null) => {
            if (typeof Storage !== "undefined") {
                if (theme != null) {
                    uLight.currentTheme = theme;
                    localStorage.setItem("uLight-theme", theme);
                } else
                    return (
                        localStorage.getItem("uLight-theme") ||
                        uLight.currentTheme
                    );
            }
            return uLight.currentTheme;
        },
        fixBackground: () => {
            uLight.setProperty(
                document.querySelector(
                    "ytmusic-browse-response[has-background]:not([disable-gradient]) .background-gradient.ytmusic-browse-response"
                ),
                "background",
                "var(--ytmusic-background)"
            );
        },
        checkProgress: () => {
            if (
                uLight.count == uLight.limit ||
                document
                    .querySelector("yt-page-navigation-progress")
                    .attributes.getNamedItem("aria-valuenow").value == "100"
            ) {
                uLight.fixBackground();
                uLight.count = 0;
            } else {
                uLight.count++;
                uLight.checkProgress();
            }
        },
        removeStyle: (id) => {
            const styleSheet = document.getElementById(id);
            if (styleSheet) {
                styleSheet.remove();
            }
        },
        createStyle: (style, id = null) => {
            const styleSheet = document.createElement("style");
            styleSheet.id = id || new Date().getTime();
            styleSheet.innerText = style;
            document.head.appendChild(styleSheet);
        },
        addCss: () => {
            let pStyles = "";
            uLight.themes.map(
                (t, i) =>
                    (pStyles += `
                .uLight-theme-container p:nth-child(${i + 1}) {
                    background: ${uLight.themes[i]};
                }
            `)
            );
            const style = `
                .icon.ytmusic-menu-navigation-item-renderer {
                    fill: #000;
                }
                picture.ytmusic-fullbleed-thumbnail-renderer img {
                    opacity: .4;
                }
                .uLight-theme-container {
                    position: absolute;
                    right: 20px;
                    top: 20px;
                    display: flex;
                    flex-direction: column;
                }
                .uLight-theme-container p {
                    width: 20px;
                    height: 20px;
                    border-radius: 50%;
                    cursor: pointer;
                    margin-top: 6px;
                    border: 1px solid;
                }
                ${pStyles}
            `;
            uLight.createStyle(style);
        },
        trustedTypes: () => {
            if (window.trustedTypes && trustedTypes.createPolicy) {
                return trustedTypes.createPolicy("uLightPolicy", {
                    createHTML: (string) => string,
                });
            }
            return null;
        },
        createThemes: () => {
            const themeElement = document.createElement("div");
            themeElement.className = "uLight-theme-container";
            let themeOptions = "";
            uLight.themes.map(() => (themeOptions += `<p></p>`));
            themeElement.innerHTML = uLight
                .trustedTypes()
                ?.createHTML(themeOptions);
            document.querySelector("ytmusic-nav-bar").appendChild(themeElement);
            setTimeout(() => {
                uLight.addEvents();
            }, 500);
        },
        addEvents: () => {
            document
                .querySelectorAll(".uLight-theme-container p")
                .forEach((p, index) => {
                    p.addEventListener("click", (e) => {
                        uLight.setTheme(index);
                    });
                });
        },
        setTheme: (theme) => {
            let color;
            color = uLight.themes[theme];

            const cleanColor = color.endsWith(")")
                ? color.split("/")[0].replace(")", "") + ")"
                : color;

            uLight.setProperty(
                document.querySelector("html"),
                "--ytmusic-color-black4",
                cleanColor
            );
            uLight.setProperty(
                document.querySelector("html"),
                "--ytmusic-color-black1",
                "var(--ytmusic-color-black4)"
            );
            uLight.setProperty(
                document.querySelector("body"),
                "background",
                color
            );
            uLight.setProperty(
                document.querySelector(
                    "ytmusic-search-box[is-bauhaus-sidenav-enabled]"
                ),
                "--ytmusic-search-background",
                cleanColor || "#fff"
            );
            uLight.setProperty(
                document.querySelector(".cast-button.ytmusic-cast-button"),
                "--iron-icon-fill-color",
                "#000"
            );
            if (uLight.textBlack.includes(color)) {
                uLight.createStyle(
                    `
                * {
                    color: #000 !important;
                }`,
                    "uLight-text-black"
                );
            } else {
                uLight.removeStyle("uLight-text-black");
            }

            uLight.localStorage(theme);

            uLight.pluginInit();
        },
        setProperty: (selector, key, value, type = "style") => {
            if (selector) selector[type].setProperty(key, value);
        },
    };
    uLight.init();
})();

ysmnikhil / youtube-music-light-themes

Youtube music light themes

This project contains the file related to the blog. To know more information about this please go to this blog Dev.to

View on GitHub

How to use it?

Here's a step-by-step guide on how to use the script to get a light theme on Youtube Music:

Copy the script provided.
Paste it into the Youtube Music console in your browser.

You will see some options like next screenshot in your desktop and once you will click on these coloured dots, you will see the colours will change.

However, this step requires you to do it every time you visit or refresh the page. To fix this, there are various options available, such as using the Tampermonkey Chrome extension. You can choose whatever you prefer.

Then, copy the entire script with headers (which are very important) from the GitHub repo and use it with your browser plugin.

Now, the light theme will work like a charm and be available all the time in the same browser.

Varnish Caching and 503 | Backend Fetch Failed

Nikhil Malik — Sun, 07 May 2023 07:10:22 +0000

Introduction

Hello fellow developers!

With this, I will discuss the famous Varnish error which haunts people with various names

5xx(503)
Backend Fetch Failed
Guru meditation error

We also faced the same issue and it was very difficult to understand and there was no direct solution to fixing it. So I would like to share with you the steps we took to find out why the error occurred.

Prerequisites

You should have knowledge of these

Varnish
Nginx (Basic, depending on your configuration if you are using it as a middle service for Varnish to the Backend)
Logs (I use Elasticsearch Kibana)

I am already assuming you already know about all the above, so I will add very little information about the stacks and the way in which the problem will be addressed.

What is Varnish?

Varnish is a caching HTTP reverse proxy. You can install it on any HTTP server and configure it to cache the contents.

What is Nginx?

Nginx is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability.

Although it can work as so many things but I am treating it as a web server as reverse proxy, we are using Varnish.

What is Kibana?

Kibana Kibana is a free and open frontend application that sits on top of the Elastic Stack, providing search and data visualization capabilities for data indexed in Elasticsearch. Commonly known as the charting tool for the Elastic Stack.

I am using Elastic search for the logs and Kibana for the visualization, you can use any other stack as per your choice. Our main purpose is to understand the logs and gain meaningful insight.

Problem Statement

The website shows 50x error with message Backend fetch failed. It's usually found on blogs or github issues for various platforms, such as WordPress and Magento, when backend teams are trying to enable it, but it's not a specific issue for either platform. The issue occured in my case because of some changes to the data that increased the request, response, and header values. It could also happen with a well-run system, and we must constantly monitor it.

I have the following environment as a reference:

Varnish in a Docker container (it uses Nginx to communicate with the backend)
The backend is in a different container
for logging, I use Elastic search (Kibana)

Error Behaviour

This issue could happen for various reasons and we can see different behaviour of the errors

If the error is persistent or showing for all the requests, it means there are higher chances that your varnish is unable to reach the backend at all so in that case, we need to focus more on the connection between these services.
If the error is intermittent, then the connection between varnish and the back end is working fine and there are other things to consider. There could be a few requests which are not compatible with the current varnish configuration and we need to tweak those as it's not failing all the time.

Solution

To find the solution, we can consider two options

Hit and Try
Find the truth.

Before that, let's discuss the reasons for this error.

Understand the reason

There could be various reasons for these errors. Let me give a few examples, which I found are the common cases which the majority of people face. We can have an error if these values are higher than the defined one in the Varnish config

Delay in the first or in-between byte Varnish receives from the backend. For it we will focus on the 'bytes' and time_first_byte values.
The header size of your request or response. We will focus on our headers from requests and responses.
The request or response size of the request. In this case, we will focus on the content of the whole request or response body, for example API requests are not paginated at all.
The request is taking longer to communicate between Varnish and the Backend. For it, we will focus on request_time and work on the 'connect_timeout' parameter of varnish

Hit and try

Based on the previous mentioned reasons, we can tweak the Varnish configuration and test if the solution works for us and then proceed. After increasing these values slightly, it should solve your issue. I am adding a sample solution covering all the mentioned parameters.

// Please remove the new line, it's just for clear display
varnishd
 -p connect_timeout=15 // Reason 4
 -p first_byte_timeout=90 // Reason 1
 -p between_bytes_timeout=120 // Reason 1
 -p http_req_hdr_len=64k // Reason 2 & 3
 -p http_req_size=256k // Reason 2 & 3
 -p http_resp_hdr_len=64k // Reason 2 & 3
 -p http_resp_size=256k // Reason 2 & 3
 -p timeout_idle=10 // Works with Reason 4
 -p workspace_backend=256K // Reason 2 & 3
 -p workspace_client=256k // Reason 2 & 3

Note: all the definitions are available on Varnish Doc

To find the default Varnish value, we can look at these files

CentOS 6: /etc/sysconfig/varnish
CentOS 7: /etc/varnish/varnish.params
Debian: /etc/default/varnish
Ubuntu: /etc/default/varnish

Find the truth.

In the previous step, I proposed that, we can directly try these values and increase a bit and proceed but what about if we want to know the exact reason or the value we want to put should be close to what our application wants not something random and most importantly to understand the actual reason?

To find the solution, first we need to enable logs. It is always helpful to have logs for the service otherwise it's very challenging to procced and we will be just trying bliendly. Logs will play crucial role in finding out the real culprit and useful for both the behaviour of error. We will try to make sense of the logs and find what values are appropriate for our Varnish config. For it we will need these logs

Enable Varnish logs

Varnish logs consist of the requests which Varnish will handle and can provide various information like status (503) or caching status or bytes. There are several ways to get the Varnish logs.

varnishlog it's also easy to use and gives clear information on the logs but I found it challenging to use with a logging service as I couldn't format the output.

varnishlog -q 'RespStatus > 499' -g request

varnishncsa it's easy to use and you can provide the format for the logs which you can easily parse in the logging service.

varnishncsa -q 'RespStatus > 499' -g request

To format the logs with more information, we can use something similar to this

// Please remove the linebreak as it could mess with your logging service parsing
// -c for the client reqeusts
// -b for the backend requests
// -E for the esi reqeusts
// -F for the format for the output
varnishncsa -c -b -E -F '{
        "@timestamp": "%{%Y-%m-%dT%H:%M:%S%z}t",
        "@fields" : {
        "client":"%h",
        "remote_user" : "%u",
        "x_forwarded_for" : "%{X-Forwarded-For}i",
        "hit_miss":" %{Varnish:hitmiss}x",
        "bytes": %b,
        "time_first_byte" : "%{Varnish:time_firstbyte}x",
        "duration_usec": %D,
        "status": %s,
        "request":"%r",
        "url":"%U",
        "query":"%q",
        "virtualhost":"%{host}i",
        "method":"%m",
        "handling" : "%{Varnish:handling}x",
        "referrer":"%{Referrer}i",
        "user_agent":"%{User-agent}i"
    }
}'

Generated logs with Kiabana

You can use a similar kind of format to generate the logs which will give you a clear idea about the requests. Based on the status you can filter the requests.

// you can filter in Kibana and it will display all the logs which have status more than 499, means all 50x
status > 499

Enable Nginx logs (optional)

If you are using Nginx then with its logs, we can have more information about the requests. With this, we can focus on a few parameters which are not available with the Varnish logs.

log_format apm '{'
    '"logsType":"Nginx", '
    '"time":"$time_local", '
    '"client":"$remote_addr", '
    '"method":"$request_method", '
    '"host":"$host", '
    '"request":"$request", '
    '"request_length":"$request_length", '
    '"status":"$status", '
    '"bytes_sent":"$bytes_sent", '
    '"body_bytes_sent":"$body_bytes_sent", '
    '"referer":"$http_referer", '
    '"user_agent":"$http_user_agent", '
    '"upstream_addr":"$upstream_addr", '
    '"upstream_status":"$upstream_status", '
    '"request_time":"$request_time", '
    '"upstream_response_time":"$upstream_response_time", '
    '"upstream_connect_time":"$upstream_connect_time", '
    '"upstream_header_time":"$upstream_header_time"'
'}';

access_log /dev/stdout apm;

Note: all the definitions are available on Nginx Docs

Generated logs with Kiabana

Update the configuration.

After checking the logs, we can track the actual parameter causing this issue and increase the respective value. We can use a bit higher value than what our logs are showing. I am again adding a sample solution which covers all the mentioned parameters.

// Please remove the new line, it's just for clear display
varnishd
    -p http_req_size=256k
    -p http_resp_size=256k
    -p workspace_backend=256K
    -p workspace_client=256k

References

Final notes

I appreciate you reading the article! And I hope it will help you to fix it. Feel free to comment and let me know if you have any questions.

I'd be pleased to connect with you on LinkedIn

How to use React or Vue with Vite and Docker

Nikhil Malik — Wed, 25 Jan 2023 12:03:18 +0000

Introduction

Hello fellow developers!

With this guide, we will be creating a project that includes React or Vue as the front-end framework and Vite as the server, and Docker as the development environment.

[Update 16th Aug 2024]

Added the Resource Section

Prerequisites

These should be available on the host machine

Node
Docker, Docker Compose (In any form CLI / Desktop client)

Basic knowledge of

React
Vite
Docker
Makefile (not mandatory, just to make life easier)

These definitions will be in the references of the article and give you a very small idea of these terms. For more information, use the links provided with the definitions.

What is Vite?

Vite is a revolutionary frontend development tool that provides a more rapid development environment for developers as compared to existing solutions.

Vite uses source code over native ESM. And by using ES build and ESM under the hood, Vite enhances startup speed 10-100x.

This supports almost every frontend framework, react, vue, and so on.

I suggest you go ahead and look at their website and specifically this one

What is Docker?

Docker is an environment provider for your application regardless of the technology and it separates that from the host (based on your choice).

Although it does so many things and makes the life of dev to ops very easy. I will leave those things to you.

What is Makefile?

Make is a Linux utility that allows us to bind multiple shell commands to a single command. The Makefile is used for it.

We can use package.json > scripts for the same as well but I prefer to use it as it works with non-node projects as well.

Let's Start.

Step 1: Create the project

First, we will use this command to create a Vite project

npm create vite@latest

In this step, it will ask you these questions

App Name
Js Framework - React / Vue ..
Framework Variant - Javascript / TypeScript

Choose accordingly. I have selected React for now.

Note: I am using node version v17.8.0

Step 2: Update Vite Config

We need to specify the host and port in vite.config.js in order to work with the Docker.

export default defineConfig({
 plugins: [react()],
 server: {
   host: true,
   port: 8000, // This is the port which we will use in docker
   // Thanks @sergiomoura for the window fix
   // add the next lines if you're using windows and hot reload doesn't work
    watch: {
      usePolling: true
    }
 }
})

Step 3: Setup Docker

I am intending to use docker-composer for it as it's easier to scale as compared to relying on Dockerfile.

First, we will add docker-compose.yml within the root of the project.

version: "3.4"
services:
 vite_docker:
   image: node:alpine
   container_name: vite_docker
   entrypoint: /bin/sh
   ports:
     - 8000:8000
   working_dir: /srv/app
   volumes:
     - type: bind
       source: ./
       target: /srv/app
   tty: true

This is pretty straightforward from the labels. I am adding the meaning again.

image: node:alpine

Docker will choose the node:alpine image to build this env. You can choose node:lts, node:latest but I prefer alpine as it's small in size and suitable for production as well.

container_name: vite_docker

The container name will be vite_docker which we will use to execute future commands and refer to this application.

entrypoint: /bin/sh

The entry point refers to the application that will execute at the time of entry within the container. It could be /bin/bash etc but as I am using an Alpine image, you have to add those dependecies.

ports

The ports on which the application will run, in our case 8000, and with this mapping, we will be able to access the host machine using the same port.

working_dir

The working_dir is the directory for the project within the container. When you log into the container, you will land in this directory.

volumes

The key configuration here is the volumes. This will allow us to use the host file within the container and we will be able to work on it by building or restarting the container.

Here I am using type: bind which allows us to do this and update the files within the container as we update/ add anything in the host and vice versa.

Also with this, you need to build and run it every time as you will modify the host.

   volumes:
     ./: /srv/app

It is useful in other situations, but avoids syncing between hosts and containers.

tty

The tty is used to run the container continuously.

Step 4: Build the Docker Container

So far, we have added scripts to build our environment and have these files in our project.

Run this command to build the image on your local machine and start the container. You only need to run this command the first time, and whenever you make changes to docker-compose.yml.

docker-compose up --build --no-recreate -d

From the second time, we can use

docker-compose up -d

Now our container is up and you should be able to test it using the following command.

docker-compose ps

This is what it should look like

Step 5: Build and start the Application

Just to clarify, we have a running container, but not the installed or running react app. For that, we need to log into the container and then execute the commands.

docker exec -it vite_docker sh

We have entered the container and now need to run the commands to install the Node packages and start the app.

npm i && npm run dev

It will install the packages and the application will run on the defined ports.

I already had the packages so it is not showing the logs related to the packages.

These will be the files in the project. Please ignore Makefile (it's a bonus for later :) )

and the running app

Step 6: Modification in the project files

So far, everything has been running smoothly. Using the browser, we can access the project from the host after creating the Docker container and installing the app packages.

But that's not everything, right?

What about changing the heading Vite + React or adding new components and different layouts? Also, we don't want to rebuild the container every time we make any changes and we are doing it to make our life easier, not difficult :)

Let's do it.

Video

With this, we can see the changes from the host are getting reflected in the container (due to volumes > bind) and we can see those changes in the browser without any build or restarting of the container and Vite is doing its job perfectly.

Resources

Important files and you will do the remaining work and learn

GitHub Link for the files

Lazy like me :) Working Project with updated docker compose config

With this you can clone the project and start working directly. This project depends on these utilities

docker && docker compose (https://docs.docker.com/compose/install/#installation-scenarios)
make or node (on host machine)

These will be the commands which you need to execute

If you have the make utility

// Only first time 
make first

// All the time
make start

If you have the node installed in the host. This will also run the docker commands

// Only first time 
npm run first

// All the time
npm run start

GitHub Link for the Branch

Bonus

Throughout all the steps, we worked through various commands. If you are familiar with Docker, then that is great. Otherwise, it may seem overwhelming at first.

Therefore, I always prefer using something that allows me to combine these commands into one, with a more meaningful name or whatever I prefer.

Makefile

Here comes the Makefile, so with this you will need an extra utility on your OS but it will be very helpful. Make utility is used to combine various shell commands into one. Using what we did in steps 4 and 5, we can combine everything into a single command.

To install and run the dev server, we can have this

make first
// make is the utility
// first is command from the Makefile

And next time, we can always use

make start

There are various other commands related to restart, clear, stop which we can use to simply execute multiple commands at once.

and the commands are in the Makefile

CURRENT_DIR=$(patsubst %/,%,$(dir $(realpath $(firstword $(MAKEFILE_LIST)))))
ROOT_DIR=$(CURRENT_DIR)
CURRENT_USER=
DOCKER_NAME=vite_docker
DOCKER_COMPOSE?=docker-compose
DOCKER_EXEC_TOOLS_APP=$(CURRENT_USER) docker exec -it $(DOCKER_NAME) sh
NODE_INSTALL="npm i"
SERVER_RUN="npm run dev"


.PHONY: build install dev up start first stop restart clear


build:
 $(DOCKER_COMPOSE) up --build --no-recreate -d


install:
 $(DOCKER_EXEC_TOOLS_APP) -c $(NODE_INSTALL)


dev:
 $(DOCKER_EXEC_TOOLS_APP) -c $(SERVER_RUN)


up:
 $(DOCKER_COMPOSE) up -d


start: up dev
// this will up the docker env and run the npm run dev it to


first: build install dev
// this will build the env, up it and run the npm install and then run npm run dev it to


stop: $(ROOT_DIR)/docker-compose.yml
 $(DOCKER_COMPOSE) kill || true
 $(DOCKER_COMPOSE) rm --force || true


restart: stop start dev


clear: stop $(ROOT_DIR)/docker-compose.yml
 $(DOCKER_COMPOSE) down -v --remove-orphans || true

Note: You can always use package.json > scripts as a complete/ partial replacement for Make.

Final notes

I appreciate you taking the time to read the article! Feel free to comment if you have any questions.

I'd be pleased to connect with you on LinkedIn

DEV Community: Nikhil Malik

mjs vs cjs with Event Loop

Introduction

Basic Information

mjs (ECMAScript module) supports,

cjs (CommonJS Modules) supports

Event Loop and Execution Order

process.nextTick vs setImmediate

Code Example

Expected vs Actual Execution Order

What's the reason?

For ESM (.mjs):

For CommonJS (.cjs):

Framework Behaviour

Conclusion

Youtube music light themes

Introduction

Disclaimer

ysmnikhil / youtube-music-light-themes

Youtube music light themes

How to use it?

Varnish Caching and 503 | Backend Fetch Failed

Introduction

Prerequisites

What is Varnish?

What is Nginx?

What is Kibana?

Problem Statement

Error Behaviour

Solution

Understand the reason

Hit and try

Find the truth.

Enable Varnish logs

Enable Nginx logs (optional)

Update the configuration.

References

Final notes

How to use React or Vue with Vite and Docker

Introduction

[Update 16th Aug 2024]

Prerequisites

What is Vite?

What is Docker?

What is Makefile?

Let's Start.

Step 1: Create the project

Step 2: Update Vite Config

Step 3: Setup Docker

Step 4: Build the Docker Container

Step 5: Build and start the Application

Step 6: Modification in the project files

Resources

Important files and you will do the remaining work and learn

Lazy like me :) Working Project with updated docker compose config

Bonus

Makefile

Final notes

`mjs` (ECMAScript module) supports,

`cjs` (CommonJS Modules) supports