DEV Community: 💻 Bleeding Code-By John Jardin

JavaScript's Clipboard Copy: Crafting with AI

💻 Bleeding Code-By John Jardin — Fri, 07 Jul 2023 11:20:57 +0000

When it comes to JavaScript, the devil is often in the details. Even seemingly simple functions can contain a world of complexity, especially when we aim to make our code robust, reusable, readable, and adaptable to varying browser capabilities.

Take, for instance, a function that copies text to the clipboard. It might seem straightforward, but there are multiple aspects to consider: What if the Clipboard API is not supported? How can we handle different types of input?

Enter Artificial Intelligence

To address these questions, I embarked on a journey to craft a copyTextToClipboard function that could stand the test of real-world applications. I had an AI partner on this journey: GPT-4.

So why choose this particular function? While I haven't encountered issues with existing Copy To Clipboard functions, the goal was to create one that not only functions effectively but is also built according to the latest JS standards and best practices.

Here's what we developed (Note: Click here to open the below code on CodePen.io)

/**
 * Copies the provided text to the clipboard.
 *
 * @param {string} text - The text to be copied to the clipboard.
 * @returns {Promise} A promise that resolves when the text has been successfully copied, or rejects when an error occurs or the Clipboard API is not supported.
 */
const copyTextToClipboard = (text) => {
  return new Promise((resolve, reject) => {
    // Check if the text is a string and not empty.
    if (typeof text !== "string" || text.trim() === "") {
      reject(new Error("Invalid text: Text should be a non-empty string."));
      return;
    }

    // Check if the Clipboard API is supported.
    if (!navigator.clipboard) {
      reject(new Error("Clipboard API not supported"));
      return;
    }

    // Try to write the text to the clipboard.
    navigator.clipboard
      .writeText(text)
      .then(resolve) // If successful, resolve the promise.
      .catch(reject); // If an error occurs, reject the promise with the error.
  });
};

So, why should you consider using this function over others? Here are some key reasons:

Robust Error Handling: This function checks if the Clipboard API is supported and ensures that the text to be copied is a non-empty string. This makes it more robust against potential misuse.
Asynchronous Operation: The function leverages JavaScript Promises for asynchronous execution, making it compatible with async/await syntax and suitable for applications that need non-blocking operations.
Code Best Practices: The function is designed with modern JavaScript best practices in mind, from the use of const for function declaration, arrow functions, to template strings.

Learn To Prep AI Before Asking Questions

Working with GPT on this was quite an experience. I learned the hard way that it's essential to define GPT's persona and provide as much context as possible-the more precise and specific the instructions, the more satisfactory and applicable the results.

Here's an example of what I asked GPT:

Act as a JavaScript Developer using the latest stable ECMA Script standards that are supported on modern browsers. You only write robust, reusable, readable, well-documented, performant, and secure code that conforms to best practices for production environments. Perform a code review of the following JavaScript function and if it fails your standards and practices, rewrite it with explanations of what you changed and why:

I then pasted a version of copyTextToClipboard that I felt was quite good.

In response, GPT not only followed my instructions but also added additional value, enhancing readability, reusability, and error handling in the function. The collaboration resulted in a piece of code I was happy to add to my project.

Considerations

It's important to understand the caveats when working with a function like this:

The use of the Clipboard API: The Clipboard API requires permission and only works in a secure context (HTTPS), which could limit the usability of your function in some situations.
Browser Compatibility: Although the Clipboard API is widely supported, there may be compatibility issues with older browsers or less popular ones that do not fully support this API.
Performance: While this function is unlikely to be a performance bottleneck, one has to keep in mind that varied results could occur depending on the size of the text to be copied.

Closing

As we continue to adopt AI tools like GPT and Google Bard in our coding journeys, we not only enhance our coding practices but also create new opportunities for innovation and improvement.

Feel free to use this function in your projects and, more importantly, reference this function on CodePen.io for the latest version.

Till next time - John 🙂

Finally!! A Blockchain For Any Programming Language (Video)

💻 Bleeding Code-By John Jardin — Thu, 18 Aug 2022 12:51:53 +0000

I have exciting news for any developer who programs using a modern language like JavaScript, Python, C#, etc.

A new blockchain called QANplatform allows you to design Smart Contracts using your existing skillset and programming environment. And even better, the blockchain automatically pays you royalties in crypto if your contracts are generic so that other applications can use them.

