Deep Dive into Undici

Undici, the next-generation HTTP client built by the Node.js Core team, powers Node.js core fetch(). Let’s dig into how its internals, discovering how to work with Dispatchers, Agents, and Pools. Last but not least, we’ll even do some magic.

Rate this content
Bookmark
Video Summary and Transcription
This video explores Undici, a modern HTTP client designed for Node.js. Undici is engineered from the ground up, providing an efficient way to handle HTTP connections. The focus is on the Undici request function, which allows developers to make HTTP requests with ease, returning status codes, headers, trailers, and body. The Undici agent manages multiple pools and dispatches requests to the appropriate pool, optimizing connection management. Undici js is not based on Node.js's internal HTTP modules, offering a fresh approach to HTTP handling. The support for Undici HTTP2 is a notable feature, enhancing performance and compatibility with HTTP standards. Undici also introduces the concept of HTTP pipelining, allowing multiple requests to be sent in a single connection, improving throughput. The dispatcher is a key component, managing HTTP connections and requests while supporting global dispatcher configurations. Undici's separation of public API and connection management contributes to its impressive performance gains.
Available in Español: Profundizando en Undici

FAQ

Yes, Undici is built to be spec-compliant with the fetch API, ensuring high compatibility with browser fetch implementations.

The dispatcher in Undici manages HTTP connections and requests, allowing configuration of global dispatchers and connection pooling.

You can start using Undici by importing the 'request' function and providing a URL. It returns the status code, headers, trailers, and body.

Platformatic is a startup co-founded by Matteo Collina, providing tools and runtime to help developers build and manage Node.js applications efficiently.

Yes, Undici supports HTTP/2 in addition to HTTP 1.1.

Matteo Collina is the Co-Founder and CTO of Platformatic, a member of the Node.js Technical Steering Committee, and a board member of the OpenJS Foundation.

Undici is a modern HTTP client built from scratch for Node.js. It is not based on the internal HTTP and HTTPS modules.

'Undici' means 11 in Italian and refers to HTTP 1.1. It is also a reference to the TV show Stranger Things.

HTTP pipelining in Undici allows sending multiple requests in a single connection without waiting for the previous response, improving throughput.

Undici offers improved performance, separation between public API and connection management, HTTP pipelining support, and optimized memory allocation.

1. Introduction#

Short description:

Hi everyone, I'm Matteo Collina, Platformatic Co-Founder and CTO, and today I'm going to dig deep into Undici, the new HTTP library built by the Node Core team. A few words about me, I am part of the Node.js Technical Steering Committee as well as a board member of the OpenJS Foundation. I created some libraries that you might use. I worked eight years as a consultant, then decided to do a startup. Here is Platformatic.

Hi everyone, I'm Matteo Collina, Platformatic Co-Founder and CTO, and today I'm going to dig deep into Undici, the new HTTP library built by the Node Core team. A few words about me, I am part of the Node.js Technical Steering Committee as well as a board member of the OpenJS Foundation. I created some libraries that you might use. I spoke about them at Node Congress a few times, so you might want to check them out, both Fastify and Pino if you like them. I worked eight years as a consultant, then decided to do a startup. Here is Platformatic. I have a newsletter at node.landofdev, a YouTube channel, and so on and so forth. You can check it out. But in all of this, the important part is you're likely using my stuff, because my modules have been downloaded 22 billion times last year, which probably includes you as well, that you're watching this video.

2. Undici: HTTP Client for Node.js#

Short description:

Undici is a modern HTTP client written from scratch for Node.js. It's easy to start using and provides all the expected features like status code, headers, trailers, and body. Undici is also the home of fetch for Node.js and aims for high spec compatibility. It offers improved performance and a complete split between the API and connection management. Undici provides connection pooling and supports interceptors for integration.

Let's talk a little bit about Undici. Undici is a relatively new or modern HTTP client written from scratch for Node.js. What does it mean from scratch? It means it's not based on the internal HTTP and HTTPS module, but we created it from nothing. Undici, not of color here, means 11 in Italian, and comes from HTTP 1.1. It's also a Stranger Things reference because I was watching Stranger Things when this started to come into my mind.

