Forem: Dubymar Tollinchi

The Thread States and Life Cycle in a Java Multithreaded Environment

Dubymar Tollinchi — Mon, 16 May 2022 18:49:16 +0000

Before diving into the life cycle of threads in Java, let’s start with some basic concepts about this topic. A thread is a lightweight subprocess; it represents the smallest unit of processing, thus making it possible that multiple threads can use a shared memory area and run concurrently. Despite this, they are independent, meaning that in the case of an exception, one doesn’t affect the others. They exist inside a process, and this process can have multiple threads. At the same time, many processes can exist in the operative system. The task of running more than two threads simultaneously is called multithreading, and it maximizes CPU memory and saves time.
The life cycle of threads consists of the following states:

New: whenever a new thread is created, meaning that the code has not been run and the thread has not been executed yet, is called the new state. It is the very first state a thread can be in.
Active: a thread can go from a new to an active state after the start() method is executed. This state can be split into two states:
- Runnable: in a multithreaded environment like Java, several threads can be executed at the same time. Each one gets a fixed amount of time to run, and it’s the thread scheduler who provides that time and moves the thread to the running state. Once a thread is done running, it gives the CPU to another thread to run. All other threads that are waiting to run are said to be in a runnable state, which can be represented as a queue that contains all threads in order.
- Running: it is the moment where a thread gets the CPU to be able to run. Threads come in order from the runnable state to the running state and generally go back to the runnable state after they are run.
Blocked/Waiting: whenever a thread is temporarily inactive is either in the blocked state or waiting state. To explain these states, we need to talk about inter-thread communication and the concept of synchronization. In Java, there is this concept of a “monitor” (a synchronized block), which we can picture as a box that can only contain one thread at a time. When a thread has a lock on this block, it is in its running state. The rest of the threads that are waiting for a monitor lock are in the blocked state. Threads remain idle until the wait() method is called, placing them in a waiting state. In this state, the main thread is waiting for another thread to finish its execution, and once this happens, it then calls notify() so the main thread can acquire the monitor lock, and therefore, go to the active state.
Timed Waiting: if a thread is being run and it enters a critical section of code that is not possible to leave, other threads can be waiting forever. This concept of eternal waiting is known as starvation, and to avoid this, a specific amount of time is given to each thread in the timed waiting state. For example, the sleep() method puts a thread in this state, and after the specific amount of time runs out, the thread wakes up.
Terminated: a thread moves to the terminated state (also called dead state) when it finishes its job. For example, when the run() method completes its execution, it would represent a normal termination. If any unusual event occurs, such as an unhandled exception or a segmentation fault, it is called an abnormal termination. Once a thread is killed, it cannot go back to any other state. Threads go from one state to another from the very beginning of the program execution. Java’s multithreaded environment allows multiple threads to be executed and moved between states, but since they share the same memory area, the CPU can be used by only one thread at a time. This thread will be the only one in a running state, while the rest of them will be in other different states. Since threads are lightweight subprocesses, they take little time to switch from one to another. This saves plenty of time when running a program, unlike process-based multitasking (known as multiprocessing), where each process has a different space in memory, is heavyweight, and switching between them can be time-consuming.

Building an Express back-end for basic CRUD operations

Dubymar Tollinchi — Wed, 08 Dec 2021 20:14:00 +0000

When enrolling for college, I had to choose between Web Development and Web Design. This decision was quite easy because I thought "making a website look pretty is something that most developers can do (not saying it's easy tho!), but making a website be completely functional? That's more of a complex job, and that's a challenge I want to take".

In my Web Technologies class, after learning the basics of JavaScript and working with front-end, it was time to swim into the deep waters of the back-end of a website. I was assigned to create RESTful routes that interact with a MongoDB database using Node.js and Express.js. It was very confusing at the beginning, but after building a few small projects applying the same steps, I feel more comfortable to share the knowledge I acquired with this community.

So let's dive into it!!

The first thing we need to know about is Node.js, and I already wrote a post about it, so go check that out so you understand why and how it is used. After installing Node, we will use the terminal to install the required dependencies, in this case are: dotenv, express, and mongodb. Luckily, I used a template that already had all these installed, but if your project does not have any of these, just type npm install express on the terminal, repeating the same syntax with the other packages.