In this video, I discuss problems with Web3 and how the QANplatform will solve many of them. Whether you’re a technical or non-technical person, you must understand what’s coming, so you can take full advantage as a developer and a business.

Video Chapters

0:00 Intro
0:39 How I started with Web3 as a NodeJS Dev
1:41 The problem with Web3 preventing Mass Adoption
11:44 How can we fix Web3 for Mass Adoption
20:15 What is the QANplatform
23:55 Unique features that QANplatform offers
33:58 A message from John Jardin
34:31 How QANplatform benefits developers and businesses
51:11 Final Notes about the QANplatform

Reference Links

What is the DeSo Blockchain 💎 | Post-2-Earn Crypto

💻 Bleeding Code-By John Jardin — Mon, 02 May 2022 11:36:47 +0000

In this tutorial, you will learn exactly what DeSo is, how it compares to applications like Twitter and Facebook, how you can earn crypto just by posting a message and why it's the future of social media.

What is DeSo

DeSo stands for Decentralized Social and is a new kind of internet where all social media content exists openly on a blockchain. Because the content is on a blockchain, which is scaled across many computers all around the world, no one person or central authority can own the data, hence the term Decentralized.

Centralized vs Decentralized

You might be wondering, "Is DeSo then like Twitter or Facebook"? And the answer is "no", because DeSo is so much bigger. To understand it, let's use the following example:

When you posted a Tweet on Twitter's website, did that tweet appear on Facebook, Instagram or LinkedIn? It didn't. This is because behind the Twitter app is a platform that is owned by Twitter, where all tweets, user profiles, images and videos are stored. Twitter is what is known as a centralized social media platform, because they own the data and govern what content or user accounts can exist. Nearly every other social media platform at present falls into this category.

The problem with this setup is that you, the User, have become the product and advertisers, the Customer. Absolutely everything you say and do on these platforms is analyzed by the company that owns it. This data is then used to sell targeted advertising and worse, influence you via your social feed to better benefit advertisers.

A new kind of Social Media

But what if your post didn't exist only on Facebook's platform, but rather on an open platform that can be used by any social media application? What if you were a Twitter user and decided to start using Instagram, but instead of having to create a new account there, and rebrand yourself on a new platform, your current profile, followers, who you're following and all your activities are automatically available. You would be able to continue on Instagram where you left off on Twitter.

DeSo is the solution that makes all of this possible and eliminates the downsides of a centralized social media platform. It's not a Facebook or Twitter lookalike, but rather, it's the underlying system that stores and manages all content that would be created and referenced by social media applications.

On DeSo, you will only ever need a single user account to access any of the applications that have been developed on the DeSo blockchain. Everything you say and do on any of the applications will be linked to your account.

Applications on the DeSo Blockchain

At the time of this tutorial, there are over 200 applications that exist on the DeSo blockchain. A few that are worth mentioning are:

Diamond App

Diamond is one of the first applications to be developed on DeSo. Diamond's features are similar to Twitter, in that you can post, like, retweet, follow and send direct messages. However, because Diamond is built on top of a blockchain, there are a number of additional features:

Using DeSo's crypto coin ($DESO), you can reward users crypto for their posts or be rewarded for yours

Any post can also be converted into a NFT, which can be transferred, sold or auctioned on the DeSo blockchain

Every user profile has their own crypto token called Creator Coin. This allows others to invest in you as a content creator and vice versa

Overclout

Overclout is similar to Diamond, but allows you to post stories, livestream or create rich text content such as articles and tutorials.

DeSocialWorld

DeSocialWorld provides social media content in multiple languages.

Mousai

Mousai allows you to stream music and invest in your favorite artists.

Entre

Entre is a professional network similar to LinkedIn.

These are but a few of the many applications that exist on the DeSo blockchain and the list continues to grow.

Closing

With decentralized content, post-2-earn capabilities and a vast range of social media applications, DeSo has become a blockchain like no other and is truly the future of social media.

How To Create Your First Flow In Node-RED

💻 Bleeding Code-By John Jardin — Tue, 25 May 2021 04:48:37 +0000

This post introduces a deep dive video tutorial where I teach you the fundamentals of Node-RED and at the same time, show you how to build a Weather Forecast Dashboard. To make the dashboard work, we'll need to integrate with 3 online APIs that will provide the current weather forecast, a 5 day forecast, and information about the country connected to the town or city being searched.

