A Comparison of Web Workers

Rate this content
Bookmark

Modern browsers come equipped with three types of Web Workers: Dedicated, Shared, and Service Workers. While each one offers the ability to execute JavaScript in a separate thread, their differing APIs and capabilities mean that any given task usually has an ideal worker. Learn the benefits of each worker and how to choose the right one.

Thomas Hunter II
Thomas Hunter II
25 min
18 Feb, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk compares web workers, including dedicated workers, shared workers, and service workers. Web workers provide multithreading capabilities and use shared memory for higher performance. Dedicated workers have one parent and can execute on a separate thread. Shared workers can have multiple parents and are useful for communication across different windows. Service workers can intercept and proxy requests made from a web page and are useful for caching network assets and building progressive web apps.

Available in Español

1. Introduction to Web Workers

Short description:

Hi, I'm Thomas Hunter and this talk is a comparison of web workers. Today we're going to talk about dedicated workers, shared workers, and service workers. JavaScript is single threaded, but web workers provide multithreading capabilities. Web workers use shared memory for higher performance and multithreading. Each JavaScript environment is isolated, with its own variables and globals. Web workers cannot access the DOM, but shared memory can be used for data access.

Hi, I'm Thomas Hunter and this talk is a comparison of web workers. The content from this talk is adapted from a book I recently published, Multithreaded JavaScript. If you'd like more about the book, feel free to follow that bitly URL at the bottom of the screen.

All right. So today we're going to talk about three separate topics. The first one is dedicated workers. The second is shared workers. And the third is service workers. Each one of these workers is a type of web worker.

But first, I'm actually going to talk about some basics. So, first, the concept of multithreading JavaScript. One thing to keep in mind is that it is the nature of JavaScript and its ecosystem to be single threaded. So for the longest time, there really existed no true multithreading capabilities in JavaScript. You can sort of pull some of this off by using basic message passing, using iframes. But it wasn't exactly the cleanest solution. However, now we have web workers available to us. And with that comes a feature called shared memory, which allows for higher performance and multi threading than just using message passing. This presentation is going to be from the perspective of using these web workers from a multi threading purpose since it is sort of related to the book.

All right. So another basic concept is, well, what is a JavaScript environment? Well, a JavaScript environment is an isolated collection of variables, globals, things like, you know, capital O object are going to be different in these separate environments, the prototype chains, you know, what those objects end up pointing to are different in these different environments. Each one each additional environment is going to incur some overhead to spin up and so with Node it's easier to measure. In my experiments it was about each new work of thread instance consumes about six megabytes of memory. In a browser you're going to get some more overhead. Web workers will incur some additional memory overhead and then if you have additional pages there's even more overhead as there's different documents and rectangles that need to be rendered.

So, these object instances that are created in these different environments, they can never truly be shared across environment. However, you can serialize these objects, you can sort of clone them, or you can represent them as JSON and then pass them around between the separate environments. However, if you mutate one in one place, you're not mutating it in the other. None of the web workers that we're going to look at today have access to the DOM. So, for example, the document object global is not available within the web workers. Using the shared array buffer, if you pass one of those between these different environments, a pointer to this the same binary data in memory will end up getting shared and that's how we can perform shared memory data access.

2. Dedicated Workers

Short description:

A dedicated worker is the simplest type of web worker. It has one parent and can load other dedicated workers. Each worker provides a new JavaScript environment and can execute on a separate thread. To work with a dedicated worker, we instantiate a worker instance, attach a message handler, and pass messages using postMessage. The worker.js file handles messages received from the parent and can perform CPU-heavy calculations before sending a message back.

And a lot of this explanation is short of hand waving over some complexities under hood with relation to context and realms and really how the JavaScript VM works.

All right. So, now let's take a look at dedicated workers. What is a dedicated worker? Well, a dedicated worker is the simplest of the web workers that we're going to look at. Each one of these dedicated workers can have exactly one parent. You can actually end up loading them as a hierarchy if you want where dedicated workers can load other dedicated workers as well. And each one of these workers gives us a new JavaScript environment. Each one is also able to execute on a separate thread.