The second step is to create a .env file, which will contain the database URL that will connect our application to MongoDB. This file will be untracked, since we do not want to include it in our commits. This is more of a security reason, because why will we want strangers accessing to our database, right?

DB_CLIENT_URL=databaseurl

The third step is to go into our config.js file and declare the configurations for our project. In this case, I have the port, database URL, name, and collection name. Having this information here and not in other files will make our website easier to maintain, having to change it just here and not everywhere.

export default {
  port: process.env.PORT || 3000,
  db: {
    clientURL: process.env.DB_CLIENT_URL,
    name: "sample_airbnb",
    collectionName: "listingsAndReviews"
  }
}

As you can notice, there is no way to see the actual database URL. For this project I used an Airbnb database sample from MongoDB, but in case I want to use another database, I can change the name and collection right there and that will be applied to the entire project.

The fourth step is to create a db/conns (database connections) folder, and inside create a client.js file, that will contain a reusable Mongo client to connect to our application. Here is where we use that mongodb package that we installed earlier. Note: this is the only file inside of that folder, everything else from now on will continue to exist inside the server folder.

import { MongoClient } from "mongodb";
import config from "./config.js";

const client = new MongoClient(config.db.clientURL);

client.connect()
  .then(() => {
    console.info("MongoDB Client 🏃🏾‍♂️");
  })
  .catch((err) => {
    console.error("Error starting MongoDB Client", err.message);
    // Exit process with failure
    process.exit(1);
  });
process.on("SIGINT", () => {
  client.close().then(() => {
    console.info("MongoDB Client disconnected");
    process.exit(0);
  });
});
export default client;

Once we have our Mongo Client successfully connecting to our database, we can proceed to create our routes in the router.js file. First, we will start with a test route to connect to our API. We need to import the content from config.js, client.js, and our Router from express.

import Router from "express";
import config from "./config.js";
import client from "./db/conns/client.js";

// create collection variable to reduce code duplication
const collection = client
.db(config.db.name)
.collection(config.db.collectionName);

const router = new Router();

// localhost:3000/api
router.get("/", (_, res) => {
    res.send("Hello from API router");
});

export default router;

To utilize this router we need to import it to our index.js file, using express as the framework that will make our lives easier. Express gives developers all the tools they need to create HTTP servers, allowing to receive and send data as JSON.

import express from "express";
import config from "./config.js";
import router from "./router.js";

const app = express();

// json middleware allows to send and receive JSON data
app.use(express.json());

app.get("/", (_, res) => {
  res.send("Hello World");
});

app.use("/api", router);

To run our server we can type npm start in our terminal, and then go to any explorer and type http://localhost:3000/api and that will show "Hello from API router". Now that our testing route is working, we can proceed to create the rest of our routes. In this project we are using basic CRUD operations, which are Create, Read, Update, and Delete. In some of these route we will need to use Insomnia. These platform will allow us to send JSON data, since we are not doing that from the browser. The way we will send this information will be on the request body.

Let's start with the first route, which will be create a listing.

// post a new listing
router.post("/listings", async (req,res) => {
    const newListing = await collection.insertOne(req.body);
    res.json(newListing);
})

The second route will allow to read all listings. In this case, the {} inside the find method brings all listing, but we can also add any filters that we want inside {}. Let's have in mind that these filters must be in the MongoDB language, which is different from a later update of these route where we have optional filters, using in that case JavaScript filters.

// get all listings
router.get("/listings", async (_, res) => {
    const listingsData = await collection.find({}).toArray();
    res.json(listingsData);
});

The third one will take a listing id and update that listing. In the Insomnia body we can send the "payload", which is the updated data for our listing.

// update a listing
router.put("/listings/", async (req, res) => {
    const updatedListing = await collection.updateOne({ _id: req.body.id},
    { $set: req.body.payload });
    res.json(updatedListing);
})

And the fourth one to complete our CRUD operations is to delete a listing using its id.

// delete a listing
router.delete("/listings/:id", async (req, res) => {
    const deletedListing = await collection.deleteOne({ _id: req.params.id });
    res.json(deletedListing);
});

This project has more routes, such as reading an specific listing, getting all reviews from one listing, creating, updating and deleting a review from one listing. For your reference, this is the project repo.

