DEV Community: Gbeminiyi 'Telo Briggs' Oshoba

Parallel Processing with Multithreaded Node.js

Gbeminiyi 'Telo Briggs' Oshoba — Sat, 26 Feb 2022 21:49:25 +0000

Whether you're a few days in or a few years, a lot of people can't seem to understand how single-threaded NodeJS can compete with multi-threaded backends.

To identify the reasons, we have to understand what it really means when we say Node.js is single-threaded.

JavaScript itself was originally created to do basic things like validating forms, making things responsive, etc., and it was only in 2009 that Node.js creator Ryan Dahl made it possible to use JavaScript to write server-side code.

Server-side languages that support multithreading have all manners of structures and constructs in place for syncing values between threads and other thread-oriented features.

Supporting those things meant JavaScript would have needed to change the entire language which was never the plan of it's creator. So in order for plain JavaScript to support multi-threading, Dahl had to create a workaround. Let's dive in!

How does Node.js actually work?

Node.js uses two kinds of threads: a main thread handled by the event loop and several auxiliary threads in a worker pool.

The Event loop is the infrastructure that takes callbacks (functions) and registers them to be executed at a later time in the future. It executes in the same thread as the JavaScript code itself. When a JavaScript operation blocks the thread, the event loop is also blocked.

A Worker pool is an execution model that spawns and handles separate threads, it then synchronously performs the task and return the result to the event loop. The event loop then executes the provided callback with said result.

Basically worker pools handles asynchronous I/O operations - mainly, interactions with the system's disk and network. A few modules use worker pools out the box such as fs (I/O-heavy) or crypto (CPU-heavy). Worker pool is implemented in libuv, which results in slight delays whenever Node needs to transmit data internally between JavaScript and C++, but this is hardly noticeable.

The implication of both systems is that we are able to write code like this:

In the code above we don't have to synchronously wait for an event. We delegate the task of reading the file to the worker pool and call the provided function with the result. Since worker pool has its own threads, the event loop can continue executing normally while the file is being read.

This is seemingly sufficient until it is necessary to synchronously execute a complex operation - any function that takes too long to run will block the thread. If in your application you have functions of that nature, it could significantly reduce the throughput of your server or even completely freeze it. In this scenario we have no way of delegating the load to the worker pool.

Tech fields that required complex calculations - such as AI, machine learning, or big data - couldn't really use Node.js efficiently due to the operations blocking the main (and only) thread, making the server unresponsive. This was the case up until Node.js v10.5.0 came out in June 2018, which added support for multiple threads and opened up new possibilities for JavaScript.

I introduce to you: worker_threads

With the release of Node.js 10.5.0 came about worker_threads. It enables the creation of simple multi-threaded applications in JavaScript. Threads are pretty simple and, very importantly, fun.

The worker_threads module is a package that allows us to design fully functional multithreaded Node.js applications. A thread worker is a piece of code (usually taken out of a file) spawned in a separate thread.

It is important to note that the terms thread worker, worker, and thread are often used interchangeably; they all refer to the same thing.

Worker Threads in Node.js is useful for performing heavy JavaScript tasks. With the help of threads, Worker makes it easy to run JavaScript codes in parallel making it much faster and efficient. We can do heavy tasks without even disturbing the main thread.

Worker threads were not introduced in the older versions of Node. Therefore, first update your Node.js for getting started.

Now create two files for implementing the thread as shown below:

Filename: worker.js

// workerData is used for fetching the data from the thread and parentPort is used for manipulating the thread const { workerData, parentPort } = require('worker_threads');

// log some stuff console.log(Write-up on how ${workerData} wants to chill with the big boys);

// The postMessage() method is used for posting the given message in the console by taking the filename as fetched by workerData parentPort.postMessage({ filename: workerData, status: 'Done'});

Filename: index.js

const { Worker } = require('worker_threads');

// function runService() runs the worker thread and returns a Promise const runSerice = (workerData) => { return new Promise((resolve, reject) => { const worker = new Worker('./worker.js', { workerData }); worker.on('message', resolve); worker.on('error', reject); worker.on('exit', code => { if (code !== 0) reject(new Error(Worker Thread stopped with exit code ${code})); }); }); }

// function run() is used for calling the function runService() and giving the value for workerData const run = async () => { const result = await runSerice('Tunde Ednut'); console.log(result); }

run().catch(err => console.error(err));

Output:

Full working code on github: https://github.com/ocdkerosine/multithreaded-node-js

Conclusion
By delegating heavy CPU computations to other threads, we can significantly increase our server's throughput and worker_threads provide a fairly easy way to add multithreading support to production applications.

With the official threads support, we can expect more developers and engineers from data and compute intensive fields to start harnessing the added power and notorious speed of Node.js.

Read More
Looking to scale from local first development to production first coding? Join us at Kerosine Coding today!

Deploy to Kubernetes in 5 minutes with Docker Compose and Okteto Cloud

Gbeminiyi 'Telo Briggs' Oshoba — Sat, 26 Feb 2022 01:54:20 +0000

Why developers need Docker Compose in Kubernetes

