Comparison of synchronous and asynchronous I/O in Node.js
Performance impact of synchronous I/O operations
Exceptions where synchronous I/O might be acceptable
Exploration of methods to achieve synchronous I/O in Node.js
Challenges in maintaining compatibility with legacy systems
The discussion around synchronous versus asynchronous I/O in Node.js often centers on performance and efficiency. Asynchronous I/O is known for allowing multiple operations to happen at once without blocking the execution thread, making it ideal for non-blocking, scalable applications. This is particularly important in environments like Node.js, which rely on an event-driven, non-blocking I/O model.
Synchronous I/O, on the other hand, processes tasks sequentially. When a synchronous I/O operation is executed, the entire thread is blocked until the operation completes. This means that no other operations can proceed, which can severely impact performance and responsiveness, especially in a server environment where multiple tasks are expected to run concurrently.
Despite the general consensus against using synchronous I/O in Node.js, there are situations where it might be considered acceptable. One such instance is during the loading of code modules, where synchronous file system I/O is often used. This is seen in both CommonJS and ESM module loading, although the latter could potentially be redesigned to avoid this.
Another situation is in command-line interface (CLI) applications where operations are simple and limited in scope, and where developers are certain that no other processes will be impacted by synchronous operations. However, even in these cases, best practices suggest sticking to asynchronous patterns to maintain consistency and future-proofing.
Legacy systems can present challenges when transitioning from synchronous to asynchronous I/O. For example, older systems or applications may have been designed with synchronous operations in mind. Rewriting these systems to accommodate asynchronous I/O can be complex and time-consuming, requiring careful consideration of how to maintain backward compatibility while improving performance.
Several strategies exist to handle synchronous I/O needs in Node.js without compromising the non-blocking nature of the environment. One approach involves using workers combined with atomics to simulate synchronous behavior. This method involves creating a separate thread to handle asynchronous operations while the main thread waits for completion, effectively blocking until the task is done.
Another potential solution is utilizing WebAssembly (Wasm) and the WebAssembly System Interface (WASI) to run compiled code synchronously. This approach allows for synchronous execution of compiled languages like C or Rust, although it involves complexities such as serialization and deserialization between JavaScript and Wasm code.
Developers can also consider writing native add-ons in languages like C++ or Rust. These add-ons can perform synchronous I/O operations and be called from Node.js. However, this requires significant effort to implement and maintain, especially when dealing with the Node.js networking stack.
In some cases, transforming asynchronous code to be used synchronously can be achieved through transpilation techniques. For instance, using tools like Babel to convert asynchronous code to synchronous code, although this approach may not cover all language features and can have limitations.
The journey to balance synchronous and asynchronous I/O in a Node.js environment reflects broader challenges in software development, such as maintaining performance while ensuring compatibility with existing systems. Developers must weigh the trade-offs of each approach and consider the specific requirements of their applications when deciding how to handle I/O operations effectively.
Ultimately, understanding the implications of synchronous versus asynchronous I/O and exploring various strategies to address these challenges can lead to more robust and efficient applications. The key is to remain adaptable and open to evolving best practices, leveraging the strengths of Node.js and its ecosystem to build responsive, high-performing software solutions.
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