These basic routes allow us to perform CRUD operations in our database, and although it is just a server-side project, this gives you an idea on how to create a full-stack website, if you already know how to connect to the client-side. Node.js and Express.js made possible to create and work with the server without knowing any other server-side language, such as PHP.

JavaScript References

Dubymar Tollinchi — Thu, 28 Oct 2021 19:36:42 +0000

A few years back when I was studying Electronic Engineering, one of the requisites was Programming I, II, and III. C++ was the first programming language I learned, and I must say it was the reason I chose my current career (I realized I hated dealing with hardware). One of my professors was an old lady that used to teach in the classroom writing code on the board, instead of using a computer. Although I thought it was a waste of time, writing things down several times helped me understand the core concepts.

I remember a class when she explained references, and how every piece of data has a place in memory. At first, it was quite difficult to understand, but finally, she used the word "pointer". Ok, I know what a pointer is and I can picture it (kind of like an arrow, I will say), now what? Well, let's say we have a variable named myFavCar that stores a value of "Ferrari". This piece of data is stored in someplace in the computer's memory, and it can be accessed by using its name, which is pointing to that place in memory. So, whenever we want to display the value of a variable, the function console.log uses the variable name as an argument and gets the data from where is stored.

let myFavCar = "Ferrari"
console.log(myFavCar); // prints "Ferrari"

Primitives vs. Objects

If we want to reassign that value to "Lamborghini" instead, we should start talking about immutability, and how primitives (String, Number, Boolean, Null, and Undefined) and immutable and how Objects (pretty much everything else in JS) can be modified. Since we are using a String variable, is not like Lamborghini will override ~~Ferrari~~. We can't modify a String, so what is going to happen is that myFavCar now will be pointing to another place in memory where this new value is stored.

let myFavCar = "Ferrari"
myFavCar = "Lamborghini";
console.log(myFavCar); // prints "Lamborghini"

This makes a lot of sense when I think about String methods returning a new String instead of modifying the current String value. That's why if we want to keep that new value, we have to store it in a new variable (aka, pointer to a new place in memory).

let text1 = "Hi";
let text2 = "there";
let text3 = text1.concat(" ", text2);
console.log(text3); // prints "Hi there"

// this does not modify text1 or text2 values

How does mutation work?

A mutation is something that we want to avoid at all costs, and that means making sure none of our functions change their arguments or anything outside of them. This kind of function is called pure function (I learned that today!). Whenever we pass an object as an argument for a function, that function can modify the object that's outside of the scope. A way to avoid this kind of mutation is to use the spread operator (...) and save a copy of the object and modify and return that copy.

let customer = {
   name: "John Doe",
   dob: "2/13/1987",
   address: "123 Park Ave",
   subscriptionAct: true,
}

function updateInfo(customer) {
   // create a variable that stores a copy of the object
   // this will be a NEW object
   let customerUpdated = { ...customer }

   // modifies the copy
   customerUpdated.subscriptionAct = false;
   return customerUpdated;
}

// the function will return a new object
// we save it in a variable
customer = updateInfo(customer);

Without the spread operator, customerUpdated will point to the customer object. So pretty much we will have customer and customerUpdated pointing at the same object. This is called copy by reference, and it means that if we modify either one, it will affect both of them.

Copy by value can be done with primitives, since they can't be modified, they just create a new place in memory to store that new value (even if it's a copy).

let a = "a";
let b = "b";
a = b;
b = "hello";

console.log(b); // prints "hello"
console.log(a); // prints "b"

In this case, a copies the value that's stored in b, which in this case is a String. After reassigning b a new value, we can notice that a didn't change. That's because it copied just the value, but does not reference that address where b is pointing at.

Understanding these concepts was difficult and very confusing at the beginning, but after a few years of programming in different languages, I was able to understand, being a crucial part of data structures and algorithms. I used this article as a reference for writing this post, which helped me understand these concepts even more.

Introduction to Database Schemas

Dubymar Tollinchi — Wed, 20 Oct 2021 17:18:55 +0000

About I year ago I took Introduction to Databases at my college, where I first learned SQL. I consider it to be quite a simple language to understand and write, considering my basic experience in that class. I knew database is an important concept for web developers to understand, so I made sure I understood the foundations.

What are database schemas and how to implement one?

When learning about databases schemas, the best way to describe them would be as a "blueprint". This blueprint will contain the shape and format of the data, as well as the necessary patterns to retrieve the information when requested. This is called logical schema and it is the first step to developing a database.

