So far we have displayed film data stored in our JavaScript code. But real applications fetch data from servers over the internet. We can restate our problem as follows:

Given an API that serves film data
When the page first loads
Then the page should fetch and display the list of film data, including the film title, times and film certificate

💻 Client side and 🌐 Server side APIs

We will use fetch(), a client side Web API 🧶 🧶 client side Web API A client side Web API lives in the browser. They provide programmatic access to built-in browser functions from JavaScript. . Fetch will fetch our data from the server side API 🧶 🧶 server side API A server side API lives on a server. They provide programmatic access to data or functions stored on the server from JavaScript. .

APIs are useful because they let us get information which we don’t ourselves know. The information may change over time, and we don’t need to update our application. When we ask for the information, the API will tell us the latest version.

We also don’t need to know how the API works in order to use it. It may be written in a different programming language. It may talk to other APIs we don’t know about. All we need to know is how to talk to it. This is called the interface.

Using fetch is simple. But we want to understand what is happening more completely. So let’s take ourselves on a journey through time.

Instead of already having our data, we are now sending a request over the network to another computer, and then waiting for that computer to send us a response back. Now that our data is going on a journey over a network, we introduce the problem of latency.

Latency is the time taken for a request to traverse the network.

💡 Network latency is travel time.

Why is latency a problem? Because it means we need to wait for our data. But our program can only do one thing at a time - if we stopped our program to wait for data, then we wouldn’t be able to do anything else. We need to handle this time problem.

Programming often involves time problems, and latency is just one of them.

We can handle latency using asynchronous execution 🧶 🧶 asynchronous execution run code in a different order. To understand asynchrony we first need to be clear about synchronous execution 🧶 🧶 synchronous execution run code in the order it is written. .

We have written a lot of JavaScript programs that execute sequentially. This means that each line of code is run in order, one after the other.

console.log("first");
console.log("second");
console.log("third");

first
second
third

When we call a function, the function will run to completion before the next line of code is executed. But what if we need to wait for something to happen? What if we need to wait for our data to arrive before we can show it? In this case, we can use asynchronous execution.

Event Loop

We have already used asynchronous execution. We have defined eventListeners that listen for events to happen, then execute a callback function. But here’s a new idea: eventListeners are part of the Event API. They are not part of JavaScript! 🤯 This means you can’t use them in a Node REPL, but they are implemented in web browsers. The core of JavaScript is the same everywhere, but different contexts may add extra APIs.

When you set an eventListener you are really sending a call to a Web API and asking it do something for you.

const search = document.getElementById("search");
search.addEventListener("input", handleInput);

The callback handleInput cannot run until the user types. With fetch, the callback function cannot run until the data arrives. In both cases, we are waiting for something to happen before we can run our code.

We use a function as a way of wrapping up the code that needs to be run later on. This means we can tell the browser what to do when we’re done waiting.

👉🏽 Visualise the Event Loop

🧠 Recap our concept map

Consider this visualisation of an asynchronous program:

👉🏽 Code running out of order and off the thread

When we call setTimeout we send a function call to a client side Web API. The code isn’t executing in our single thread any more, so we can run the next line. The countdown is happening, but it’s not happening in our thread.

When the time runs out, our Web API sends a message to our program to let us know. This is called an event 🧶 🧶 event An event is a signal that something has happened. . Our API sends its message to our event loop 🧶 🧶 event loop The event loop is a JavaScript mechanism that handles asynchronous callbacks. . And what message does the event loop send? It sends a callback. It sends our call back. It tells our thread to run the code in that function.

setTimeout(function timeout() {
  console.log("1");
}, 2000);
setTimeout(function timeout() {
  console.log("2");
}, 500);
setTimeout(function timeout() {
  console.log("3");
}, 0);

So now we have these pieces of our giant concept map

1. 📤 we know that we can send a request using fetch()
2. 🐕 we know that fetch is a 💻 client side 🧰 Web API
3. 🗓️ we know that sending 📤 requests over a network takes time
4. 🧵 we know that we should not stop our program to wait for data
5. 🪃 we know that we can use callbacks to manage events

But we still don’t know how to use fetch to get data from a server side API. Let’s find this out now. In our filterFilms code, replace the films array with data fetched from a server.

// Begin with an empty state
const state = {
  films: [],
};
// Data
const endpoint = "//curriculum.codeyourfuture.io/dummy-apis/films.json";

const fetchFilms = async () => {
  const response = await fetch(endpoint);
  return await response.json();
}; // our async function returns a Promise

fetchFilms().then((films) => {
  render(filmContainer, films); // when
});

🐕 fetch returns a 🫱🏿‍🫲🏽 ‍Promise; the 🫱🏿‍🫲🏽 Promise fulfils itself with a 📥 response; the response contains our 💾 data.

We will dig into this syntax: Promises, async, await, and then in our next sprint and complete our concept map.