Every JS developer uses
Math.random() once in a while in their applications for various use cases. The general wisdom says that
Math.random() is good for anything, but security. That said, this function is not backed by a CSPRNG (cryptographically secure pseudorandom number generator) and shouldn’t be used in security-related tasks, like UUID v4 generation (note: if you dare to use UUIDs for such tasks).
Today we’ll try to understand how…
Note: this post was originally published in Hazelcast blog.
As you may already know, the Hazelcast In-Memory Data Grid (IMDG) ecosystem includes a variety of clients for different languages and runtimes, which includes Node.js client library as a part of that list.
You can use Hazelcast clients in various cases, including, but not limited to the following:
The common wisdom says that K/V stores are a bad fit for time series (TS) data. Reasons are lots of writes and a large data volume implied by time series. But the common wisdom maybe sometimes wrong. Today we will discuss an approach for building a (relatively) efficient TS storage on top of RocksDB, an embedded key/value (K/V) store from Facebook. RocksDB is a perfect fit for our needs, as it’s production-ready, well-maintained, and provides solid write speed thanks to the LSM tree data structure. …
With this blog post, I am starting V8 Deep Dives series dedicated to my experiments and findings in V8, which is, no doubt, a well-engineered and sophisticated software. Hopefully, you will find this blog post valuable and share your ideas for the next topic.
ECMAScript 2015, also known as ES6, introduced many built-in collections, such as Map, Set, WeakMap, and WeakSet. They appeared to be an excellent addition to the standard JS library and got widely adopted in libraries, applications, and Node.js core. …
Node.js v13.10.0 introduced a built-in CLS API, namely, new class
AsyncLocalStorage located in the well-known experimental
async_hooks module. In this short post I’ll try to explain why it is so important.
CLS stands for Continuation-Local Storage, an async variation of the Thread-Local Storage concept from the multithreaded world. CLS APIs allow you to associate and track contexts through asynchronous execution chains. Without such API, you have to either pass the context object explicitly (which sometimes is not an option), or deal with lots of monkey-patching for all async APIs in Node.js.
Recently I wrote a post about request id tracing in Node.js apps. The proposed solution was built around cls-hooked library, which in its turn uses node’s built-in Async Hooks API. So, I decided to get more familiar with async hooks. In this post I’m going to share my findings and describe some real-world use cases for this API.
Let’s start our journey with a short intro.
If you ever wrote back-end applications in Node.js, you know that tracing the same HTTP request through log entries is a problem. Usually your logs look something like this:
[07/Nov/2018:15:48:11 +0000] User sign-up: starting request validation[07/Nov/2018:15:48:11 +0000] User sign-up: starting request validation[07/Nov/2018:15:48:12 +0000] User sign-up: request validation success[07/Nov/2018:15:48:13 +0000] User sign-up: request validation failed. Reason:
Here, log entries are mixed up and there is no way to determine which of them belong to the same request. While you would probably prefer to see something like this:
[07/Nov/2018:15:48:11 +0000] [request-id:550e8400-e29b-41d4-a716-446655440000] User sign-up: starting request validation[07/Nov/2018:15:48:11 +0000]…