Designing schemas for relational databases

As I learned with relational (or static) databases, we do this applying Entity-Relationship (ER) models, which are diagrams that describe entities, their attributes, and how they relate to one another. Using ER models in the early stage of designing the database is very convenient since it gives you a clear idea of how your data will be stored, connected, and retrieved.

In class, the first thing I used to do was determine the entities that I had, and by an entity I mean a real-life "object" or "thing" that exists, something that we can identify. These entities have attributes, which describe the characteristics of these objects. One (or a combination) of these attributes should be unique, which would be used as the identifier.

Then, the fun part: figuring out how the entities are going to relate to one another. This is done using minimum and maximum cardinality, which will determine one-to-one, one-to-many, or many-to-many relationships. For example, students and classes: students can take many classes, and classes can be taken by many students. This easy example represents a many-to-many relationship, but in real life, even if you know how your data will be, figuring this out can be a headache.

Once everything is looking good we start developing the physical schema. The first step is to declare the tables, one per entity, and declare its attributes as columns. A very important step is to identify the primary key, which sometimes can be unique or composite. These keys will be used as foreign keys in other tables to relate to one another.

In my basic experience, relating tables can get complicated. Basic relationships between tables might just include a primary key of one table as the foreign key in another table, but also might include several tables with primary keys from different tables as foreign keys in one or more tables. So, it can get pretty messy.

During this stage, we use normalization to minimize data redundancy and inconsistencies. Normalization is a process where we split tables depending if we encounter certain elements that can be treated in their separate table. Another thing to have in mind is predicted query patterns and what tables will be accessed more than others. By doing this we can identify database indexes, so we can speed up the retrieval process.

Designing schemas for non-relational and NoSQL databases

This process is often quite different. Non-relational databases are used for high performance using a limited number of predefined queries. These database schemas are designed depending on the application that will use them.

The first step is to determine the primary queries (pseudo queries, since the database, does not exist yet) the database needs to run. Knowing this will help us understand how we can structure our data in a way that is optimized to retrieve.

const customer = {
    id: "1294730"
    name: "John Doe",
    email: "john.doe@email.com",
    address: "123 Main St",
    orders: [ { orderID: 1,
                product: "Laptop",
                price: 599.99,
                date: 12/24/20 },
              { orderID: 2,
                product: "Bed sheets",
                price: 35.99,
                date: 8/21/19 } 
            ]
}

Working with JavaScript, we can use an object as an example. This object will track information for a customer and its orders, so here we can have an idea of how the information can be accessed. First access the customer object, which in this case is one simple object, but realistically it will be an array of objects. Once there, we use the customer id to locate the record that we want. Then we can access its properties, such as email or address. We can also access a nested array of objects (or records in this case) such as orders. Doing this we can know all the orders placed by costumers.

This is very convenient and easier to work with by the fact that all the information related to an entity can be stored in one single record, unlike relational databases. But non-relational databases are not great at combining data from multiple entities in a single query, so we have to decide the best way to represent our data. Avoiding duplicated data will reduce the number of items to maintain.

In my JavaScript project for this semester, I am planning to create an e-Commerce, where I can implement a non-relational database using MongoDB to get started with back-end development.

Comparing Database Types to MongoDB

Dubymar Tollinchi — Wed, 13 Oct 2021 18:47:40 +0000

A library. We know this place has tons of books, novels, magazines, and other products in-store. If we think that this library is a database, we can think of their organization method (alphabetical, category, author, etc...) as a database type. Database types are patterns and structures used to organize data.

The beginnings of database types go back to the early-60s, and through the years these technologies experienced an amazing development. Some of these historic types have served as the base to advanced database technologies, however, new types have been developed to solve new issues and requirements in modern DBMS. In 1969, relational databases were introduced. This database type worked with tables, having primary keys and foreign keys that connect each table. Like this, tables can organize specific information and refer to other tables' information if needed.

To access and manipulate this DBMS, a querying language named SQL (Structured Query Language) was created. It connects tables through primary-foreign keys and allows to filter data using constraints. Like this, we can write complex queries that are very powerful and useful.

/* to retrieve all date in a table: */
SELECT * FROM TABLE_NAME;