This video tutorial shows you step by step, how we bring these APIs together in Node-RED, to produce a weather service in the form of a UI dashboard. Once you've completed this tutorial, you will have a good enough understanding of Node-RED, enough to be able to get up and running with your own flows.

NOTE: This is my first deep dive video and I would really appreciate honest feedback as to if this kind of content adds value and if yes, how can I better it for future videos to come.

NOTE: Also see below references to mentioned websites, online tools as well as GitHub resources for the Node-RED Weather Dashboard.

Video Tutorial

References

Advanced Setup Of Node-RED In Easy Steps

💻 Bleeding Code-By John Jardin — Thu, 20 May 2021 03:53:58 +0000

In this article I'm going to show you how to install a Node-RED Server that includes optional advanced capabilities, that are not available by default with the standard installs mentioned in Node-RED's documentation.

If you're following my Up and Running with Node-RED series, you'll know that my intention is to teach you how to use Node-RED as a tool for business app development and integration, instead of just home automation and hobby-based projects. To achieve this, we cannot setup Node-RED the traditional way, which is installing it as a global module on our local machine. We need more control and flexibility. For example:

To run multiple instances of Node-RED
To containerize and deploy to various on-prem and cloud environments
To integrate with 3rd party services

Everything needs to be achievable from one Node-RED instance, and today's install will give us just that.

Watch Video On YouTube

Node JS and NPM Required

To start, you need to have at least Node JS 12.18 or higher installed on your machine. If you have an older version or don't have Node installed, I highly recommend using a Node Version Manager to be able to install one or multiple versions of Node. There are many great Version Managers out there, but for an immediate recommendation, NVM is one that we at Agilit-e use and it works very well. Not only will you be able to easily switch between various versions of Node, but NVM also takes care of permission issues on your Operating System that sometimes occur when installing Node directly.

Find "agilite-node-red" on GitHub

Now, the boilerplate Node-RED server we're going to be using can be found on GitHub and is called agilite-node-red. This repo is maintained by the team at Agilit-e and provides the control and flexibility mentioned earlier.

Download Relevant Version

Once the boilerplate repo is open in your browser, switch the branch from Master to 7.3.1. This is the current boilerplate version as per the release of this article, is compatible with Node 12.18 and runs Node-RED 1.3.4. Should you be reading this article long after it was released, you can switch to newer branches which will support upgraded versions of Node and Node-RED. Reference the README file for these versions.

Once you've switched to branch 7.3.1, click on the Code button, following by clicking on download zip to download the boilerplate to your local environment. One downloaded, extract the zip file, which will extract the boilerplate to a folder called agilite-node-red-7.3.1.

Install Node Modules

Via your Terminal or Command Prompt, navigate to the boilerplate folder and run the following command npm ci - only=production. This installs the main project dependencies based on the package-lock.json file and ignores the dev dependencies which you don't need. This ensures the boilerplate's node modules are installed the way we intended, to avoid possible inconsistencies and problems.

Once the NPM install is complete, enter the command npm run main. This starts up the Node-RED server, which you can now access by opening your preferred web browser and entering the URL: http://localhost:6020. If all was successful, you will see the Node-RED Editor open in your browser's window. You are now ready to start using Node-RED.

Closing

As mentioned before, this boilerplate offers everything of Node-RED and more, which I'll be taking everyone through step by step in my Up and Running with Node-RED series. So if you haven't yet, be sure to subscribe to my YouTube channel, or alternatively follow me on this site. In the meantime though, I welcome you to peruse the configuration for this boilerplate, which can be found in the config/templates folder, in a file called default-config.json. This is where much of the magic happens, but more on that very soon.

Until next time though…cheers :)

Visual NodeJS Programming Using Node-RED

💻 Bleeding Code-By John Jardin — Thu, 13 May 2021 04:40:53 +0000

In this article I'm going to introduce you to a NodeJS module that allows you to create and deploy server-side processes by using a visual, drag n drop style interface in your Web Browser. The module I'm referring to is called Node-RED: A flow-based programming tool that allows you to design processes (aka Flows) by wiring together microservices.

Watch The Video on YouTube

Created in 2013, Node-RED was initially intended for visually wiring together the Internet of Things, but as it matured, it evolved into something way more powerful, enough to be deployed as middleware within enterprise production environments. The power behind Node-RED is how it hides boilerplate code from the design interface, allowing you to quickly build and deploy processes and integrations.