So, now, let's look at a code sample. This is how we would work with a dedicated worker from the context of the web page. So, maybe this sits in, like, an index.html file. Maybe it sits inside main.js loaded by an HTML file. But at any rate, this runs within the main thread that draws the window. And so, modern browsers give us a capital W, worker global. We're able to instantiate that to create an instance of a worker. The argument to this is the path to a file we want to use is the worker. Once we get the worker, we can attach a message handler on it. Here I'm assigning this dot on message handler, which is a callback function. When this function gets called, it's going to print the message from worker and then print the data that was passed into it. This code will get called within the parent thread when the dedicated worker thread has passed a message to it. And then conversely, if we want to pass a message into the worker, we call worker.postmessage where we pass in an argument. I'm passing in a string, but we could pass other simple values as well or basic objects with a few caveats. And then finally, at the end of the file, we're just logging that the end of the main.js file has run.

So now let's look at the dedicated worker inside the worker. So this is our worker.js file that was referenced in the previous slide. So in this file, the first thing we do is we just log that we're inside the worker. And then we assign a global on message handler, which accepts the message that was passed in from the parent. And so within this handler, we'd log a message that we received a message from main, we log the data that was passed into us. At this point in time within an application, this might be a good place to perform a heavy CPU, CPU heavy calculation. And then finally, we can call the postMessageGlobal to post a message back to the parent.

3. Executing Code and Dedicated/Shared Workers

Short description:

Let's execute the code and look at the output. We see the message Hello from Main, which is passed into the child. The message is then received by the worker and processed. The worker prints 'hello from worker' and 'from Main message to worker'. The final message from the worker is printed as well. Dedicated workers give access to an additional thread, allowing offloading of CPU-intensive work and preventing slowdowns. However, if the parent dies, the dedicated worker will also die. Shared workers can have multiple parents and are useful for communicating across different windows, as long as they follow the same origin rules.

So let's actually execute the code and look at the output. Here I've already executed it for us. So the first thing we see is we see the message Hello from Main. And then even though we pass the message into the child, we end up logging the message Hello from the end of Main. So a non-deterministic amount of time sort of passes before the message is actually received by the worker and processed. So within there we print hello from worker, and then we print from Main message to worker. And then finally, the message that was passed back to the parent thread is then printed as well. So from worker, message from worker, that's the final message there.

And so why might you want to use a dedicated worker? Well, the most important reason in my opinion is that it gives access to an additional thread. And so this is a great way to offload CPU-intensive work or things that might otherwise slow down a web browser. Things that might cause scroll jank, you're able to offload this additional thread. And so you pass the message to the thread then the main thread is able to perform other work. And then once it receives a message back from that dedicated worker, it's then able to handle that value and then sort of continue with what it's doing. One thing to keep in mind is that a dedicated worker, anytime its single parent dies, that dedicated worker will die as well.

And next up, we're going to look at shared workers. What is a shared worker? Well, a shared worker it's actually pretty similar, but it can actually have multiple parents. And so it's useful for communicating across different windows. There's a caveat that these windows need to be on the same origin. So for example, you can't have the Google web page communicating with the Microsoft web page. They have to follow the same origin rules. So let's again, look at some sample code. And so first we're going to look at the code that might run within like an HTML page. And so we can pretend that we have two different HTML pages. Both of them have a script. One is the red HTML and the other is the blue HTML. And so within these files, we have like a script tag that's instantiating a shared worker. So the shared worker is available again in modern browsers with a small caveat that I'll cover at the end. So much like the other workers, we instantiate the shared worker and we pass an argument, which is a path to the file, to be used as the worker file. However, the API to interact with it is slightly different where instead of assigning an onMessage property directly on the worker, we assign it to a port. And so that port property represents a communication port into the worker itself.

4. Using Shared Workers

Short description:

The shared worker interface is similar to the dedicated worker, with a callback that takes an event argument. We pass a message into the shared worker using worker.port.postMessage. In the shared worker JavaScript file, we generate an ID, print a log message, create a set called ports to store the passed ports, and handle connections using the on connect method. We extract the port from the connection, add it to the ports set, and log the connection and the number of connected pages. We also assign an on message handler to the port to handle incoming messages. With shared workers, we can have multiple parents, so we iterate over the ports set and call postMessage on each port to send a message back. Let's execute this code on our machine.

And so the interface otherwise, this is fairly similar to the dedicated worker where it's a callback that will take an event argument with a data property that's passed into it. In this case, we're just logging a message that says we received an event. And then so later what we'll want to do is pass a message into the shared worker from one of the HTML files. And so to do that, we would call worker.port.postMessage, passing in the message that we want to pass into it.

