In the world of Node.js, the choice between synchronous and asynchronous I/O is critical for performance and efficiency. Synchronous I/O, the traditional method, processes tasks sequentially, blocking other operations until the current task is completed. Asynchronous I/O, on the other hand, allows multiple operations to occur simultaneously, improving performance by not waiting for one task to finish before starting another.
Asynchronous methods are more modern and suited to the non-blocking nature of JavaScript environments like Node.js. The primary reason for choosing asynchronous I/O over synchronous I/O is performance. In Node.js, which is built on the event-driven, non-blocking I/O model, asynchronous operations allow for handling multiple tasks at once, thus optimizing resource use and increasing throughput.
Why Avoid Synchronous I/O in Node.js?
The main drawback of synchronous I/O in Node.js is that it blocks the execution of other code while waiting for an I/O operation to complete. This blocking nature is at odds with the non-blocking, event-driven architecture of Node.js. When a synchronous operation is performed, it halts the execution of any other code, including JavaScript and other I/O operations, until it finishes.
In contrast, asynchronous operations enable Node.js to continue executing other code while waiting for an I/O task to complete. This non-blocking nature is at the core of Node's design philosophy and is a key reason why developers are advised to avoid synchronous I/O in their applications.
Exceptions to the Rule
There are scenarios where synchronous I/O might still be used. For instance, loading required code or using ESM imports in Node.js still involves synchronous file system I/O. This is not technically necessary, and efforts are being made to move away from it, but it remains a common practice.
Another scenario is when developing command-line applications where operations are limited, and the simplicity of synchronous code is preferred. Even in such cases, developers are encouraged to write asynchronous code to follow best practices, ensuring consistency and future-proofing the application.
Challenges in Implementing Asynchronous I/O
Transitioning from synchronous to asynchronous I/O can present challenges, particularly when dealing with legacy systems or APIs that were originally designed for synchronous operations. In some cases, developers have no choice but to implement synchronous behavior due to external constraints, such as APIs or user interfaces that demand synchronous interaction.
An example of this challenge is evident in the development of MongoDB's CLI utility. The goal was to rewrite the MongoDB shell to function asynchronously while maintaining compatibility with scripts written for the older, synchronous shell. This required creative problem-solving to ensure a smooth transition without sacrificing performance or user experience.
Exploring Possible Solutions
Various approaches can be taken to tackle the challenge of converting synchronous I/O operations to asynchronous ones. One straightforward method is using built-in synchronous methods in Node.js, but this doesn't solve issues related to network I/O, which is inherently asynchronous.
Another approach is leveraging WebAssembly (Wasm) with the Web Assembly System Interface (WASI) to execute non-JavaScript code, such as C or Rust, synchronously. This method, while innovative, is still experimental and not user-friendly for developers who primarily work in JavaScript.
Developers can also create native add-ons in C++ or Rust to handle synchronous I/O, but this involves significant effort and complexity, as it would require re-implementing Node.js's networking stack.
Combining Workers with Atomics for Synchronous Behavior
One promising approach involves using worker threads and Atomics to simulate synchronous behavior. By spawning a worker thread and using Atomics.wait, developers can block the main thread until the worker completes its asynchronous task, effectively achieving a synchronous-like process.
This method takes advantage of Node.js's full API and npm packages within the worker, allowing for a more seamless integration of asynchronous operations. However, it comes with its own set of limitations, such as restrictions on Atomics.wait in browser environments and the inability to manipulate objects directly within the worker.
Crafting a Custom Solution
For those familiar with Node.js internals, creating a custom solution might be the answer. By embedding Node.js into itself and creating a synchronous worker, developers can start a new Node.js instance with its own event loop on the same thread. This method allows full control over the event loop and access to JavaScript objects, providing a powerful tool for managing asynchronous tasks in a synchronous manner.
While this approach is not without its challenges and is limited to Node.js environments, it offers a way to maintain compatibility with existing scripts and provide a smoother user experience.
Transpiling Synchronous Code to Asynchronous
In cases where none of the above methods meet the requirements, transpiling synchronous code to asynchronous code can be a viable solution. By using tools like Babel to convert synchronous operations into asynchronous ones, developers can maintain functionality while adhering to best practices.
This approach, while not perfect, provides a practical solution that balances the need for synchronous behavior with the advantages of asynchronous execution. It is particularly useful for legacy systems where rewriting code from scratch is not feasible.
Embracing Asynchronous I/O in Node.js
The journey to mastering asynchronous I/O in Node.js involves understanding the trade-offs between synchronous and asynchronous operations and finding creative solutions to bridge the gap. By embracing asynchronous I/O, developers can unlock the full potential of Node.js's non-blocking architecture, resulting in more efficient and responsive applications.
While challenges exist, particularly with legacy systems and external constraints, the benefits of adopting asynchronous practices are significant. With the right tools and strategies, developers can overcome these challenges and build scalable, high-performance applications that take full advantage of Node.js's capabilities.
Node.js is famously a JavaScript runtime that encourages using asynchronous operations wherever possible – but what happens when you really, really need to do synchronous I/O? Anna gives an overview over the – surprisingly many – different ways to achieve this, and what we can learn about how the language and Node.js internals work from them.
This talk has been presented at Node Congress 2021, check out the latest edition of this JavaScript Conference.
Anna is currently working on a project called Mongosh, a Node.js application aimed at rewriting the MongoDB shell to improve maintainability and incorporate modern JavaScript practices.
Implementing synchronous IO for network operations in Node.js is challenging because the underlying library (libuv) does not support synchronous network IO, requiring complex workarounds or reimplementation of the networking stack.
The approach using workers with atomics achieves synchronous IO by blocking the main thread using atomics.wait, while a worker thread performs the IO operation asynchronously. Once completed, the worker notifies the main thread to proceed, mimicking synchronous behavior.
The purpose of the project where Node.js is embedded into itself is to create a synchronous worker by starting a new Node.js instance on the same thread. This allows for synchronous execution without multi-threading, providing a unique way to handle certain synchronous operations.
The use of atomics.wait in browsers is limited because it blocks the main thread, which would prevent rendering and other operations, potentially degrading user experience and browser functionality.
Acceptable scenarios for using synchronous IO in Node.js include loading code required during the synchronous file system IO, writing CLI applications with limited concurrent operations, and situations where synchronous code is necessary due to API constraints.
The main reason to avoid synchronous IO in Node.js is due to performance issues. Synchronous IO can block other operations from executing, causing delays and inefficiency in processing.
The synchronous version of an IO operation might initially seem faster because it directly performs the read operation without scheduling other tasks in between. However, this can be misleading as it blocks other operations, affecting overall performance.
This Talk explores synchronous IO in Node.js and the advantages of asynchronous IO. It discusses exceptions to synchronous IO and approaches to achieving synchronous IO in Node.js, including using WASI and native add-ons. The Talk also covers mixing workers with atomics for synchronous IO and embedding Node.js to create a synchronous worker. Additionally, it touches on TypeScript migration, optimizations in Node.js, and experiences and advice on contributing to Node.js.
Hi, everyone. I'm Anna and I'll be talking about synchronous IO in Node.js. I have a background in the Node.js Technical Steering Committee and now I'm part of the MongoDB DevTools team.
2. Synchronous vs Asynchronous IO in Node.js
The synchronous and asynchronous ways of loading files in Node.js give the same result, but the synchronous way has performance issues. Initially, I expected the synchronous version to be slightly faster for a single call, but I discovered a bug in the async version that affected performance. However, the async version is now faster. The advantage of asynchronous IO is that multiple things can happen at the same time, allowing for concurrent operations.
3. Exceptions to Synchronous IO in Node.js
There are exceptions to synchronous IO in Node.js. Loading code required and ESM import do synchronous file system IO, but it's not necessary. Writing asynchronous code is encouraged even if not strictly necessary. The third case is when synchronous code is needed, such as when an API or user interface requires it. I'm currently working on rewriting the Mongo CLI utility as a Node.js application called Mongosh. JavaScript applications are easier to maintain and we can embed Mongosh in Electron apps and web pages.
4. Approaches to Synchronous IO in Node.js
We're building on top of the Node.js driver and need to make the method do something synchronously. The easy way is using synchronous methods, but they don't cover network I/O. I believe the existence of synchronous file operations is a design flaw. To achieve synchronous I/O in Node, you can write C, Rust, or C++ code and compile it to Wasm.
5. Using WASI for Synchronous IO in Node.js
You can use WASI, the Web Assembly System Interface, supported by Node.js, to run code synchronously. However, it is still experimental and not very useful for writing JavaScript due to the need to serialize data and use array buffers. It does support web network IO.
6. Foreign brute force for synchronous IO in Node.js
You could write a native add-on that you load from Node.js to perform IO. However, reimplementing the whole Node.js networking stack just for synchronous IO would be too much work and not supported by libuview.
7. Mixing Workers with Atomics
And now, let's get to the exciting part: mixing workers with atomics. We create a message channel and a shared array buffer. The main thread starts a worker and waits on the shared array buffer. The worker receives data from the main thread and runs an async function using NodeFetch to load HTTP requests. After getting the response, it posts it back to the main thread using atomic cert notify.
8. Using Workers for Synchronous IO in Node.js
And then on the main thread, we look at what we got, use the receive message from party API, and print out the response. This idea allows synchronous operations with some advantages. The main thread is blocked, spawns a worker thread, and waits for the response before progressing. Node.js offers the full API and NPM packages in the worker, but there are downsides. Atomics.wait is not allowed on main threads in browsers, and manipulating objects inside the worker is not easily possible. However, it's production-ready and can be used in worker threads.
9. Embedding Node.js and Synchronous Worker
I went to my evil scientist lab and thought about a solution for synchronous IO in Node.js. The idea is to embed Node.js into itself, starting a new instance on the same thread. This eliminates the need for separate threads and reduces complexity. I came up with a project called synchronous worker, which achieves the desired result.
10. Using Workers for Synchronous IO
You can create a require function inside the worker that loads node fetch. This is a runnable example. There are a couple of downsides, such as it only works in Node.js and is currently implemented as a native add-on. However, it provides full event loop control and access to JavaScript objects. For Mongo's edge, we use Babel to transpile asynchronous code to sync code. Thank you for listening.
11. TypeScript Migration and Optimizations in Node.js
We use TypeScript at work and plan to convert legacy JavaScript code to TypeScript. The migration is not a top priority now, but we aim to do it on a file-per-file or project-per-project basis. We follow the concept of single-gear development, migrating as we touch each file. Regarding optimizations for SS read file in Node.js, I improved performance by changing the implementation to read the entire file at once. Being one of the top contributors to NodeJS has been a special experience.
12. Experiences and Advice on Contributing to Node.js
I don't think it's one that many of us get to have, honestly. I'm really glad. I appreciate that a lot. It's just very different working on code that affects so many people and that is so visible in the community. I'm also not that sad that I'm not actively working on Node that much anymore. Do you have any advice for folks that are interested in starting to contribute? Start with what would I want to change about Node if I could. Or what is something that I know I could help with? And then focus on that instead of just looking for an easy contribution. What was your first change in Node? My first change was providing a test case for a bug that I found. It's not very exciting on its own, but it helped me work on my own project. I like the philosophy of making changes that are useful to you and probably useful to a lot of other people.
13. Improving Node.js with Supported Official API
That's how open source works. You do things that are good for you and hope that somebody else also finds them helpful. A lot around tracing and like acing operations in Node. If we get everything inside Node on one format, we could provide a supported official API that gives you all things that currently keep the event group alive. It would be really nice to have something inside of Node that is a fully supported public API. Somebody sufficiently motivated could definitely do that.
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.
Today's Talk is about logging with Pino, one of the fastest loggers for Node.js. Pino's speed and performance are achieved by avoiding expensive logging and optimizing event loop processing. It offers advanced features like async mode and distributed logging. The use of Worker Threads and Threadstream allows for efficient data processing. Pino.Transport enables log processing in a worker thread with various options for log destinations. The Talk concludes with a demonstration of logging output and an invitation to reach out for job opportunities.
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods. Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters Prerequisites- IDE for your choice- Node 18 or higher
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible. All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL. In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours. If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.
Comments