How does it work? It's very easy to start using, to be honest. You can just import requests from Undici and just put your URL in, and you get all the things that you would expect. You get the status code, headers, trailers, and body. You get all the things. Note that it has implemented the same body mixing of fetch, so you can await body.json, for example. Something very important to remember is whenever you get a body, please consume the body. There are certain logic internally that will make sure that things are handled correctly, but clean it up if possible.

Undici is also the home of fetch for Node.js. When you use fetch inside Node.js, in reality, you're using fetch from Undici and Node.js bundle Undici internally. It's a spec-compliant fetch that you like and love. That's more or less all the things that need to be said. We are working very hard to have as much higher spec compatibility as possible, so this should in theory work as close to as possible as the fetch that you are running in your browser and also the other runtimes. If you need to have spec compatibility, if you want to work on spec compatibility for fetch, Undici is the right place.

What are the good things about Undici? First of all, Undici has improved performance. We'll go through that later. I have a cool few slides. It also creates a complete split between the API, the public API, the developer experience, and how connection management is handled. Something that was not present in HTTP.request and HTTP and HTTPS module. It has also multiple implementation. I said pool. Yeah, I said pool. HTTP is a connection-based protocol, so you probably want to do connection pooling. Despite all the literature says that HTTP is a stateless protocol, but it's stateless because you're talking about a stateful... How is this possible? Well, yes, of course, because it's stateless in the sense of semantics, but it's implemented on top of a stateful connection, TCP and TLS, of course. I will talk about what interceptors are and how to integrate with them.

3. Undici: Advanced Features and Performance#

Short description:

Undici is maintained by the Node Core team and provides support for HTTP 1.1 and recently added HTTP 2.0 support. The HTTP modules are a mess due to the same API structure for both client and server of HTTP 1.0. To overcome this, undici.request was created to be fast and highly configurable, using Node.js stream and supporting HTTP 1.1 pipeline. Undici Fetch is built to be spec compliant and internally uses WhatWGstream. It also supports HTTP2 and HTTP pipelining. Undici offers impressive performance, especially with Undici.Stream.

Also, it's maintained by the Node Core team, HTTP team, and in fact, most of us think that HTTP.request is almost unfixable and therefore that's what we are working on instead. At the beginning, it started from support for HTTP 1.1 only, then we also recently added HTTP 2.0 support, and now it's... You know, the Undici name might not be the best reference anymore. Anyway, so... Also, we have HTTP 1.1. It also has HTTP 1.1 pipelining support. So... It also... Something that is a little bit... There are some things that are different in it, so you might experience a few errors that you might need to deal with, essentially. So, why? Well, the problem is the HTTP, HTTP modules are a mess, okay? Mostly because they use the same API structure for both the client and the server of HTTP 1.0, and both of them are tied with the connection management with the public API. So, how can you see it? Well, you have a request.socket, okay? The fact that you have a request.socket property will tell you that there is this kind of connection, because if your system is not being on socket anymore, like on HTTP 2.0, how would you implement that? And this is the reason why you cannot support both HTTP 1.1 and HTTP 2.0 on the same API.

Finally, last but not least, we cannot change those classes without breaking express. So, yeah, well, that's the situation. So, we created undici.request to be as fast as possible, because making HTTP request should not be the bottleneck of your app. It also provides a good enough DX, a very good DX, from my point of view. It's highly configurable, it uses Node.js stream, supports HTTP 1.1 pipeline. It's great. Just use this. This is probably the code that you want to be using, okay? Undici Fetch is built to be spec compliant, okay? So, it's not putting performance as the top priority. It's spec compliance that it is. And right now, 88% of the WPT tests that we are running for Fetch, we are passing them. So, I think it's pretty good compatibility overall. However, internally, it uses WhatWGstream, so you can use Pipe2, WhatWGstream, all the things, the Redible stream, like the browser. So, all the code that uses Undici Fetch and Fetch Node could be isomorphic. Again, the protocol handling and the API are completely split, so all the things that we are going to talk about, Undici and connection management and so on, all apply to both. And this is the reason why Undici Fetch was built on top of Undici. The Fetching Node was built on top of Undici. It also supports HTTP2, HTTP pipelining, because of this separation.