All right. So here's some code on how to use the shared worker from the perspective of the worker. So this is our shared worker JavaScript file. Now, there's a bit of complexity going on in here. And I'll try to sort of explain everything step-by-step. But really, the purpose of this is just to sort of show how the shared worker works. So the first thing I do in the shared worker is I generate an ID. So that number, it's just a big random number to sort of show that this code is only going to be executed once. And so the next thing we do is we just print a log message that we're inside the shared.js file and we log that ID again. Next up, we're creating a variable called ports. And that's a set, and that's going to contain the ports that are passed into it. After that, we have an on connect method that's assigned to the self. And so what this is, this is a callback that gets called every time a different webpage makes a connection to the shared worker. So if you've ever worked with web sockets, this code pattern might feel a little familiar. So the first thing we do is we extract the port from the connection, and then we add it to our ports set. And then we just log that a connection has been made. We're just logging the the ID again and then also the size of the ports, which is going to tell us how many pages are connected.

After that, we signed an on message handler to the port itself, and that's saying that when this port receives a message. So when one of the HTML pages sends a message into this shared worker, we want to be able to handle it here. So again, we'd slog into the message, we'd say that the message was received, the ID in the data was passed in. Now, previously with the dedicated worker, when we wanted to send a message back out to the parent, it was pretty straightforward. There was a single port and we would just post the message to it. However, with shared workers, since we can have more than one parent, that's why we're sticking each one of the ports into the ports set, and then we're iterating over them here, and then we're calling the post message on each of them. Now, post message, it only allows us to send a single value through it. However, in this case, I'm just sort of abusing an array to pass the ID and the data that was received as well. And so let's say that we actually go ahead and execute this code on our machine.

5. Shared Worker Communication and Usage

Short description:

We open the red.html file and the shared.js file is executed. An ID is generated, a connection is made, and the red.html connects to the shared worker. We open the blue.html file, another connection is issued, and the number of connections is now two. We pass a message into the shared worker and it prints the received message and its ID. The messages are dispatched to the calling HTML files. There's no guarantee on the order of execution. Shared workers are useful for communication across pages and maintaining variable scopes. They are not supported by Safari, but work in Chrome and Firefox. If coordination across pages is needed, the broadcast channel can be used as an alternative. A shared worker dies when its last parent dies.

So maybe the first thing we do is we open the red.html file. And so what happens, we're going to see that the shared.js file is executed. And we see that an ID was generated. That ID is 1, 2, 3, 4, 5, 6. And then we see that a connection is made. And the red.html has connected to the shared worker. And again, we print that ID. And the ID is the same.

Then we open up the other file. We open the blue.html file. At that point, we see that the other connection is issued. And the ID is repeated again. And we see that the number of connections is now two. And after that, we execute the post message example from two slides ago, where we pass in the message, hello, world, into the shared worker. And so when that happens, the shared worker prints that it received a message, prints its ID again, and the message that it received. And then it dispatches those messages to the calling HTML files. And so when that happens, the event line is called, the final two event lines are printed to the screen. And those will be seen within the console for the inspector on those specific pages.

There's no sort of guarantee in this case, the order in which the right of the blue HTML logs get made. That's a bit of the fun excitement of multi threading is that there's not always a guarantee on the order in which this stuff gets executed. So, why might you use a shared worker? Well, perhaps you need to communicate across pages. You know, it's pretty useful for keeping, like, a context with variables associated with it, and particularly in cases where you want those variable scopes to outlive of the life of a page. And so perhaps some heavy, you know, single page applications might depend on this. We really want to coordinate things across different pages. So, another pattern is perhaps you want to make a singleton, you know, single, singleton, source of truth, and you want that to be accessed across pages. One thing to keep in mind is that, unfortunately, shared workers are not supported by Safari. I believe they support them at some point, but then for security considerations, they end up removing it. However, it does work in Chrome and Firefox. If you do find yourself needing a pattern to coordinate communication across different pages, you might consider using the broadcast channel as an alternative, and that is available in modern browsers as well. Now, one thing to keep in mind is that a shared worker is going to die when its last parent dies, and so if we were to open multiple pages, maybe you end up opening 10 of them, it's not until, you could then start closing these different pages and it's not until you close the final page that the shared worker would end up being killed as well.

6. Service Workers and Intercepting Requests