A Docker Compose file for five microservices might be around 30 lines of yaml, but the same application in Kubernetes would be 500+ lines of yaml and about 10-15 different files. Also, the Docker Compose CLI rebuilds and redeploys containers when needed. In Kubernetes, you need additional tools to build your images, tag them, push them to a Docker Registry, update your Kubernetes manifests, and redeploy them. It’s too much friction for something that’s wholly abstracted away by Docker Compose.

There are some use cases where running your Docker Compose files locally presents some challenges. For example, you might need to run dozens of microservices that exhausts your local CPU/Memory resources, you might need access to GPUs to develop a ML application, or you might want to integrate with a service deployed in a remote Kubernetes cluster. For these scenarios, running Docker Compose in Kubernetes is the perfect solution. This way, developers get access to on demand CPU/Memory/GPU resources, direct access to other services running in the cluster, and more realistic end-to-end integration with the cluster configuration (ingress controllers, SSL termination, monitoring tools, secret manager tools…), while still using the application definition format they know and love.

A docker-compose manifest is a configuration manifest file for listing and configuring single or multiple application services to be deployed. Like Kubernetes manifests or Helm charts, docker-compose is supported as a manifest for application deployment on Okteto.

Docker Compose, Kubernetes & Okteto Stacks

Okteto Stacks is a fully compatible Kubernetes backend for Docker Compose. Okteto Stacks are unique with respect to other Kubernetes backend implementations of the Docker Compose Specification because they provide:

In-cluster builds for better performance and caching behavior.
Ingress Controller integration and SSL termination for public ports.
Bidirectional synchronization between your local filesystem and your containers in Kubernetes.

Okteto’s bidirectional synchronization is pretty handy: .it reloads your application on the cluster while you edit your code locally. It’s equivalent to mounting your code inside a container using Docker Compose host volumes, but for containers running in a remote cluster.

For a more beginner friendly quickstart there is a handy tutorial hosted by the Docker Team here.

In this tutorial, you’ll learn how to deploy a Fullstack Invoice Management App called Kerosine Invoicing to Okteto Cloud by using a docker compose manifest. Quickly grab the code here

How to get started

In order to follow this tutorial, the following prerequisites must be met:

The latest stable version of Node installed on your machine
Good knowledge of the Nodejs and Docker
Docker compose installed.
Okteto CLI installed.

To show the possibilities of Okteto Stacks, let’s deploy our Invoice Management App, Kerosine Invoicing.

Get a local version of the Kerosine Invoicing App by executing the following commands:

$ git clone https://github.com/ocdkerosine/kerosine-invoicing.git

$ cd kerosine-invoicing

$ okteto stack deploy --wait

i Using ocdkerosine @ cloud.okteto.com as context
! The following fields are not currently supported and will be ignored: 
    - networks
    - services[kerosine-invoice-frontend, kerosine-invoice-backend].networks
    - volumes[api-data].driver
Help us to decide which fields to implement next by filing an issue in https://github.com/okteto/okteto/issues/new
✓ Created volume 'api-data'
✓ Deployed service 'kerosine-invoice-frontend'
✓ Deployed service 'kerosine-invoice-backend'
✓ Stack 'kerosine-invoicing' successfully deployed
i Endpoints available:
   - https://kerosine-invoice-backend-ocdkerosine.cloud.okteto.net/
   - https://kerosine-invoice-frontend-ocdkerosine.cloud.okteto.net/

The deploy command will create the necessary deployments, services, persistent volumes, and ingress rules needed to run the Kerosine Invoicing App. Go to the Okteto Cloud dashboard and you will get the URL of the application… or maybe just pick it up from your console.

Dashboard :

Live App:

Sidebar:

It is at this point I would like to obligatorily pull you away from the action to speak on my environment setup and tell you the inspiration behind it. I code using VS Codium(open source binary release of vscode without Microsoft telemetry) on Parrot OS, Linux. Parrot is a security and pen-testing based OS. Its popular rival is Kali Linux, the OS in which I learnt the bread and butter of hacking and Linux Administration. But why? Because trackers are using your information for purposes that don’t protect your self interest. Find out how you can protect yourself from the PrivacyTools.io site here.

Moving On

We have successfully deployed our application to the Kubernetes development platform, Okteto, using docker-compose as below:

Local Development

Now that the Kerosine Invoicing App is running on the cloud (production), let’s make a small change (on local pc) to show you the full development workflow.

Open the “frontend/public/index.html” file in your IDE and change the line 14. Save your changes.

<title>Kerosine Invoice App</title>

Once you’re happy with your changes, execute the following command:

okteto up

Check the URL of your application again. Your code changes were instantly applied. No commit, build, or push required. And from this moment, any changes done from your IDE will be immediately applied to your application all thanks to Telepresence!

Conclusion

By using docker-compose with Okteto, you’re able to get all the benefits of developing with Kubernetes, such as using monitoring tools, platform services like secret management tools, and taking ownership of the release pipeline, but without the hassle of needing to learn Kubernetes.

The post Deploy to Kubernetes in 5 minutes with Docker Compose and Okteto Cloud first appeared on Kerosine Coding.