Okay, let's talk about performance, because this is the critical stuff for it, okay? So, which, you know, it's the numbers are really significant here, okay? Like, Undici is pretty much unconstrained, okay? You can use, on this testing system, you can actually use Undici, one of the lowest level APIs, which is Undici.Dispatch, but to be honest, this is not what you should be using, okay? It's the underlining bit, or Undici.Stream, which is, you know, even faster, but again, probably too low a level.

4. Undici: Performance and Request Speed#

Short description:

Making HTTP requests should not be the bottleneck of your app with Undici.Request. Undici offers impressive performance, especially with Undici.Stream.

You can get those up to a huge amount of requests going out from a single node process, okay? Getting 20,000, 21,000 requests per second out, it's a lot of requests that you're going to send, okay? So, essentially, our goal is making HTTP requests should not be the bottleneck of your app with Undici.Request. And you can see how the other APIs are being set up. So, we have SuperAgent, we have HTTP from Node Core, we have Axios, how Axios performs, we have the old school request module, how that performs down to Undici.Fetch, which is actually slower, okay? As I said, there are a lot of things that can be optimized still, which is just a tad bit faster than Node.Fetch, which is great, and then we have got at the end.

5. Undici: HTTP 1.1 Pipelining#

Short description:

If you are experiencing performance problems doing HTTP requests, switch to Undici. HTTP 1.1 pipelining allows sending multiple requests at the same time, cutting response time significantly. However, head-of-line blocking can occur if the first request is delayed. Despite this, pipelining can improve throughput, particularly when calling microservices.

Okay, just to clarify, all of this is actually very important to note, that if you are experiencing any performance problems doing HTTP requests, you probably should switch to Undici. I talk a lot about HTTP 1.1 pipelining, and I need to, I really want to explain it, okay? Because otherwise you probably won't know what I'm talking about. So, in a normal HTTP request, when you open a client, a request from a client to a server, okay? First of all, there is a ping pong, okay, of opening up the HTTP request, okay? On top of that, you need to add TLS if there is TLS. So, yeah, a lot of exchanges. Once you have this connection set up, okay, the client sends one request into that socket, okay? Once the socket came back, it does the processing and gets it back to the beginning, and then it can send a second request on that socket. I told a lot about connection pooling. So, you have, essentially, if you want to talk to another microservices in your network, you have, I don't know, three, four, five, 10, 20, 50, whatever connections. So, you want to, you know, allocate one connection to a request up until you get the next second, the request, the next request after. So, if you have 50 connections, essentially, it means that there can only be 10 connections, sorry, 50 requests in flight overall, because each one connection, one request, okay? Pipelining changes that. So, with pipelining, we can send two requests at the same time, okay? We can send one request, we can send two requests at the same time, one after the other. Now, this is great because we can actually cut the response time significantly because we send two messages and we can save all the round trip time, okay? The servers then will need to parse those one after the other and then send us back the results, okay? Which is fine because if you slide in this example, it takes 172 milliseconds to get both responses while in the other one is 228. So, we are actually responding sooner and having data sent back sooner, but there is one catch, okay? What happens if the first request is delayed? If the first request is delayed, okay, as you can see in this example, we are actually losing a lot of processing, okay? The second one, the shorter one, needs to wait to be sent, okay? Because first, I need to send the first one and then I need to send the second one. This phenomenon is called head-of-line blocking. So, okay? So, great, not great, you need to take this into account, okay? But especially when calling microservices, this is probably fine or my experience is this is fine and it can help us achieve way, way, way more throughput because we can use our sockets way better, okay? So, let's take a look inside and how this works.