To demonstrate this, I'm going to compare a simple Node App with a Node-RED Flow, which will show you the time saving to be had and why you should be excited to learn this tech:

Simple NodeJS Express App

The code below is for a simple Express application that outputs Hello World.

server.js

const Express = require('express')
const App = Express()
const HTTP = require('http')
const Cron = require('node-cron')
const Functions = require('./functions')

// Create Route
App.get('/api/greet', (req, res) => {
   const result = Functions.greet()
   res.send(result)
})

// Start Server
const port = 6025
HTTP.createServer(App).listen(port, () => {
   console.log('NodeJS App Listening on: ', port)

   // Schedule CRON Job
   Cron.schedule('*/5 * * * * *', () => {
      Functions.greet()
   })
})

functions.js

const greet = () => {
   const result = 'Hello World'
   console.log(result)
   return result
}
exports.greet = greet

In server.js, we've got some logic for our Express server, a scheduled process, as well as an endpoint called /api/greet. We then have a functions.js file that exports a greet() function, which returns the text Hello World. The CRON job in server.js runs every 5 seconds, triggering the greet() function on every run. This function is also triggered by the /api/greet endpoint.

So the point of this exercise is that we're going to trigger the greet() function using 3 events:

Manually via Terminal
Via a Web API
Via a schedule

package.json

{
   "name": "node-red-intro-nodejs-app",
   "version": "0.0.1",
   "description": "Node-RED Intro - NodeJS App",
   "main": "server.js",
   "scripts": {
      "manual": "node -e \"require('./functions').greet()\"",
      "endpoint": "curl http://localhost:6025/api/greet"
   },
   "engines": {
      "node": "12.18.4"
   },
   "author": "Agilit-e",
   "license": "MIT",
   "dependencies": {
      "express": "4.17.1",
      "node-cron": "3.0.0"
   }
}

We trigger the function manually by requiring the functions.js in terminal or command prompt, and executing the greet() function. You can see I've added this as a manual script in package.json, which I will trigger by running npm run manual. This will write Hello World as a response to the console.
For our next test we start the NodeJS server and trigger the greet() function via an HTTP request. Our endpoint will be http://127.0.01:6025/api/greet. Because it's a simple GET request, we can just use curl command in Terminal or alternatively open the URL in a browser window. For ease of execution, I have this also as a script in package.json, which I will trigger using npm run endpoint. You can see Hello World is returned as a response.
Finally, we can also see that in the background, the scheduled CRON job is printing the response to the console every 5 seconds.

Now, excluding the time that was taken to set up the base of this project, i.e. the package.json, dependencies and HTTP server…creating the HTTP endpoint, the greet() function and the CRON job will take you a couple of minutes if you know what you're doing. For fun, let's see how fast we can achieve this in Node-RED:

NOTE: For the Node-RED demo, click here to watch my video on YouTube or alternatively watch the embedded video above (Fast Forward to minute 2:42). Because we're still at the beginning stages of my Node-RED Series and this is more an introduction article, it will be tough to explain what I'm doing in Node-RED in writing. Apologies for any inconvenience caused.

Assuming you've watched the the video demo, I trust you enjoyed the fun comparison of native NodeJS and Node-RED. What can take minutes in NodeJS can be achieved in a fraction of the time using Node-RED. Scale that up to a much bigger project and you're going to see a massive time saving.

Now this is the first article of my Up and Running with Node-RED series, with many more to come that will focus on all areas of Node-RED, from basic to advanced functionality, to real world scenarios. If you're not yet subscribed or following me, now would be a great time to do so, so that you're notified when new content is released.

I want to close off by providing you with a reference to resources that will help you learn more about Node-RED:

Your first stop will be Node-RED's website - nodered.org. This site will give you a lot of insight into what Node-RED is, how it works, and provides proper end to end documentation on how to achieve almost anything you want with it. You can find almost anything you need regarding Node-RED, including links to online communities and forums which can be found at the bottom of the home page.

Finally, I highly recommend you subscribe to the Node-RED channel on YouTube, managed by the creators of Node-RED. It includes a number of tutorials as well as live webinars and streams.

That's it for now. Thanks so much for reading/watching and stayed tuned for much more to come.
Cheers :)

How to Manage Multiple Threads in Node JS