/* we can filter the data using constraints (WHERE).
If we have a PERSON table with attributes such as Name and Age we can filter the results depending on conditions */
SELECT Name FROM PERSON 
WHERE Age > 18;

But as the years pass, newer and better technologies are being developed to facilitate developers' jobs. NoSQL databases are modern database types that manage data differently from the standard relational pattern. Although the name might sound like is the opposite of SQL, it stands for "Not-only SQL" or "Non-SQL", meaning that it may allow SQL-like querying.

Some of them are Key-value databases, which have a key and a value (self-explanatory, right?). They can store simple data such as a JSON object, an image, or plain text. We access the data using the key name.

Document databases follow the same semantic as key-value databases, but this time they don't have random pieces of data, instead, they store entire documents, often using formats like JSON or XML. Each document can have a different internal structure, and sometimes this type of database relates to both relational and key-value databases. MongoDB is an example of a document database.

How does MongoDB compare to the relational model? As we mentioned above, the relational model stores different data in separate tables. Having dozens and dozens of tables can result in a massive amount of complexity to our application. This includes:

Being hard for people to use and understand.
Difficult to add new features, having in mind all the tables related.
Retrieving data from many tables involves code statements that might slow down our application.

Unlike the relational model, MongoDB stores data using a document, and here we can think about a real piece of paper with specific data. Documents are a simple way to structure your data, being easier for computers (and humans) to process and understand.

// writing the same queries above, now using MongoDB
// .find() with a {} (empty document) inside , retrieves all the data within the collection
db.collection.find({});

// This query will retrieve all individuals over 18 years old
db.person.find({ age: {$gt: 18}});

This DBMS makes adding new data easy, not having to worry about breaking any other data. It also knows how to coordinate multiple servers to store data, so if one server fails we don't have to worry about our application being affected.

Introduction to Databases

Dubymar Tollinchi — Fri, 08 Oct 2021 15:48:25 +0000

Databases are logical structures that can store and organized any kind of data for future use. They are an indispensable component of a web application, thus they allow us to process, retrieve, or evaluate our data. They are managed by an application called DBMS (Database Management System), which organizes data according to specific patterns (database models). The relational model is perhaps considered to be the default paradigm, organizing data into cross-referenced tables, rows, and columns.

Databases have two ways to store data:

Data persistence: since the data is store on disk, even if the application or computer shuts down and restart, everything will continue there.
Ephemeral storage: the data is saved in-memory, but it is volatile, meaning that it does not survive a system shut down. Although the data might not be saved, in-memory databases are usually faster.

Now that we now how data is store, how can we interact with it? Databases provide an interface for users or applications, that allow us to access and interact with what's stored there. There are four types:

Data definition: allow us to create, modify, and remove definition's of the data structure.
Update: allow us to insert, modify, and delete data within the database.
Retrieval: allow us to access the stored data. It can be access as-is, or it can be filtered for a specific result.
Administration: these tasks are not directly related to our data, but it is important for user management, security, and performance monitoring.

Creating, modifying, or deleting data are potentially dangerous operations, often known as "write operations". On the other hand, retrieving data allow users to access that information for certain use, without modifying or interfering with the database itself.

In the case that we don't want to use a database, there are a few options that, in some way, are also consider a database:

Local memory or temporary filesystems
Serialize application data directly to the local filesystem
Storing file-like objects directly to disk

Database are used for many reasons, some of them are:

Storing and processing site data, which affects how information is organized on the site. If we have an e-Commerce, our database can store user information, product availability, and orders history.
Analyzing information to make better decisions, which relates to the basic functionality of the website. This operations, called analytics, provide answers to specific questions such as product trends, states where we ship the most, and factors that influence sales.

Understanding Node.js

Dubymar Tollinchi — Tue, 05 Oct 2021 04:25:04 +0000

When the majority of us started learning about web development, the first thing we came across was HTML. Then we learned about CSS to make our websites prettier and visually satisfying. When it was time to make our websites interactive and dynamic, we started diving into the amazing world of JavaScript. But back in the day, JS was used just to code the client-side, meaning that it could only be used in the browser. To interact with the server we needed to use other server-side languages such as Python, Ruby, or PHP. Until Node was born.

But, what is Node and how does it work? Node is a runtime environment that allows us to run JavaScript on a physical machine, rather than in the browser. At the same time, it is open-source, whereby millions of developers can create libraries and modules that can be downloaded for us to use.