Short description:

Service workers are the most complex of the web workers. They can intercept and proxy requests made from a web page, including fetch requests, AJAX requests, and loaded assets. Service workers can technically have zero parents and run in the background. They can be used to share state between same origin windows. To create a service worker, we use the navigator.serviceWorker.register method with a path to the worker file and a configuration object. The scope property defines the URL range the worker can control. We can handle state changes, such as oncontrollerchange, and log messages when the service worker takes control of the page. The makeRequest function fetches data from a file and logs it to the screen. The service worker file, sw.js, is where the service worker logic is implemented.

You can also sort of manually terminate these web workers if you so choose. All right, so finally, let's take a look at service workers. What is a service worker? Well, a service worker is the most complex of the web workers. The sort of the coolest feature that they support is the ability to intercept or otherwise proxy requests that are made to a server from a web page. And so, this includes things like, oh, the fetch request, sort of AJAX requests, but also includes things like images that are loaded, assets that are loaded from CSS, the favicon file. A lot of that stuff, basically all of it ends up getting sent through the service worker.

One thing that's interesting about the service worker is that it can actually technically have zero parents, and it's sort of hand wavy, runs in the background. And so, you do need a page to run to actually end up installing the service worker. But then once that page closes, the service worker technically remains installed in the browser. Sort of the behavior on when it sort of comes and goes, when it lives and dies, that's a little bit less defined in the sense that it's not something you would necessarily want to depend on. So, you can use the service workers to share state between same origin windows as well.

All right. So, let's look at another code example. So, in this case, when we look at service workers as they're seen in the web page, again, so in this case, the interface to create the worker is a little bit different. Here we're calling navigator.service work.register. Much like with the other web workers, the first argument is a path to the file that represents the worker. There's also an additional configuration object, and the most commonly used configuration property in this is that of the scope. And so, the scope allows us to define the URL range that the worker can control. So, in this case, we're saying, you know, things that are loaded that begin with a slash end up being in control. Essentially it's saying everything on this domain is sort of under control. We also get some different state changes that we're able to hook into. In this case, we're handling the on controller change, and we're just gonna log a message to the screen. So, what that says is that, when the current page, when a service worker ends up taking control of the page, which means at that point in time that requests are intercepted, we're just gonna log a message that it is now functioning. So, the final function we have here is the make request. So, this is just for illustrative purposes, and we'll execute this in a little bit. But what this does is it just makes a fetch to a file in the current server called data.json. Deserializes the result and then logs it to the screen. Alright, so now let's check out the service workers inside the worker itself. So, this is our sw.js file. This is the first half.

7. Service Worker Installation and Activation

Short description:

We create a variable called counter and set it to zero. The on install method logs a message when the service worker is installed. The on activate method logs a message when the service worker becomes active. The service worker intercepts requests from currently open pages after they are refreshed. The on fetch handler logs the received URL and checks if it ends in data.json. If not, it falls back to a normal HTTP request. If it does, the counter variable is incremented and a new response is created with a JSON object containing the counter. The content type is set to text.JSON. The logs show the installation, activation, and controller change of the service worker, but their order is not guaranteed.

So, the first thing we're doing in here is we're creating a variable called counter and we're signing it to zero. Next, we're assigning an on install method on our self object and that tells us when the service worker is being installed. So, in this case, we're just going to log a message that the install happened.

After that, we have an on activate, and so this tells this gets called when the service worker reaches the activation stage or state, as it were, these service workers act as a state machine. So, this happens, we're just going to log a message that the service worker is now active, but then we're also going to do something else that's kind of interesting. When a service worker is first activated, any pages that are open, requests that they send will not immediately get sent through this service worker. It isn't until the page is refreshed that those pages are then under control of the service worker. So, what we're doing here at the bottom, we're calling event.waitUntil, which accepts a promise, and the promise is the result of the self.clients.claim call. So, that's saying basically the pages that are currently open, the service worker will intercept the request. All right.