💻 Bleeding Code-By John Jardin — Wed, 31 Mar 2021 17:16:44 +0000

In this post I'm going to show you how to potentially triple your Node application's performance by managing multiple threads. This is an important tutorial, where the methods and examples shown, will give you what you need to set up production-ready thread management.

Watch The Video on YouTube

Child Processes, Clustering and Worker Threads

For the longest time, Node's had the ability to be multi-threaded, by using either Child Processes, Clustering, or the more recent preferred method of a module called Worker Threads.

Child processes were the initial means of creating multiple threads for your application and have been available since version 0.10. This was achieved by spawning a node process for every additional thread you wanted created.

Clustering, which has been a stable release since around version 4, allows us to simplify the creation and management of Child Processes. It works brilliantly when combined with PM2.

Now before we get into multithreading our app, there are a few points that you need to fully understand:

1. Multithreading already exists for I/O tasks

There is a layer of Node that's already multithreaded and that is the libuv thread-pool. I/O tasks such as files and folder management, TCP/UDP transactions, compression and encryption are handed off to libuv, and if not asynchronous by nature, get handled in the libuv's thread-pool.

2. Child Processes/Worker Threads only work for synchronous JavaScript logic

Implementing multithreading using Child Processes or Worker Threads will only be effective for your synchronous JavaScript code that's performing heavy duty operations, such as looping, calculations, etc. If you try to offload I/O tasks to Worker Threads as an example, you will not see a performance improvement.

3. Creating one thread is easy. Managing multiple threads dynamically is hard

Creating one additional thread in your app is easy enough, as there are tons of tutorials on how to do so. However, creating threads equivalent to the number of logical cores your machine or VM is running, and managing the distribution of work to these threads is way more advanced, and to code this logic is above most of our pay grades 😎.

Thank goodness we are in a world of open source and brilliant contributions from the Node community. Meaning, there is already a module that will give us full capability of dynamically creating and managing threads based on the CPU availability of our machine or VM.

Worker Pool

The module we will work with today is called Worker Pool. Created by Jos de Jong, Worker Pool offers an easy way to create a pool of workers for both dynamically offloading computations as well as managing a pool of dedicated workers. It's basically a thread-pool manager for Node JS, supporting Worker Threads, Child Processes and Web Workers for browser-based implementations.

To make use of the Worker Pool module in our application, the following tasks will need to be performed:

Install Worker Pool

First we need to install the Worker Pool module - npm install workerpool

Init Worker Pool

Next, we'll need to initialize the Worker Pool on launch of our App

Create Middleware Layer

We'll then need to create a middleware layer between our heavy duty JavaScript logic and the Worker Pool that will manage it

Update Existing Logic

Finally, we need to update our App to hand off heavy duty tasks to the Worker Pool when required

Managing Multiple Threads Using Worker Pool

At this point, you have 2 options: Use your own NodeJS app (and install workerpool and bcryptjs modules), or download the source code from GitHub for this tutorial and my NodeJS Performance Optimization video series.

If going for the latter, the files for this tutorial will exist inside the folder 06-multithreading. Once downloaded, enter into the root project folder and run npm install. After that, enter into the 06-multithreading folder to follow along.

In the worker-pool folder, we have 2 files: one is the controller logic for the Worker Pool (controller.js). The other holds the functions that will be triggered by the threads…aka the middleware layer I mentioned earlier (thread-functions.js).

worker-pool/controller.js

'use strict'

const WorkerPool = require('workerpool')
const Path = require('path')

let poolProxy = null

// FUNCTIONS
const init = async (options) => {
  const pool = WorkerPool.pool(Path.join(__dirname, './thread-functions.js'), options)
  poolProxy = await pool.proxy()
  console.log(`Worker Threads Enabled - Min Workers: ${pool.minWorkers} - Max Workers: ${pool.maxWorkers} - Worker Type: ${pool.workerType}`)
}

const get = () => {
  return poolProxy
}

// EXPORTS
exports.init = init
exports.get = get

The controller.js is where we require the workerpool module. We also have 2 functions that we export, called init and get. The init function will be executed once during the load of our application. It instantiates the Worker Pool with options we'll provide and a reference to the thread-functions.js. It also creates a proxy that will be held in memory for as long as our application is running. The get function simply returns the in memory proxy.

worker-pool/thread-functions.js

'use strict'

const WorkerPool = require('workerpool')
const Utilities = require('../2-utilities')