Node uses V8, which is Google Chrome's JavaScript engine. Both the browser and Node use JavaScript as their programming language, but unlike the browser, with Node, we don't interact with the DOM. We have innumerable APIs that Node provides through their modules, which will allow us to program the server-side without learning any other language.

To get started with Node, we first have to download it to our computers from its website. Packages are available for all major platforms, and it's very easy to install. Select the correct operating system and once being installed, click next all the way through the end, and that's it!

npm

npm stands for Node Package Manager, and as it is self-explanatory, it manages all modules with the necessary dependencies for our project. Nowadays, there are more than 350,000 packages declared in Node.js.

To start using node, first, we go to our project and create a package.json (if it's not already part of the project). After that, we go to our terminal and type npm install or npm i, then Node goes to nmpjs.com and downloads all dependencies and creates a folder named node_modules where it's all stored. At the same time, it stores all names and versions of those dependencies in the package.json file.

This package.json can do many different things, unrelated to one another, and it has no requirements other than following the JSON (JavaScript Object Notation) format. Some basic declarations that we can make in our package.json file are:

{
  "name": "my-project",
  "version": "1.0.0",
  "description": "A JS project",
  "main": "src/main.js",
  "private": true,
}

Now let's take a look at something interesting:
In our package.json we specify the packages' version in our project, as well as the minimum being used and the new versions to be installed.

If we type ~0.1.0, it will update patch releases, like 0.1.1, but not 0.2.0.
If we type ^0.1.0, it will get updates that don't change the leftmost non-zero, like 0.1.1, 0.1.2, but not 0.2.1.
If we type 0.2.1, that is the exact version that we will always use.

In the case that we do not type the specific version that we will use, when someone on the other side of the world tries to download the project and run npm i, the latest versions will be downloaded, which will result in a project with different versions of dependencies. This was a very specific problem that package.json left unsolved, but now we have something called package-lock.json.

Package-lock.json stores the current versions that our project is using, and installs the right one from npmjs.com when running npm i. In case we want to update the dependencies' version, we run npm update and it will update them in the package-lock.json.

Async + Await

Dubymar Tollinchi — Mon, 04 Oct 2021 03:48:59 +0000

What is control flow?

It is the order in which statements, instructions, or functions are executed in our code. JavaScript is an asynchronous language, meaning that it reads code line by line, from top to bottom.

If there is a line that needs to fetch any information from a database, for example, it will kick off that data fetching and
continue reading the next lines immediately, instead of waiting for the fetching to be done.

JavaScript being asynchronous makes it difficult to write any code that will suddenly stop or block any application process. In the past some of the solutions for this issue were implementing callbacks, which is a function that gets passed as the last argument of another function.

This was fine until you encounter what developers call Callback Hell, which is a callback within a callback, within a callback, and so on, which makes it very difficult to read and maintain the code.

What is a promise?

A promise is the state of the result that gets return, so instead of having 10 lines of code indented with all those callbacks you can do it step by step. If something bad happens to the data, then you have an error handling, such as try catch. If you get the data successfully, then you execute a code, and like this, you write .then for each action that you want.

Async + Await is the same as promises but with a better syntax. Rather than having .then, we can put await in front of the promise and it will temporarily freeze that line of code until the promise is resolved or rejected, and then continues reading the following lines.

promises.all() are Mega promises, which are no other thing than a promise made of many promises, and it will return a promise where it will only resolve itself when all pieces of data are resolved.

Browser API's

Most new browser API's are build on native promises. Fetch is the way to get data from an API, so we can use await fetching data.

The fetch API is like a double promise, because you fetch some data from your API and then you need to convert that data (most of the time we want to convert it into JSON). Axios is also based on promises and they have some JSON defaults, so we don't need to convert the data.

JS's util package has a promisify function that converts callback-based functions to promise-based functions, so we can use our code on callback-based API's.

Since Async + Await is not built in every browser, something that we can do in order to make our code compatible with everything, is to go to Babel.com and convert the code.

Error handling

Error handling methods, such as try-catch, let you place the code that you want to execute in your program in the try part, and if anything happens, any errors can be handle in the catch part.

There is no way to abort or cancel a promise, when, for example, you have two fetch requests going at the same time. One thing that you can do is abortController(), which will cancel one or more web requests.