So, the file continues, and here's the second half. We also have this on fetch handler. This on fetch handler, this gets called every time the service worker receives a network request from one of the web pages. So, inside of this one, what we're doing is first logging the URL that was received. Next, we have an if statement, so in here, we check to see if the URL that was received ends in data.json. If it does not, then we skip to the end and we fall back essentially to a normal HTTP request. So, in here, we have this event that respond with, and that accepts a promise which resolves into a value that is given to the browser as a result of the request. And so, the value that we're giving it is then the response from fetch, which is a promise, and then the argument that we're providing to fetch is the incoming request, which is event.request. So, essentially, what that line is saying is just perform a normal request and don't really do anything with it. However, if the URL did end in data.JSON, we execute the body of that if statement. So, what we do in there is we increment that counter variable from before, and then we just call event.respondWith, you can ignore that return void, but we just call the event.respondWith, where we pass in a new response that we're creating from scratch. And so, the body of that response is a JSON object that contains our counter in the variable. And then, just for illustrative purposes, muscle setting the headers, so in this case, we're setting the content type to text.JSON. And so, if we actually execute this code, this is the logs that we'll see. So, the first thing we see is that the service worker is installed. Next, we see that the service worker has been activated. And then, finally, we see that the controller change has happened. Again, sort of the order of these messages is non-deterministic, as the browser, you know, may handle a log and buffer it in memory. Well, it will print a log from another location. So, the order of this, those first two messages, is not guaranteed.

8. Using Service Workers and Web Worker Comparison

Short description:

Next, we call make request from within the webpage, and that's gonna make our fetch request to the server. The main.js receives that message and prints the result, which in this case is counter set to 1. Service workers are useful for caching network assets, performing background synchronization, supporting push notifications, and building progressive web apps. However, a service worker's lifespan is not guaranteed, and it's recommended to use cache APIs for persistent storage. Dedicated, shared, and service workers provide additional threads for multi-threading purposes and have different characteristics and use cases.

Next, we call make request from within the webpage, and that's gonna make our fetch request to the server. So, that happens. We print that the fetch was made. It just prints the URL that was received, and then it returns the JavaScript object through the network request. And then, finally, the main.js receives that message, and then prints the result, which in this case is counter set to 1. And then, if we were to execute the make request function multiple times, each one of those requests would then result in a different counter.

And so, none of these requests actually get sent to that, to the server running at localhost port 500, they're all handled by the service worker. And so, why might you want to use a service worker? Well, it's really useful to cache network assets if an application is offline. You can use it to perform background synchronization of content that is updated, and if you update content on the server, the service worker can then sort of decide how to give that back to the client. If you want to be able to support push notifications, that's also done in the service worker. If you're like me and you like to build progressive web apps, and you like those apps to be added to the home screen, well, both Android with Chrome and iOS with Safari will make use of these service workers, and it's sort of one of the requisites before you can add your PWA to the home screen. One thing to keep in mind is that a service worker, it might die when the last parent dies, but it sort of sits around and there's not really a guarantee on how long those closures sort of remain in memory. So, if you think back to the example I had with that counter variable, that's actually a bit of an anti-pattern. You really wouldn't want to create a state in memory in a service worker where you would expect it to sort of hang around. And if you want to do things that are a bit more persistent, for example, you want to put things in caches. There's all sorts of cache APIs that are available within service workers to keep that stuff in a more persistent state. So, if you were to take a screenshot of this presentation, this is probably the one to do.

And so, here we have sort of a comparison between the different types of web workers. And so, on the far left, I have sort of the feature and then how it works for dedicated, shared, and service workers. And so, all three of these web workers, each one of them is gonna provide an additional thread which could be used for multi-threading purposes. If you have a server that's not serving content over HTTPS, but you can only use dedicated and shared workers, you are unable to use a service worker with it. If you need support Safari, you can use dedicated and service workers, but you'd have to avoid a shared worker. If you want to act as a HTTP proxy, well, then you need to use a service worker. A dedicated worker has one parent, a shared worker has at least one parent, and a service worker has at least zero parents. And then a dedicated worker dies with its parent, a shared worker dies with its last parent, and a service worker, it's a little bit trickier. All right. So that's been the presentation. This was a comparison of web workers. If you'd like to follow me, I'm on Twitter at tlhunter. This presentation is available at that bit.ly link online. And then if you're interested in finding out more information about the book, feel free to follow that last URL as well.

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

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
Making JavaScript on WebAssembly Fast
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
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
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Webpack in 5 Years?
JSNation 2022JSNation 2022
26 min
Webpack in 5 Years?
Top Content
What can we learn from the last 10 years for the next 5 years? Is there a future for Webpack? What do we need to do now?

Workshops on related topic

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
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
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
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.
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
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.