// MIDDLEWARE FUNCTIONS
const bcryptHash = (password) => {
  return Utilities.bcryptHash(password)
}

// CREATE WORKERS
WorkerPool.worker({
  bcryptHash
})

In the thread-functions.js file, we create worker functions that will be managed by the Worker Pool. For our example, we're going to be using BcryptJS to hash passwords. This usually takes around 10 milliseconds to run, depending on the speed of one's machine, and makes for a good use case when it comes to heavy duty tasks. Inside the utilities.js file is the function and logic that hashes the password. All we are doing in the thread-functions is executing this bcryptHash via the workerpool function. This allows us to keep code centralized and avoid duplication or confusion of where certain operations exist.

2-utilities.js

'use strict'

const BCrypt = require('bcryptjs')

const bcryptHash = async (password) => {
  return await BCrypt.hash(password, 8)
}

exports.bcryptHash = bcryptHash

.env

NODE_ENV="production"
PORT=6000
WORKER_POOL_ENABLED="1"

The .env file holds the port number and sets the NODE_ENV variable to "production". It's also where we specify if we want to enable or disable the Worker Pool, by setting the WORKER_POOL_ENABLED to "1" or "0".

1-app.js

'use strict'

require('dotenv').config()

const Express = require('express')
const App = Express()
const HTTP = require('http')
const Utilities = require('./2-utilities')
const WorkerCon = require('./worker-pool/controller')

// Router Setup
App.get('/bcrypt', async (req, res) => {
  const password = 'This is a long password'
  let result = null
  let workerPool = null

  if (process.env.WORKER_POOL_ENABLED === '1') {
    workerPool = WorkerCon.get()
    result = await workerPool.bcryptHash(password)
  } else {
    result = await Utilities.bcryptHash(password)
  }

  res.send(result)
})

// Server Setup
const port = process.env.PORT
const server = HTTP.createServer(App)

;(async () => {
  // Init Worker Pool
  if (process.env.WORKER_POOL_ENABLED === '1') {
    const options = { minWorkers: 'max' }
    await WorkerCon.init(options)
  }

  // Start Server
  server.listen(port, () => {
    console.log('NodeJS Performance Optimizations listening on: ', port)
  })
})()

Finally, our 1-app.js holds the code that will be executed on launch of our App. First we initialize the variables in the .env file. We then setup an Express server and create a route called /bcrypt. When this route is triggered, we will check to see if the Worker Pool is enabled. If yes, we get a handle on the Worker Pool proxy and execute the bcryptHash function that we declared in the thread-functions.js file. This will in turn execute the bcryptHash function in Utilities and return us the result. If the Worker Pool is disabled, we simply execute the bcryptHash function directly in Utilities.

At the bottom of our 1-app.js, you'll see we have a self calling function. We're doing this to support async/await, which we are using when interacting with the Worker Pool. Here is where we initialize the Worker Pool if it's enabled. The only config we want to override is setting the minWorkers to "max". This will ensure that the Worker Pool will spawn as many threads as there are logical cores on our machine, with the exception of 1 logical core, which is used for our main thread. In my case, I have 6 physical cores with hyperthreading, meaning I have 12 logical cores. So with minWorkers set to "max", the Worker Pool will create and manage 11 threads. Finally, the last piece of code is where we start our server and listen on port 6000.

Testing the Worker Pool

Testing the Worker Pool is as simple as starting the application and while it's running, preforming a get request to http://localhost:6000/bcrypt. If you have a load testing tool like AutoCannon, you can have some fun seeing the difference in performance when the Worker Pool is enabled/disabled. AutoCannon is very easy to use.

Conclusion

I hope this tutorial has provided insight into managing multiple threads in your Node application. The embedded video at the top of this article provides a live demo of testing the Node App.

Till next time, cheers :)

Increase Node JS Performance With Libuv Thread Pool

💻 Bleeding Code-By John Jardin — Mon, 07 Sep 2020 15:50:35 +0000

In this 5th instalment of my “Node JS Performance Optimizations” series, I show you how to increase Node JS performance with thread pool management. We achieve this by understanding how Libuv works, how the thread pool works and how to configure the number of threads based on your machine specs.

Are you a Node developer who’s not yet familiar with the inner workings of Node JS? If so, you might be deploying production applications with some default configurations that existed since installing Node. In this article, I’m going to touch on a lesser-known configuration that could very well double the performance of some of your application’s operations. This will depend on a number of factors, but chances are good this is going to be a win for many.