6. Undici: Connection Management#

Short description:

We separate the API from the internal and manage the connection pool manually. The key part of connection management is the dispatcher, which can be changed using SetGlobalDispatcher. The hierarchy of dispatchers includes the abstract class, the dispatcher for connection management, the client, and the pool. The balanced pool uses an algorithm to choose the socket with the best latency. The agent allows working across multiple pools, one for each origin.

And first of all, we have, we want to provide the foundation for HTTP next. And, as I said, we separate the API from the API, the API that users use from the internal. So, there are two separate layers, completely independent from each other.

And all the internals are callback based. They're not based on error backs and they're not based on events, okay? So, they're based on lower level mechanism that is extremely fast. So, we are not having any overhead whatsoever.

Also, we manually manage our connection pool, okay? And you can do different things. And we are very picky about overhead and memory allocation. Last but not least, we minimize the transition between C, C++ and JavaScript.

So, the key part of the connection management and how you interact with internals is by the concept of a dispatcher. And there is an API in Undichi that's called SetGlobalDispatcher. So, if you want to change the global dispatcher or the global mechanism for handling the HTTP request, you can do it anytime via the Undichi library, calling SetGlobalDispatcher and passing either an agent or something else that we'll talk about sooner. You can configure a lot of things. You can put a lot of parameters in here. So, you check it out. Now, what's important to note is that calling SetGlobalDispatcher from Undichi will also change the one from fetching Node.js, as the two things are built to be completely interoperable.

So, what is the hierarchy of those dispatchers? So, we have a Dispatcher abstract class, which includes a bunch of things. And it includes a lot of the fancy methods. And then we have an abstract that implements the dispatcher for connection management. And from there, we have the client, which wraps a socket, a connection. Then we have the pool. And the pool, it's an array of clients, essentially. So, if the pool receives a request, it says, oh, give me a free client. Otherwise, it waits. The balanced pool is an alternative system that uses a recent algorithm that was published on a recent paper that allows us to choose the socket that will offer the best latency for that specific request. How does it work? Yeah, it's a complex algorithm. So, check it out. It uses a lot of weight and math to make it do its job. What does the agent do? Well, the agent allows you to work across a group of pools. One for each origin.

7. Undici: Dispatchers and Interceptors#

Short description:

The agent coordinates requests to the right pool and allows for the creation of a mock agent. The dispatcher's dispatch method separates the lower level interface from the higher level. A retry agent can be used to retry failing HTTP requests. Dispatch interceptors offer an alternative to the dispatcher class. The UndiciOIDCInterceptor module automatically issues machine-to-machine OIDC tokens for requests to specific destinations.

So, if you have a combination of domain plus port, or IP plus port, then the agent is the system that coordinates it and sends a request to the right pool. This system also allows us to implement a mock agent or a mock system for Undici, which is built in. So, you can actually configure a mock agent, and the mock agent can be set up to only intercept a few requests. So, if you configure this, you can intercept a request and you can wrap it via the mock agent. Seems fantastic, right? There's no monkey patching happening, nothing. This just works out of the box.

Why is it called dispatcher, though? Well, because a dispatcher has the most important methods for dispatcher is the dispatch method. And the dispatch method takes an option object, which describes the request, and a handler for that request. A handler is a complex object that implements a lot of callbacks for a lot of different states of the HTTP request. And if you're calling dispatcher.request internally to use a request handler, and stream, stream handler, fetch, fetch handler, pipeline, pipeline handler, yeah, seems about correct, okay? And this is how we separate between the lower level interface, which is dispatch, and the higher level, like request, fetch, stream, and so on and so forth.

