As I was reading this article about exporting getters in CommonJS from my colleague David Barral the other day, it occurred to me that we could use this approach to export dynamically from a CLS context. Since I recently wrote a post about AsyncLocalStorage, I thought that I could probably dig a bit deeper on this subject.
In my previous AsyncLocalStorage post I used this example:
We can make it way more readable by taking out all the CLS stuff and moving it to a separate file. This is the content of
We added a couple of lines here. We defined a default store and we assigned it to the
AsyncLocalStorage with the
enterWith method. This store will be returned when we’re out of the request scope. …
Some months ago I wrote a post about storing data in an asynchronous context using continuation local storage to avoid spreading the request context to every function via parameters. For this purpose, we used cls-hooked, a library that implements CLS using the
async_hooks node API.
With Node.js 13.10, we got a new feature called AsyncLocalStorage. In this post we’re going to learn more about this new feature and we’re going to rebuild our previous solution using AsyncLocalStorage this time.
AsyncLocalStorage is a new experimental feature included in the
async_hooks package that allows us to store data in asynchronous contexts just like we were doing with cls-hooked. You can think of it as the node.js …
I’ve been wanting to share access to these services with my family for some time now, but accessing the services via IP:PORT urls is a bit harsh for non tech users.
We are going to solve that by using a reverse proxy.
A reverse proxy is a piece of software that listens for requests at some port, parses them, and based on the parsed information fetches data from some other servers.
This is easier to understand with an example. Let’s say we have our calibre service running at
localhost:9083 and our transmission server at
localhost:9091. What we want is to have
books.mydomain.com pointing to
torrents.mydomain.com pointing to
localhost:9091. What our reverse proxy has to do in this case is: take the request, and based on the subdomain portion, forward the request to the right service. …
In the last years gRPC has been gaining a lot of traction. In this post we are going to cover the very basics of gRPC, and jump right into building a Greeter service with grpc-node. After that, we’re going to rewrite it using Mali.
This post will assume no previous gRPC experience, so if you haven’t had the time to check what is gRPC about, keep reading!
Recently I’ve been working on a Node.js project where we needed to keep track of which requests were generating calls to some other pieces of code. Passing a request identifier around was not viable since it would require to change too many APIs.
We solved the problem using cls-hooked, a small package that uses the
async_hooks experimental Node.js API to implement Continuation Local Storage.
Some languages have Thread Local Storage. This is a way to attach global data to the thread itself. Due to the asynchronous and single-threaded nature of Node.js this is not useful. …
Not long ago I was running some tests for a Node.js project and for some reason they run forever. There was something preventing the process from terminating. It took me some time to realise that it was an interval not being properly cleared, but I learned a lot in the debugging process.
How can we find out what bits of code are causing our programs to starve forever? Why is this happening?
Node.js uses an event-driven architecture. The core of the event loop is implemented using a C library called libuv, which provides support for asynchronous I/O polling. Node.js also has some event queues of its own to implement things like
In the last few years the microservice architecture pattern has become mainstream. The pattern solves many problems of the monolithic architecture design but has some drawbacks, one of the biggest being how hard it is to debug the system as a whole.
One of the best tools you can have in your belt when you are dealing with microservices is distributed tracing. Distributed tracing lets you know what is happening in your system and which parts are involved, even in production.
In the first part of this series we learned how debuggers work and how to attach our debugging client to our code. In this part we will cover the basic features of the chrome debugger.
As developers, we frequently spend a hefty amount of time debugging. It is for this reason that knowing how to properly debug is crucial if we want to be productive.
In this series we are going to kick the good old
console.log out of our lives and learn how to debug node.js the right way.
Before we start we need to know that node.js uses the Chrome V8 engine under the hood. The V8 engine is a low level piece of software written in C++ that translates our JS code to machine code.
The Chrome V8 engine implements a protocol called the V8 Inspector Protocol or Chrome Debugging Protocol. This protocol has been available since node 6.3 and it provides debugging clients with a way to communicate with the engine itself. …
In the second part of this series we covered the Node.js REPL programatic API. This will be the last part of the series and we will write an example express application that takes advantage of that programatic API.
All the code for this article lives in this repository. I strongly recommend you to check it out to follow me in this article.
We are going to use a naive express application that has a service layer and a controller layer. …