Watch The Video On YouTube

The Node JS Runtime Environment

The Node runtime environment is made up of a few moving parts. We should all be familiar with the Google V8 engine, which is responsible for executing our JavaScript logic. There is, however, a lesser known library called Libuv, which is responsible for managing asynchronous I/O operations.

These I/O operations are also well known as “heavy duty tasks” that related to the Operating System. Tasks such as files and folder management, TCP/UDP transactions, compression, encryption, etc. are handled via Libuv.

Now, while most of these operations are asynchronous by design, there are a few that are synchronous, and if not handled correctly, could cause our applications to be blocked. It is for this reason that Libuv has what is called a “Thread Pool”.

Libuv Thread Pool

Libuv initiates a thread pool of 4 threads that it uses to offload synchronous operations to. In doing this, Libuv ensures that our application does not get blocked unnecessarily by synchronous tasks.

It is here that we will take advantage of a setting to better suit the specs of our machine or the virtual machine that our app will be deployed to. This is because we are allowed to change the default value of 4 threads to anything up to 1024 threads. We achieve this by setting the UV_THREADPOOL_SIZE Node variable.

Physical vs Logical CPU Cores

To better understand what to set the UV_THREADPOOL_SIZE to, we need to first understand how many logical cores our machine is running. If we take my MacBook Pro as an example, it’s running 6 Physical CPU cores (Intel).

However, these cores have hyperthreading, which means that each core can run 2 operations simultaneously. We therefore regard 1 physical core with hyperthreading as 2 logical cores. In my case, my MacBook Pro is running 12 logical cores.

How To Increase Node JS Performance

The recommendation is to set the UV_THREADPOOL_SIZE to the number of logical cores your machine is running. In my case I will set the thread pool size to 12.

It makes no sense setting the size to anything more than the logical cores your hardware is running and could actually result in poorer performance.

How To Check For Logical Cores

When it comes to deployment, the last thing you want to do is manually set the UV_THREADPOOL_SIZE, as your app might run on multiple environments with different machine specifications. As such, we need a way to dynamically set the thread pool size the moment the app is launched on the relevant environment.

The good news is that this is quite simple, but must be dealt with caution. To achieve this, add the below code to the top of your root JS file of your Node application:



const OS = require('os')
process.env.UV_THREADPOOL_SIZE = OS.cpus().length

The OS module is native to Node JS. It has a function cpus(), which returns the total amount of logical cores your machine is running. What’s nice is, should your CPU cores not have hyperthreading, this function will just return the number of physical cpu cores instead, which is perfect.

Closing

I trust this article proved valuable. I recommend watching the embedded video as well as checking out my Source Code repo on GitHub which has code samples of everything mentioned here.

Till next time, cheers 😎

How To Test The Availability Of Your API Server

💻 Bleeding Code-By John Jardin — Mon, 31 Aug 2020 19:18:13 +0000

Have you developed or are you in the process of creating an API Server that will be used on a production or cloud environment? In this 4th instalment of my Node JS Performance Optimizations series, I show you how to test the availability of your API Server, so that you can understand how many requests per second it can handle whilst performing heavy duty tasks.

This is a very important measure, especially for production environments, because the last thing you want is to have incoming requests queued as a result of your API Server peaking and not freeing up resources often enough.

A Quick Note

While I’ll be referencing NodeJS in this article, most of the theory and principles mentioned can apply to any platform and environment.

Watch The Video On YouTube

Which Benchmark Testing Tool To Use

The tool I’ll be using for my tests is called AutoCannon. It’s written entirely in NodeJS and is very similar to Apache Benchmark, Artillery, K6, Wrk, etc. This is good news because you are not forced to use AutoCannon to follow along with this article. If your benchmark testing tool can perform load tests against HTTP requests and can determine the average requests per second, you’re good to go.

That being said, should you wish to make use of AutoCannon, it’s as easy as installing it globally as an NPM Module:

npm i -g autocannon

How To Test The Availability Of Your API Server

Firstly, there is an online Source Code Repo that you can reference should you wish to run these examples on your local environment. All you will need is NodeJS installed.

The snippet of code below gets you pretty much 99% to where you want to be, with the exception of setting up your package.json, setting the NODE_ENV to Production and PORT to 6000 (reference sample code in provided Source Code Repo and embedded video should you struggle). Add the following to an app.js file.