This system allows us to create something like a retry agent. So, let's imagine that you want to retry your HTTP request because they are failing, for whatever reason. Well, the retry agent just does that, okay? It's built in, okay? So I don't need to do much. I can either configure it as a global agent, or I can just call it. Works great. Internally, this, it uses the, implements a retry handler. So the retry agent, when you receive the dispatch method, creates a retry handler, okay, that will, that essentially wraps the previous handler and adds some retry logic. Hey! That works, okay? Pretty neat, right? And it's endless all the way down. And one of the options in, inside the, for dispatcher are the dispatcher interceptor, okay, sorry, and the dispatch interceptors essentially are just objects that has a dispatch function. That's it, okay? Which offers the same API as the dispatcher class, okay? But an interceptor only, it's an object that only have dispatch. The other, dispatcher also have a lot of other methods in it, okay? And for example, what I have created, it's a system to automatically issue M2M, machine-to-machine, OIDC tokens for each request coming out to a certain destination. In this example, and you can check it out, it's a separate module called UndiciOIDCInterceptor. And we can, when you create an agent, you can configure your interceptors in the code, okay? It's pretty, it's pretty great. It's pretty neat and pretty great from my point of view. And you can check it out, in this slide on the right, you can see a big example for about what the provider does look like. It's a lot, okay? It's a lot of code, a lot of config, but it's compatible with Auth0, for example. It's compatible for anything that is OIDC compatible and supports machine-to-machine tokens. So pretty great from my point of view.

8. Undici: New APIs and Platformatic Runtime#

Short description:

Undici v7 is coming with improved APIs. Benchmark results show that most of the time is spent on initializing WOTUG streams. The new HTTP RFC 9110 allows implementing HTTP logic on anything. Fastify Undici dispatcher bypasses HTTP request logic to route requests to Fastify server. Platformatic runtime enables running multiple microservices in the same process.

It's compatible for anything that is OIDC compatible and supports machine-to-machine tokens. So pretty great from my point of view. But be careful, because probably in the next release of Undici v7, we'll be changing these APIs. So we are working on something better.

So from the code, the example we did at the beginning, you wonder why fetch is low, okay? So I took the liberty to run this benchmark. Very simple, very, to be honest, straightforward. We are issuing a hundred thousand fetch requests locally and get the text. And that's it. And you will be much surprised at where we are spending the time. All the time, most of the time, 50 percent of the time is actually spent in initializing the WOTUG streams, okay? Not HTTP processing, not anything else, only initialization.

Something that does all of this means that you can use the dispatcher logic also to make some magic, okay? So, in fact, because of how this works, the new HTTP RFC 9110 just splits the semantics from the transports, from HTTP 1 and HTTP 2.2. So basically, the wiring format is now only an implementation detail. So basically, it means that we can implement the HTTP logic, okay? The HTTP semantics on essentially anything, which is fantastic.

So what you could do is essentially implement it with Fastify, the Fastify Undici dispatcher, which is another dispatcher from Undici that completely bypass the HTTP request logic and create essentially a mesh network inside your process to route your request to your Fastify server. It's pretty fantastic.

All of this, that I told, powers the new platformatic runtime, which is a system to run multiple microservices inside the same box, inside the same process. And I don't know, check it out. It's there. I don't think I have time for a demo, but stay tuned, because I will be publishing something sooner rather than later on this front. And thank you very much for watching, and bye-bye.

Matteo Collina
Matteo Collina
24 min
04 Apr, 2024

Comments

Sign in or register to post your comment.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
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.
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
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: Enhancing Module Loading in Node.js
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
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.
Out of the Box Node.js Diagnostics
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
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.
Node.js Compatibility in Deno
Node Congress 2022Node Congress 2022
34 min
Node.js Compatibility in Deno
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.
Multithreaded Logging with Pino
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
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.

Workshops on related topic

Node.js Masterclass
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Top Content
Workshop
Matteo Collina
Matteo Collina
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.

Level: intermediate
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Matteo Collina
Matteo Collina
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.
Building a Hyper Fast Web Server with Deno
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Matt Landers
Will Johnston
2 authors
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.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
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
Mastering Node.js Test Runner
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Marco Ippolito
Marco Ippolito
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.
GraphQL - From Zero to Hero in 3 hours
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
Pawel Sawicki
Pawel Sawicki
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.