'use strict'

require('dotenv').config()

const Express = require('express')
const App = Express()
const HTTP = require('http')
const BCrypt = require('bcryptjs')

// Router Setup
App.get('/pulse', (req, res) => {
  res.send('')
})

App.get('/stress', async (req, res) => {
  const hash = await BCrypt.hash('this is a long password', 8)
  res.send(hash)
})

// Server Setup
const port = process.env.PORT
const server = HTTP.createServer(App)

server.listen(port, () => {
  console.log('NodeJS Performance Optimizations listening on: ', port)
})

This is a very simple Express Server that exposes 2 Routes:

/pulse
/stress

The /pulse endpoint represents a very lightweight API that contains no business logic and returns an empty string as a response. There should be no reason for any delays when processing this endpoint.

The /stress endpoint, on the other hand, uses BcryptJS to salt and hash a password. This is quite a heavy process and because it’s completely written in JavaScript, it will land up blocking the Event Loop quite badly.

For our first test, we’re going to use AutoCannon to run a load test against the /pulse endpoint, to see how many requests per second the API Server can handle when it’s running idle. The process is as follows:

Start up the Express Server
- node app
Run the AutoCannon test
- autocannon http://127.0.0.1:6000/pulse
- This is a simple load test that runs 10 concurrent connections for 10 seconds

After the test run, you should receive a report that includes an average requests per second. Depending on the speed of your machine, it should vary between 15 000 and 25 000 requests:

Now that we have our baseline measurement, let’s see what happens when the API Server is performing heavy duty tasks:

Make sure the Express server is running
- node app
Open 2 Terminal windows for the tests to be performed
In window 1, run AutoCannon against the /stress endpoint for a duration of 30 seconds
- autocannon -d 30 http://127.0.0.1:6000/stress
In window 2, while the /stress test is running, run AutoCannon against the /pulse endpoint, same as before
- autocannon http://127.0.0.1:6000/pulse
- Make sure the /pulse test runs to completion whilst the /stress test is running

After this test run, you should see a significant drop in the requests per second for the /pulse test.

As you can imagine, this is a frightening result…one that needs to be handled sooner rather than later.

What Does This Mean In The Real World

While this example won’t make too much sense in the real world, it forms a template for the kind of tests you should be running on your environment. You need to identify when your API Server is running at peak, and then hit it with load testing against lightweight APIs that belong to your server. You need to determine if they can be processed without much delay, or if they get blocked because your code might not be managing the Event Loop well enough.

How do I fix the problem?

Well, I have good news: As mentioned at the start, I am busy with a series on “Node JS Performance Optimizations”. Having already used examples from content I’ve published and content to come, I managed to increase the requests per second for the /pulse test from 117 to over 4 000.

What you want to do is subscribe to my Bleeding Code YouTube Channel, as I publish everything there first and almost on a weekly basis. There are already 4 videos for this series, an important one which is “Managing The Event Loop Phases“.

I hope this article proved valuable. Stay tuned for more to come 😎
Cheers

MANAGING THE EVENT LOOP PHASES ⭕️ [Node JS Performance Optimizations]

💻 Bleeding Code-By John Jardin — Mon, 10 Aug 2020 06:58:41 +0000

In this first video of my Node JS Performance Optimizations series, I show you how to level up you Node JS skills by managing the Event Loop phases the right way. I provide simple, yet in depth explanations and examples of how the Event Loop works as well as how to best interact with it to write performant Node apps.

The tutorial is divided into 4 main sections:

Quick Points about Node JS

Video Location - 00:45

Before diving in to the detail of what makes the Event Loop tick (mind the pun 😎), I go over a few basic points that everyone needs to first understand about Node and the Event Loop.

Async Functions

Video Location - 02:37

In this section I provide an overview of the the 5 asynchronous functions you can use to interact with the Event Loop.

Phases of the Event Loop

Video Location - 03:55

Using a simple diagram of the Event Loop, I explain the 5 main phases that make up a Cycle (Tick) and what each phase is used for.

The Event Loop in Action

Video Location - 09:15

I demo in realtime how to interact with the Event Loop using the 5 mentioned asynchronous functions.

Performance Tips

Video Location - 17:43

Finally, I provide a few quick tips on how to write good, performant Node JS applications.

Till next time. Cheers 🙂