I've put together a comprehensive cheatsheet that goes through all of the core concepts in the Apollo library, showing you how to use it with React from front to back.

Want Your Own Copy?

You can grab the PDF cheatsheet right here (it takes 5 seconds).

Here are some quick wins from grabbing the downloadable version:

• ✓ Quick reference to review however and whenever
• ✓ Tons of useful code snippets based off of real-world projects
• ✓ Read this guide offline, wherever you like. On the train, at your desk, standing in line — anywhere.

Prefer Video Lessons?

A great deal of this cheatsheet is based off of the app built in the React + GraphQL 2020 Crash Course.

If you want some more hands-on video lessons, plus see how to build apps with React, GraphQL and Apollo, you can watch the course right here.

Note: This cheatsheet does assume familiarity with React and GraphQL. If you need a quick refresher on GraphQL and how to write it, a great resource is the official GraphQL website.

Table of Contents

Getting Started

• What is Apollo and why do we need it?
• Apollo Client setup
• Creating a new Apollo Client
• Providing the client to React components
• Using the client directly
• Writing GraphQL in .js files with gql

Core Apollo React Hooks

• useQuery Hook
• useLazyQuery Hook
• useMutation Hook
• useSubscription Hook

Essential Recipes

• Manually setting the fetch policy
• Updating the cache upon a mutation
• Refetching queries with useQuery
• Refetching queries with useMutation
• Accessing the client with useApolloClient

What is Apollo and why do we need it?

Apollo is a library that brings together two incredibly useful technologies used to build web and mobile apps: React and GraphQL.

React was made for creating great user experiences with JavaScript. GraphQL is a very straightforward and declarative new language to more easily and efficiently fetch and change data, whether it is from a database or even from static files.

Apollo is the glue that binds these two tools together. Plus it makes working with React and GraphQL a lot easier by giving us a lot of custom React hooks and features that enable us to both write GraphQL operations and execute them with JavaScript code.

We'll cover these features in-depth throughout the course of this guide.

Apollo Client basic setup

If you are starting a project with a React template like Create React App, you will need to install the following as your base dependencies to get up and running with Apollo Client:

// with npm:
npm i @apollo/react-hooks apollo-boost graphql

// with yarn:
yarn add @apollo/react-hooks apollo-boost graphql

@apollo/react-hooks gives us React hooks that make performing our operations and working with Apollo client better

apollo-boost helps us set up the client along with parse our GraphQL operations

graphql also takes care of parsing the GraphQL operations (along with gql)

Apollo Client + subscriptions setup

To use all manner of GraphQL operations (queries, mutations, and subscriptions), we need to install more specific dependencies as compared to just apollo-boost:

// with npm:
npm i @apollo/react-hooks apollo-client graphql graphql-tag apollo-cache-inmemory apollo-link-ws

// with yarn:
yarn add @apollo/react-hooks apollo-client graphql graphql-tag apollo-cache-inmemory apollo-link-ws

apollo-client gives us the client directly, instead of from apollo-boost

graphql-tag is integrated into apollo-boost, but not included in apollo-client

apollo-cache-inmemory is needed to setup our own cache (which apollo-boost, in comparison, does automatically)

apollo-link-ws is needed for communicating over websockets, which subscriptions require

Creating a new Apollo Client (basic setup)

The most straightforward setup for creating an Apollo client is by instantiating a new client and providing just the uri property, which will be your GraphQL endpoint:

import ApolloClient from "apollo-boost";

const client = new ApolloClient({
  uri: "https://your-graphql-endpoint.com/api/graphql",
});

apollo-boost was developed in order to make doing things like creating an Apollo Client as easy as possible. What it lacks for the time being, however, is support for GraphQL subscriptions over a websocket connection.

By default, it performs the operations over an http connection (as you can see through our provided uri above).

In short, use apollo-boost to create your client if you only need to execute queries and mutations in your app.

It setups an in-memory cache by default, which is helpful for storing our app data locally. We can read from and write to our cache to prevent having to execute our queries after our data is updated. We'll cover how to do that a bit later.

Creating a new Apollo Client (+ subscriptions setup)

Subscriptions are useful for more easily displaying the result of data changes (through mutations) in our app.

Generally speaking, we use subscriptions as an improved kind of query. Subscriptions use a websocket connection to 'subscribe' to updates and data, enabling new or updated data to be immediately displayed to our users without having to reexecute queries or update the cache.

import ApolloClient from "apollo-client";
import { WebSocketLink } from "apollo-link-ws";
import { InMemoryCache } from "apollo-cache-inmemory";

const client = new ApolloClient({
  link: new WebSocketLink({
    uri: "wss://your-graphql-endpoint.com/v1/graphql",
    options: {
      reconnect: true,
      connectionParams: {
        headers: {
          Authorization: "Bearer yourauthtoken",
        },
      },
    },
  }),
  cache: new InMemoryCache(),
});

Providing the client to React components

After creating a new client, passing it to all components is essential in order to be able to use it within our components to perform all of the available GraphQL operations.

The client is provided to the entire component tree using React Context, but instead of creating our own context, we import a special context provider from @apollo/react-hooks called ApolloProvider . We can see how it differs from the regular React Context due to it having a special prop, client, specifically made to accept the created client.

Note that all of this setup should be done in your index.js or App.js file (wherever your Routes declared) so that the Provider can be wrapped around all of your components.

import { ApolloProvider } from "@apollo/react-hooks";

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <ApolloProvider client={client}>
      <BrowserRouter>
        <Switch>
          <Route exact path="/" component={App} />
          <Route exact path="/new" component={NewPost} />
          <Route exact path="/edit/:id" component={EditPost} />
        </Switch>
      </BrowserRouter>
    </ApolloProvider>
  </React.StrictMode>,
  rootElement
);

Using the client directly

The Apollo client is most important part of the library due to the fact that it is responsible for executing all of the GraphQL operations that we want to perform with React.

We can use the created client directly to perform any operation we like. It has methods corresponding to queries (client.query()), mutations (client.mutate()), and subscriptions (client.subscribe()).

Each method accepts an object and it's own corresponding properties:

// executing queries
client
  .query({
    query: GET_POSTS,
    variables: { limit: 5 },
  })
  .then((response) => console.log(response.data))
  .catch((err) => console.error(err));

// executing mutations
client
  .mutate({
    mutation: CREATE_POST,
    variables: { title: "Hello", body: "World" },
  })
  .then((response) => console.log(response.data))
  .catch((err) => console.error(err));

// executing subscriptions
client
  .subscribe({
    subscription: GET_POST,
    variables: { id: "8883346c-6dc3-4753-95da-0cc0df750721" },
  })
  .then((response) => console.log(response.data))
  .catch((err) => console.error(err));

Using the client directly can be a bit tricky, however, since in making a request, it returns a promise. To resolve each promise, we either need .then() and .catch() callbacks as above or to await each promise within a function declared with the async keyword.

Writing GraphQL operations in .js files (gql)

Notice above that I didn't specify the contents of the variables GET_POSTS, CREATE_POST, and GET_POST.

They are the operations written in the GraphQL syntax which specify how to perform the query, mutation, and subscription respectively. They are what we would write in any GraphiQL console to get and change data.

The issue here, however, is that we can't write and execute GraphQL instructions in JavaScript (.js) files, like our React code has to live in.

To parse the GraphQL operations, we use a special function called a tagged template literal to allow us to express them as JavaScript strings. This function is named gql.

// if using apollo-boost
import { gql } from "apollo-boost";
// else, you can use a dedicated package graphql-tag
import gql from "graphql-tag";

// query
const GET_POSTS = gql`
  query GetPosts($limit: Int) {
    posts(limit: $limit) {
      id
      body
      title
      createdAt
    }
  }
`;

// mutation
const CREATE_POST = gql`
  mutation CreatePost($title: String!, $body: String!) {
    insert_posts(objects: { title: $title, body: $body }) {
      affected_rows
    }
  }
`;

// subscription
const GET_POST = gql`
  subscription GetPost($id: uuid!) {
    posts(where: { id: { _eq: $id } }) {
      id
      body
      title
      createdAt
    }
  }
`;

useQuery Hook

The useQuery hook is arguably the most convenient way of performing a GraphQL query, considering that it doesn't return a promise that needs to be resolved.

It is called at the top of any function component (as all hooks should be) and receives as a first required argument—a query parsed with gql.

It is best used when you have queries that should be executed immediately, when a component is rendered, such as a list of data which the user would want to see immediately when the page loads.

useQuery returns an object from which we can easily destructure the values that we need. Upon executing a query, there are three primary values will need to use within every component in which we fetch data. They are loading, error, and data.

const GET_POSTS = gql`
  query GetPosts($limit: Int) {
    posts(limit: $limit) {
      id
      body
      title
      createdAt
    }
  }
`;

function App() {
  const { loading, error, data } = useQuery(GET_POSTS, {
    variables: { limit: 5 },
  });

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;

  return data.posts.map((post) => <Post key={post.id} post={post} />);
}

Before we can display the data that we're fetching, we need to handle when we're loading (when loading is set to true) and we are attempting to fetch the data.

At that point, we display a div with the text 'Loading' or a loading spinner. We also need to handle the possibility that there is an error in fetching our query, such as if there's a network error or if we made a mistake in writing our query (syntax error).

Once we're done loading and there's no error, we can use our data in our component, usually to display to our users (as we are in the example above).

There are other values which we can destructure from the object that useQuery returns, but you'll need loading, error, and data in virtually every component where you execute useQuery. You can see a full list of all of the data we can get back from useQuery here.

useLazyQuery Hook

The useLazyQuery hook provides another way to perform a query, which is intended to be executed at some time after the component is rendered or in response to a given data change.

useLazyQuery is very useful for things that happen at any unknown point of time, such as in response to a user's search operation.

function Search() {
  const [query, setQuery] = React.useState("");
  const [searchPosts, { data }] = useLazyQuery(SEARCH_POSTS, {
    variables: { query: `%${query}%` },
  });
  const [results, setResults] = React.useState([]);

  React.useEffect(() => {
    if (!query) return;
    // function for executing query doesn't return a promise
    searchPosts();
    if (data) {
      setResults(data.posts);
    }
  }, [query, data, searchPosts]);

  if (called && loading) return <div>Loading...</div>;

  return results.map((result) => (
    <SearchResult key={result.id} result={result} />
  ));
}

useLazyQuery differs from useQuery, first of all, in what's returned from the hook. It returns an array which we can destructure, instead of an object.

Since we want to perform this query sometime after the component is mounted, the first element that we can destructure is a function which you can call to perform that query when you choose. This query function is named searchPosts in the example above.

The second destructured value in the array is an object, which we can use object destructuring on and from which we can get all of the same properties as we did from useQuery, such as loading, error, and data.

We also get an important property named called, which tells us if we've actually called this function to perform our query. In that case, if called is true and loading is true, we want to return "Loading..." instead of our actual data, because are waiting for the data to be returned. This is how useLazyQuery handles fetching data in a synchronous way without any promises.

Note that we again pass any required variables for the query operation as a property, variables, to the second argument. However, if we need, we can pass those variables on an object provided to the query function itself.

useMutation Hook

Now that we know how to execute lazy queries, we know exactly how to work with the useMutation hook.

Like the useLazyQuery hook, it returns an array which we can destructure into its two elements. In the first element, we get back a function, which in this case, we can call it to perform our mutation operation. For next element, we can again destructure an object which returns to us loading, error and data.

import { useMutation } from "@apollo/react-hooks";
import { gql } from "apollo-boost";

const CREATE_POST = gql`
  mutation CreatePost($title: String!, $body: String!) {
    insert_posts(objects: { body: $body, title: $title }) {
      affected_rows
    }
  }
`;

function NewPost() {
  const [title, setTitle] = React.useState("");
  const [body, setBody] = React.useState("");
  const [createPost, { loading, error }] = useMutation(CREATE_POST);

  function handleCreatePost(event) {
    event.preventDefault();
    // the mutate function also doesn't return a promise
    createPost({ variables: { title, body } });
  }

  return (
    <div>
      <h1>New Post</h2>
      <form onSubmit={handleCreatePost}>
        <input onChange={(event) => setTitle(event.target.value)} />
        <textarea onChange={(event) => setBody(event.target.value)} />
        <button disabled={loading} type="submit">
          Submit
        </button>
        {error && <p>{error.message}</p>}
      </form>
    </div>
  );
}

Unlike with queries, however, we don't use loading or error in order to conditionally render something. We generally use loading in such situations as when we're submitting a form to prevent it being submitted multiple times, to avoid executing the same mutation needlessly (as you can see in the example above).

We use error to display what goes wrong with our mutation to our users. If for example, some required values to our mutation are not provided, we can easily use that error data to conditionally render an error message within the page so the user can hopefully fix what's going wrong.

As compared to passing variables to the second argument of useMutation, we can access a couple of useful callbacks when certain things take place, such as when the mutation is completed and when there is an error. These callbacks are named onCompleted and onError.

The onCompleted callback gives us access to the returned mutation data and it's very helpful to do something when the mutation is done, such as going to a different page. The onError callback gives us the returned error when there is a problem with the mutation and gives us other patterns for handling our errors.

const [createPost, { loading, error }] = useMutation(CREATE_POST, {
  onCompleted: (data) => console.log("Data from mutation", data),
  onError: (error) => console.error("Error creating a post", error),
});

useSubscription Hook

The useSubscription hook works just like the useQuery hook.

useSubscription returns an object that we can destructure, that includes the same properties, loading, data, and error.

It executes our subscription immediately when the component is rendered. This means we need to handle loading and error states, and only afterwards display/use our data.

import { useSubscription } from "@apollo/react-hooks";
import gql from "graphql-tag";

const GET_POST = gql`
  subscription GetPost($id: uuid!) {
    posts(where: { id: { _eq: $id } }) {
      id
      body
      title
      createdAt
    }
  }
`;

// where id comes from route params -> /post/:id
function PostPage({ id }) {
  const { loading, error, data } = useSubscription(GET_POST, {
    variables: { id },
    // shouldResubscribe: true (default: false)
    // onSubscriptionData: data => console.log('new data', data)
    // fetchPolicy: 'network-only' (default: 'cache-first')
  });

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;

  const post = data.posts[0];

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
    </div>
  );
}

Just like useQuery, useLazyQuery and useMutation, useSubscription accepts variables as a property provided on the second argument.

It also accepts, however, some useful properties such as shouldResubscribe. This is a boolean value, which will allow our subscription to automatically resubscribe, when our props change. This is useful for when we're passing variables to our you subscription hub props that we know will change.

Additionally, we have a callback function called onSubscriptionData, which enables us to call a function whenever the subscription hook receives new data. Finally, we can set the fetchPolicy, which defaults to 'cache-first'.

Manually Setting the Fetch Policy

What can be very useful about Apollo is that it comes with its own cache, which it uses to manage the data that we query from our GraphQL endpoint.

Sometimes, however, we find that due to this cache, things aren't updated in the UI in the way that we want.

In many cases we don't, as in the example below, where we are editing a post on the edit page, and then after editing our post, we navigate to the home page to see it in a list of all posts, but we see the old data instead:

// route: /edit/:postId
function EditPost({ id }) {
  const { loading, data } = useQuery(GET_POST, { variables: { id } });
  const [title, setTitle] = React.useState(loading ? data?.posts[0].title : "");
  const [body, setBody] = React.useState(loading ? data?.posts[0].body : "");
  const [updatePost] = useMutation(UPDATE_POST, {
    // after updating the post, we go to the home page
    onCompleted: () => history.push("/"),
  });

  function handleUpdatePost(event) {
    event.preventDefault();
    updatePost({ variables: { title, body, id } });
  }

  return (
    <form onSubmit={handleUpdatePost}>
      <input
        onChange={(event) => setTitle(event.target.value)}
        defaultValue={title}
      />
      <input
        onChange={(event) => setBody(event.target.value)}
        defaultValue={body}
      />
      <button type="submit">Submit</button>
    </form>
  );
}

// route: / (homepage)
function App() {
  const { loading, error, data } = useQuery(GET_POSTS, {
    variables: { limit: 5 },
  });

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;

  // updated post not displayed, still see old data
  return data.posts.map((post) => <Post key={post.id} post={post} />);
}

This not only due to the Apollo cache, but also the instructions for what data the query should fetch. We can changed how the query is fetched by using the fetchPolicy property.

By default, the fetchPolicy is set to 'cache-first'. It's going to try to look at the cache to get our data instead of getting it from the network.

An easy way to fix this problem of not seeing new data is to change the fetch policy. However, this approach is not ideal from a performance standpoint, because it requires making an additional request (using the cache directly does not, because it is local data).

There are many different options for the fetch policy listed below:

{
  fetchPolicy: "cache-first"; // default
  /* 
    cache-and-network
    cache-first
    cache-only
    network-only
    no-cache
    standby
  */
}

I won't go into what each policy does exactly, but to solve our immediate problem, if you always want a query to get the latest data by requesting it from the network, we set fetchPolicy to 'network-first'.

const { loading, error, data } = useQuery(GET_POSTS, {
  variables: { limit: 5 },
  fetchPolicy: "network-first"
});

Updating the cache upon a mutation

Instead of bypassing the cache by changing the fetch policy of useQuery, let's attempt to fix this problem by manually updating the cache.

When performing a mutation with useMutation. We have access to another callback, known as update.

update gives us direct access to the cache as well as the data that is returned from a successful mutation. This enables us to read a given query from the cache, take that new data and write the new data to the query, which will then update what the user sees.

Working with the cache manually is a tricky process that a lot of people tend to avoid, but it's very helpful because it saves some time and resources by not having to perform the same request multiple times to update the cache manually.

function EditPost({ id }) {
  const [updatePost] = useMutation(UPDATE_POST, {
    update: (cache, data) => {
      const { posts } = cache.readQuery(GET_POSTS);
      const newPost = data.update_posts.returning;
      const updatedPosts = posts.map((post) =>
        post.id === id ? newPost : post
      );
      cache.writeQuery({ query: GET_POSTS, data: { posts: updatedPosts } });
    },
    onCompleted: () => history.push("/"),
  });

  // ...
}

We first want to read the query and get the previous data from it. Then we need to take the new data. In this case, to find the post with a given id and replace it with newPost data, otherwise have it be the previous data, and then write that data back to the same query, making sure that it has the same data structure as before.

After all this, whenever we edit a post and are navigated back to the home page, we should see that new post data.

Refetching queries with useQuery

Let's say we display a list of posts using a GET_POSTS query and are deleting one of them with a DELETE_POST mutation.

When a user deletes a post, what do we want to happen?

Naturally, we want it to be removed from the list, both the data and what is displayed to the users. When a mutation is performed, however, the query doesn't know that the data is changed.

There are a few ways of updating what we see, but one approach is to reexecute the query.

We can do so by grabbing the refetch function which we can destructure from the object returned by the useQuery hook and pass it down to the mutation to be executed when it is completed, using the onCompleted callback function:

function Posts() {
  const { loading, data, refetch } = useQuery(GET_POSTS);

  if (loading) return <div>Loading...</div>;

  return data.posts.map((post) => (
    <Post key={post.id} post={post} refetch={refetch} />
  ));
}

function Post({ post, refetch }) {
  const [deletePost] = useMutation(DELETE_POST, {
    onCompleted: () => refetch(),
  });

  function handleDeletePost(id) {
    if (window.confirm("Are you sure you want to delete this post?")) {
      deletePost({ variables: { id } });
    }
  }

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
      <button onClick={() => handleDeletePost(post.id)}>Delete</button>
    </div>
  );
}

Refetching Queries with useMutation

Note that we can also utilize the useMutation hook to reexecute our queries through an argument provided to the mutate function, called refetchQueries.

It accepts an array of queries that we want to refetch after a mutation is performed. Each queries is provided within an object, just like we would provide it to client.query(), and consists of a query property and a variables property.

Here is a minimal example to refetch our GET_POSTS query after a new post is created:

function NewPost() {
  const [createPost] = useMutation(CREATE_POST, {
    refetchQueries: [
      { 
        query: GET_POSTS, 
        variables: { limit: 5 } 
      }
    ],
  });

  // ...
}

Using the client with useApolloClient

We can get access to the client across our components with the help of a special hook called use Apollo client. This execute the hook at the top of our function component and we get back the client itself.

function Logout() {
  const client = useApolloClient();
  // client is the same as what we created with new ApolloClient()

  function handleLogout() {
    // handle logging out user, then clear stored data
    logoutUser();
    client.resetStore().then(() => console.log("logged out!"));
    /* Be aware that .resetStore() is async */
  }

  return <button onClick={handleLogout}>Logout</button>;
}

And from there we can execute all the same queries, mutations, and subscriptions.

Note that there are a ton more features that come with methods that come with the client. Using the client, we can also write and read data to and from the cache that Apollo sets up (using client.readData() and client.writeData()).

Working with the Apollo cache deserves its own crash course in itself. A great benefit of working with Apollo is that we can also use it as a state management system to replace solutions like Redux for our global state. If you want to learn more about using Apollo to manage global app state you can check out the following link.

I attempted to make this cheatsheet as comprehensive as possible, though it still leaves out many Apollo features that are worth investigating.

If you want to more about Apollo, be sure to check out the official Apollo documentation.

Download the cheatsheet

Want a quick reference of all of these concepts?

Click to grab the complete PDF cheatsheet

Become a Professional React Developer

React is hard. You shouldn't have to figure it out yourself.

I've put everything I know about React into a single course, to help you reach your goals in record time:

Introducing: The React Bootcamp

It’s the one course I wish I had when I started learning React.

Click below to try the React Bootcamp for yourself:

Click to get started

Within an afternoon, you will gain the core skills to build your own React and GraphQL projects.

Why you should learn React with GraphQL ?

React is the go-to library for building amazing app experiences with JavaScript. GraphQL, on the other hand, is a tool that gives us a better, more straightforward means of getting and changing our data.

That data could be from a standard database (as we'll be using in our app) or as React frameworks like Gatsby have made possible, even from static files such as markdown files. Regardless of how it's stored, GraphQL makes working with data in our apps better.

We'll see how to leverage the powers of React and GraphQL by creating a social blogging app from start to finish, where you can create, read, edit and delete posts.

You can click here to access the course.

What tools we'll be using ?️

The crash course is meant for developers who are somewhat familiar with React (including the core React Hooks, such as useState and useEffect), but aren't familiar with GraphQL yet.

Basic React knowledge is assumed, but GraphQL knowledge is not required. We'll cover all the core GraphQL concepts you need along the way.

Throughout the course, we'll utilize the following technologies to create our app:

• React (to build our user interface)
• GraphQL (to get and change data in a declarative way)
• Apollo Client (to allow us to use React and GraphQL together)
• Hasura (to create and manage our GraphQL API + database)

To top it off, we'll be using the online IDE CodeSandbox. This will allow us to code our entire application within the browser in realtime, without the need to create any files, folders, or install dependencies on our own.

Creating a GraphQL API from scratch

To get started working with GraphQL, we'll see how to make an entire GraphQL API from scratch that will communicate with our database.

Fortunately, using the (free) service Hasura, this process is very simple and straightforward. Within seconds, we'll see how to create and deploy a complete GraphQL API to the web, which is connected to a Postgres database that will take care of storing our app data.

Click to watch this lecture

Getting familiar with GraphQL

In the second lecture, we'll cover how to write in the GraphQL language using our API's built-in console called GraphiQL.

First, we will create a table in our database for all of our posts data. After which, Hasura will automatically create the queries and mutations we need, which are the names of GraphQL operations that allow us to get and change data in our database.

Throughout this lesson, we'll get very familiar performing queries and mutations in GraphiQL, which will enable us to get entire sets of posts and individual posts, as well as to create, update, and delete our individual post data.

Click to watch this lecture

Connecting React with our GraphQL API using Apollo Client

Now that we're comfortable with using GraphQL and understand its core features, we'll see how to connect it with our React client.

The way that we connect our React app with the GraphQL API we created is through a library called Apollo. We'll see how to set up the Apollo client, by providing the GraphQL endpoint, which points to our API, like so:

import ApolloClient from "apollo-boost";

const client = new ApolloClient({
  uri: "https://react-graphql.herokuapp.com/v1/graphql"
});

With our newly created client, we have the ability to execute any GraphQL operation through React. To do this, however, we need to pass our client to our entire to all of our React components. We do that with the help of the Apollo provider, as you see below:

Click to watch this lecture

Getting posts with useQuery

After setting up our client, we'll see how to execute different GraphQL operations with them, using some special React hooks that come with the package @apollo/react-hooks.

The hook that allows us to query for data with GraphQL is called useQuery. With it, we'll first see how to get and display all of our post data in our homepage.

Additionally, we'll learn how to write our GraphQL queries directly in our JavaScript files with the help of a special function called gql.

import React from "react";
import { useQuery } from "@apollo/react-hooks";
import { gql } from "apollo-boost";

export const GET_POSTS = gql`
  query getPosts {
    posts {
      id
      title
      body
      createdAt
    }
  }
`;

function App() {
  const { data, loading } = useQuery(GET_POSTS);

  if (loading) return <div>Loading...</div>;
  if (data.posts.length === 0) return <Empty />;

  return (
    <>
      <header className={classes.header}>
        <h2 className={classes.h2}>All Posts</h2>
        <Link to="/new" className={classes.newPost}>
          New Post
        </Link>
      </header>
      {data.posts.map(post => (
        <Post key={post.id} post={post} />
      ))}
    </>
  );
}

Creating and editing new posts with useMutation

After that, we'll see how to create new posts with the useMutation hook. In order to do this, we'll take a look at how to work with GraphQL variables to pass our mutation dynamic values that will change with each execution.

Following that we'll take a look at how to edit our posts. To do so, we'll need to fetch an individual post and display it within our form, so that our user can make changes to the data. Then we'll need to execute a mutation that will perform the update, based on the posts id.

Click to watch this lecture

Handle loading and errors

In the following lecture, we'll cover some essential patterns for handling the process of loading our data.

It's important to do so when we execute a mutation, to make sure we don't submit our forms multiple times as our mutation is being executed. We'll also take a look at how to handle errors in the event that our mutation is not executed correctly.

Click to watch this lecture

Deleting posts

Finally, we'll cover how to delete posts from our app. First, we'll confirm that the user wants to actually delete the post that they've made, then perform the mutation.

Additionally, we'll take a look at how to update our UI in response to mutations with the helpful refetch function that Apollo gives us. It will enable us to re-execute a query on demand. In this case, we'll do it after the delete mutation has been successfully performed.

Click to watch this lecture

Become a Professional React Developer

React is hard. You shouldn't have to figure it out yourself.

I've put everything I know about React into a single course, to help you reach your goals in record time:

Introducing: The React Bootcamp

It’s the one course I wish I had when I started learning React.

Click below to try the React Bootcamp for yourself:

Click to get started

While this picture shows an in-person classroom, we have moved our school fully remote as a result of the COVID-19 situation.

If you want to learn how to code, there are generally three options to choose from:

1. You can teach yourself and find your own curriculum.
2. Go to college and get a computer science/IT degree.
3. Or attend a coding school. Coding schools are hands-on crash courses that are designed to get you up to speed quickly so you can find your first software development job within three months to one year.

Option number one is the cheapest, but also the most frustrating and difficult. It's so easy to get stuck along the way and want to give up.

Options two and three could work out well, if you can afford to take time off work (or at least work fewer hours), pay the tuition plus living expenses while you are attending and looking for a job, and still be able to manage your family and personal life. Not everyone is able to do that.

This is why we created freeCodeSchool Indy. It's a free coding program based off of the freeCodeCamp curriculum where we guide students through part-time coding school programs for three months.

We have two two-hour classes per week - Monday and Wednesday from 6-8 pm, where we teach them everything from HTML basics to JavaScript and Intro to React.

The students are expected to spend at least 6 hours per week studying on their own, and can optionally attend office hours on Sundays that we hold from 1-5 pm. If they complete the first three months, then they are able to attend a second three month program, where they can learn about back-end web development in Node.js.

We started working on this idea over a year ago and it's exciting to be able to say that we completed our first cohort in May. Now we can share what we have learned in this article.

Our Goal in Building a Free Coding School

Our goal from the beginning was to provide accessible, supportive education for everyone regardless of income or life circumstances (like ability to take time off work).

We are not trying to compete with bootcamps or regular coding schools – they also provide a valuable service for students. We are just trying to have another, more accessible option for people who need a more flexible schedule or cannot afford a paid coding school.

Students will receive guidance and direction from the staff, volunteers, and members of the community throughout the program, and as alumni afterward.

Of course, we want our students to be able to get jobs in the industry if that is their goal. But we do not have the resources to guarantee anything. We just want to provide as much support as we can for the students whether they decide to keep learning on their own, or go to a more formal program, like a coding school or college.

Like I mentioned before, it took us about a year to get everything set up - between finding the space and instructors, as well as deciding on the type of program and curriculum. Here is everything that went into our program preparation.

How We Planned the Program

The first things we did were choose the length of time and goals for the program. We landed on having three-month-long classes where the students would learn the basics of HTML, CSS, and JS, with some extras like Bootstrap and React Components.

If everything went well, our goal was to take a month off and host a level two course for the students who completed the first one. Level two would be another three months where we would build off of what we taught in level one and teach more about JavaScript frameworks and introduce Node.js.

Starting small with just a three month part-time program helped us to be able to learn and make adjustments as we went along. It also gave the students a short, time-based goal to be able to complete the program and have a small portfolio in just a few months.

Here is our organization on Github. We are in the process of updating and open-sourcing our material as we go along.

Adopting freeCodeCamp's Curriculum

Curriculum development is time consuming and expensive. Fortunately, freeCodeCamp already has an awesome free curriculum that we can use and modify with no strings attached.

We took freeCodeCamp's curriculum and followed it as an outline for our lectures. We used the challenges as assignments for students to complete between classes. We also used freeCodeCamp's projects as individual and group assignments along the way.

Throughout the lessons, we also encouraged students to try to do a little bit of extra work to be able to get their freeCodeCamp certifications during, or after the end of, the program.

How We Found a Space to Host Classes

The Indianapolis Public Library generously agreed to host our classes and give us space for office hours as well. The size of the space in the computer lab was limited, so the maximum number of students we could take per class was 22.

We could have used a larger conference room in the library to accommodate a larger class, but then we wouldn't have been able to take students who didn't own a laptop – and that wouldn't have been very accessible for everyone.

We didn't plan to be a remote program, so we had to adjust our classes to use Discord for lectures and all student communication when COVID-19 happened. More on that later.

How we Chose Technology Tools

We prepared a Discourse forum (like the freeCodeCamp forum) before the classes started so students could log in, get announcements, ask questions, and post assignments. It also gave the admin staff some privileges to keep track of students and moderate student interactions.

How we Administered the School

Finding Students

When we were planning this program, our worry was that we would not get enough interest and all our planning would be for nothing. The reality was that we had way too much interest and could not accommodate every student. For 22 slots, we had over 140 people who wanted to participate! And that was without doing that much marketing.

It was very exciting to get so much interest in our program, but we also had to decide which students to take and how to choose in a fair way.

We decided to whittle down the field by requiring people to show up for three pre-screening activities where they would complete some basic challenges, like Code.org's Flappy Game. This let us know which students were dedicated to showing up and got the number of people in line down to around 80. That was still too way too many for the space we had so had to do a random lottery to select the final students.

Teaching Students

Every student learns differently and has their own personality and preferences. It's unreasonable to expect that we can just lecture the students for an hour and they will all be able to pick up all that information and build the lab without issue.

We decided on a format for lectures where we start off every lecture by asking if anyone has questions – usually we don't get many. Then, we go into the slides, and pause every ~15 minutes to give the students guided 'labs' so they can try out coding on their own with the support of having instructions and still being able to ask questions in the classroom.

We also often leave the last 30+ minutes of the 2-hours classes for the students to be able to work on their class projects.

Collecting Assignments

Some people don't turn in assignments. This could mean they are shy about sharing their code where other students can see, or that they just don't think it's necessary since it's a free coding school after all, and some of their classmates aren't doing it either.

If it's the former, then we encourage them to share assignments with just the staff and let them know that we have all been in their shoes before.

If they aren't turning in assignments because they don't want to... well, there isn't much we can do about that. We try to discourage students from joining the class who don't want to fully participate in the program.

The assignments were originally being turning in on the forum, but we were getting really low engagement on there. Students weren't logging in very often and they were never asking questions there.

Now assignments are turned in via a Discord channel on the server we have for our coding school.

Since we manage our whole program from the same Discord server – including hosting lectures, answering questions, and managing the program – we are seeing an increase in the number of assignments turned in. We are also getting more useful feedback that students are getting from staff and volunteers.

Deadlines

Should we have deadlines for turning in projects? Our opinion right now is no, we shouldn't.

Most of the first cohort got a bit behind and some of them finished the program weeks after the end. Should we punish people who finish, but just not on time? We don't think so and here is why: Everyone learns at their own pace.

If someone finishes in 3 months and another student in 4 months, then they both should be rewarded the same for completing the program.

Someday, we will be able to have rolling admissions for our coding and help students at a more granular level. Until then, the least we can do is stay flexible to accommodate them and let them turn in the rest of the projects whenever they can.

Getting Students to Ask for Help

This has been one of our biggest problems! Some people fall behind and some students are confused but don't want to ask for help. Some students are so confused that they don't even know what kind of help to ask for.

You can't really force people to get help, but you can prompt them. The best way we have found to get them to ask questions is to do short review segments at the beginning of lectures and have scheduled study times where students can pop in and ask questions in a much smaller group setting.

If they prefer to type out the question, they can post it in the student chat or send a private message to one of the organizers.

We can only do so much. If students are lost or confused and don't want to ask for help, there is no way for us to fix that. We try hard to meet them where they are, but they also have to make some effort to come to us.

Student Surveys

Performing regular student surveys is really helping us to get critical feedback for our program.

Our first time through, we collected information about student goals and background at the beginning, then took a student survey at the half-way point - around 6 weeks in – and then another survey at the end.

While we received a lot of good information, in hindsight, we should have taken more surveys and added a few more questions. This time, we will probably perform surveys to get student feedback every month. Here are some of the questions we are asking:

1. What do you think about the program so far? Is it meeting your expectations?
2. Do you feel like the lectures are helpful for doing the assignments?
3. How can we better help you achieve your goals?
4. Do you have any other feedback for us?

Dealing with Drop Outs

Life happens, things change. We have to understand that students who fully intend to participate might have to drop out due to unavoidable circumstances.

If they communicate with us about the situation, we offer them a spot in the next cohort.

If they simply do not show up or communicate with us, then they are free to reapply in the future, but no spot will be saved for them.

Staff and Volunteers

Soliciting Volunteers

Without volunteers, it would be quite overwhelming to run a program like this. Here are some of the different types of volunteers you will need to be successful.

Responsibilities:

1. Organizers – Yes, we are volunteers too. We are fortunate to have an amazing team of organizers who run the program. This includes myself, two other developers, and a computer lab supervisor from the library who also knows how to code. We chat several times per week in Discord to make sure the program is running smoothly and students are progressing. I think 3-5 is a pretty good number for an organizing team, but we might add more to do specific things, such as 'community manager' or 'volunteer coordinator.'
2. Presenters – These people give lectures during class times or special help sessions held on weekends usually. This is the hardest type of volunteering to manage. In our program, the lectures are 1.5-2 hours long and there are only 24 of them, so every single one has to be on point and flow with the rest of the curriculum. Some well-meaning volunteers might not be the right fit for giving lectures for people who are brand new to development. It is very important to be clear about what you want them to cover in the lecture, down to the individual points and expected learning outcomes. We also made sure to give volunteers a boilerplate slide deck to work off of so it matched the rest of the curriculum.
3. Mentors – Students will not only have coding questions, but also have questions about their careers, networking, etc. Mentorship is great for answering these types of questions. We are currently working on setting up our mentorship program where volunteer mentors will check in with students at least once per week to make sure they are on track and answer any questions they have. One of the reasons for the delay is we have been working on a system for how to handle any complaints of inappropriate language or behavior that might take place when students meet one on one with volunteers.
4. Lab Assistants – Lab assistants are there to help out synchronously during live lab sessions, usually with problems running software or debugging. We utilized lab assistants much more when we held in-person classes. With things being remote, we can't see the students' screens so we have had to just have a few people available to answer questions in the chat if people get stuck.
5. General Helpers – These people help answer students' questions in the chat and perform other tasks like reviewing projects and portfolios. They are also useful for students to rubber duck off of or for encouragement.

Volunteer Handbook

We made a two-page handbook detailing expectations for volunteer behavior as well as requirements for participation in our program. It's pretty basic right now, but we will be building off of it as we go along I'm sure.

We also give them a link to the freeCodeCamp code of conduct because it's short, sweet, and to the point: be kind, understanding, etc.

Making Sure Staff has the Tools to Succeed

We have definitely made a few mistakes, including letting a presenter make his own slides and then having to tell him at the last minute that they needed to change. It didn't go over well. We should have been much clearer with what we wanted from him.

Now, everyone receives a boilerplate slide deck from us as well as a list of topics to cover. We also connect with them several times to go over the progress in their presentation to make sure it's on the right track.

Right now, we have a volunteer handbook, lesson plans and slide decks for teaching, guidelines for mentoring, and google drive folder where we keep all of the documentation for the program, student progress, curriculum materials, and future plans. We recently re-organized all of these materials to make them easier to locate when we need them.

As this program grows, we are going to need to manage more volunteers and even paid staff. We are preparing for this by documenting our processes to make onboarding a little bit smoother each time.

Community Partners

We are currently trying to form community partnerships to get sponsors for funding as well as donations of tech equipment.

Some of our students don't have access to good computers or a fast internet connection. The library provided those things for us when we hosted in person classes, but it's been more difficult now that we are remote.

Also, libraries only have limited hours, and, for students who work multiple jobs or have other family obligations, it can be difficult to make the time to do all of the class work during the day. This is why the sponsorship of community partners is so important to making our program accessible.

In the future, we hope to be able to provide internet access and laptop computers for students who need them.

Organizing

Marketing

We don't have any marketing experts on our team. Our marketing efforts basically consist of making sure we keep our branding that we agreed upon - colors, verbiage, etc. - consistent and collectively sharing updates on social media.

Fortunately, I have a small following on YouTube, LinkedIn, and other platforms where I have been able to solicit volunteers and get some community interest in our program.

The public library has also been helpful with reaching out to many different communities and pulling in students that we might never have been able to reach otherwise.

As we grow, we might start expanding our social media reach, but with a limited budget right now, we are just gaining traction organically.

Remote Livestreams

Discord screen sharing interface.

Hosting remote livestreams has been challenging. Internet connections sometimes drop, plus there is a learning curve for students to be able to use the software.

Discord has been a great option for us, because we can host livestreams inside of the app where all of our chats and everything else are located. This way, we only have to explain how to use one piece of software.

In addition, Discord allows us to screen share with up to 50 people at a time in the voice chat rooms. And that's all for free! We looked into Zoom and some other tools, but we are going to stick with Discord until we need - and can afford - something with more features.

Incorporating & Funding

We wanted to start asking companies and people for funding so we had to incorporate as a non-profit last year. In the US, this process takes about six months. We first had to register as a company with our state and then draw up business documents and apply for non-profit status with the federal government.

At the beginning of this year, we finally got confirmation that we are a 501c3 non-profit organization! Now we are trying to work out ways of getting funding and taking donations. We're going to add a 'donate' button to our website and we are also reaching out to companies to solicit larger donations. There have also been some internal discussions about whether or not crowdfunding is a good idea.

Do you have any suggestions for us in this area? Please leave a comment on this article or reach out to us at contact@freecodeschoolindy.com.

Communication Tools

Forum

As previously mentioned, we started off using a Discourse forum, but found that it was hard to maintain and wasn't meeting our needs. People found it hard to use, especially on mobile. We also had trouble getting staff and students to login and check it often enough to make it worth the effort. That is why we got rid of the forum and moved our whole program over to Discord.

Discord

We now have a Discord server set up for the whole coding school! We use it to host live lectures - we can have up to 50 people in the voice chat and screen share with them at the same time, manage students, organize volunteer activities, coach speakers, answer questions, do group projects, review portfolios, and perform administrative tasks.

Having everything in one place has been the best decision we have ever made. Not only are our costs lower, but it makes the program administration so much easier. Everyone we need to interact with is either already on Discord, or just needs to be invited to Discord :)

Graduation

We had grand plans of doing our first in-person graduation for students this year. Unfortunately, due to COVID-19, those plans had to be scrapped. We had to make do with mailing out certificates to students who completed the program and giving everyone a (virtual) pat on the back for finishing.

Now that our classes are virtual, we would love to be able to do something fun for the graduation of our second cohort at the end of August. Do you have any ideas? Let us know if you do.

Conclusion

Putting this program together might have been the hardest thing I've ever done. It's a lot of work but very rewarding. It can be life-changing for students.

It wasn't just me though: There was a team of people helping out and none of this would have happened without them.

I want to give special thanks to Jared Wilcurt, Casssandra Bautista, Marianne Mckenzie, The Indianapolis Public Library, freeCodeCamp, and all of our wonderful volunteers – all of whom were crucial in putting this program together.

We are working on open-sourcing our curriculum we used – slides, projects, freeCodeCamp challenges, supplementary material, and so on. It's taking a little bit of time to put everything together in a nice format, but be patient, we will get it out to anyone who is interested soon :)

I'm interested in your thoughts. Do you have any ideas for things we can do better next time around? Please reach out to me and let me know.

My Twitter: @gwen_faraday

My YouTube: Faraday Academy

Program Website: freecodeschoolindy.com

I am a JavaScript/Node developer who secretly likes (actually, loves and adores) Deno. I have been a huge fan of Deno ever since it was announced and I've been wanting to play with it.

This tutorial focuses on creating a set of REST APIs for a Todo application. Keep in mind that I did not touch on the database here – I will cover that in another article.

At any point if you feel lost or want to check a reference, here is the entire source code of this tutorial: Chapter 1: Oak.

_Photo by [Unsplash](https://unsplash.com/@bernardtheclerk?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Bernard de Clerk / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Things we will cover

• Create a basic server
• Create 5 APIs (routes/controller)
• Create a middleware to log API requests as they are made in the console
• Create a not found (404) middleware when the user tries to access an unknown API

What will we need

• An installed version of Deno (don't worry I'll walk you through it)
• A tiny bit of knowledge of Typescript
• Would be awesome if you have worked with Node/Express before (don't worry if you haven't — this tutorial is very basic)

Let's get started

First things first let's install Deno. I am on a Mac computer so I am using brew. Simply open your terminal and type:

$ brew install deno

But if you are using a different operating system, just head over to deno.land installation. They have a lot of ways you can easily install it on your machine.

Once you have it installed, close the terminal, open a new one, and type:

$ deno --version

It should output something like this:

running command "deno --version" to see which version of deno is installed

Awesome! With this we are almost done with 10% of this tutorial.

Let's move ahead and create the backend API for our Todo app.

Setting up the project

Before you move on, here is the entire source code of this tutorial: Chapter 1: Oak.

Let's get started:

• Create a new folder and call it chapter_1:oak (but you can call it anything you want)
• Once you create a folder simply cd into your new project. Create a file called server.ts and write the following code in it:

import { Application } from "https://deno.land/x/oak/mod.ts";

const app = new Application();
const port: number = 8080;

console.log('running on port ', port);
await app.listen({ port });

Let's run this file. Open your terminal and in your project root folder type:

$ deno run --allow-net server.ts

I will talk about what the --allow-net flag does, but for now just bear with me ?.

You should get something like this:

What we have done so far is create a server which listens on port 8080. It doesn't do much right now besides being able to run on port 8080.

If you have used JavaScript before, one thing you might have noticed is we are importing packages in a different way. We have to do something like:

import { Application } from "https://deno.land/x/oak/mod.ts";

When you run deno run ---allow-net <file_name> in your terminal, Deno will look at all your imports and install them locally in your machine if they are not there.

The first time you run this it will go to this URL https://deno.land/x/oak/mod.ts and install the oak package. Oak is basically a Deno framework for writing API's. It will put it somewhere locally in your cache.

In the next line we do this:

const app = new Application();

This creates a new instance of our application, and it will be the basis of everything as you progress further in this tutorial. You can add routes to the application instance, attach middleware like API logging, write a 404 not found, and so on.

Then we write:

const port: number = 8080;
// const port = 8080; // => can also be written like this

Both are the same and do the same thing. The only difference is writing const port: number = 8080 tells Typescript that port variable is of type number.

If you were to write const port: number = "8080", this would throw an error in your terminal, as port is of type number. But we are trying to assign it a string of value "8080".

If you want to learn more about different types of types (pun intended) check out this very easy and basic guide on Basic types by Typescript. Just give it a quick glance for 2-3 minutes and head back here.

And in the end we have:

console.log('running on port ', port);
await app.listen({ port });

We simply console here the port number and tell Deno to listen to the port, which is 8080.

It isn't doing much right now. Let's make it do something basic like show a JSON message in your browser when you go to http:localhost:8080.

Add the following to your server.ts file:

import { Application, Router } from "https://deno.land/x/oak/mod.ts";

const app = new Application();
const port: number = 8080;

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

console.log('running on port ', port);
await app.listen({ port });

The new thing added here is that we are now also importing Router along with Application from oak in line 1.

Next what we do is:

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

We create a new router instance by doing const router = new Router() and then we create a new route called / which is of type get.

Let's break this down:

router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});

router.get takes 2 parameters. The first is route which we have set to / and the second is function. The function itself takes an argument which is an object. What I am doing here is destructuring the object and getting only response.

Next I am type checking response similar to how I did const port: number = 8080;. All I am doing is { response }: { response: any } which is telling TypeScript here that the response which I have destructed can be of type any.

any helps you avoid type checking in TypeScript. You can read more about it here.

Then all I am doing is taking that response object and setting response.body.message = "hello world";.

response.body = {
  message: "hello world",
};

Last but not least, we just add these two lines:

app.use(router.routes());
app.use(router.allowedMethods());

This tells Deno to include all routes by our router (currently we only have one) and the next line tells Deno to allow all methods for this route(s) like GET, POST, PUT, DELETE.

And now we are done. ✅ Let's run this and see what we have:

$ deno run --allow-net server.ts

The ---allow-net property tells Deno that this app gives the user the permission to access its content via the port opened up.

Now open your favorite browser and go to http://localhost:8080. You will see something like this:

Result of running localhost:8080 on your browser

Honestly the hardest part is done. Conceptually we are 60% there.

Master Yoda approves

Awesome.

Just one last thing before we start with our Todo API. Let's replace:

console.log('running on port ', port);
await app.listen({ port });

with:

app.addEventListener("listen", ({ secure, hostname, port }) => {
  const protocol = secure ? "https://" : "http://";
  const url = `${protocol}${hostname ?? "localhost"}:${port}`;
  console.log(`Listening on: ${port}`);
});

await app.listen({ port });

The code we had before was not very accurate, because we were simply console logging a message and then waiting for the app to start listening on a port.

With the later version we wait for the app to start listening on port and we can listen by adding an event listener to our app instance with the following: app_.addEventListener_("listen", ({ secure, hostname, port }) => {}.

The first param is the event we want to listen for (which is listen ?) and then the second param is an object which we destruct to { secure, hostname, port }. Secure is a boolean, hostname is a string, and port is a number.

Now when we start our app, it will only console the message once the app actually starts listening on port.

We can just go one step ahead and make it more colorful. Let's add a new module to the top of the file in server.ts:

import { green, yellow } from "https://deno.land/std@0.53.0/fmt/colors.ts";

And then inside our event listener method we can replace:

console.log(`Listening on: ${port}`);

with:

console.log(`${yellow("Listening on:")} ${green(url)}`);

Now when we do:

$ deno run --allow-net server.ts

it will show this in our console:

Cool, now we have a colourful console.

If you get stuck anywhere you can simply go to the source code of this tutorial here.

Let's create our Todo API's routes next.

• Create a new folder in your root folder called routes and inside that folder create a file called todo.ts
• At the same time in your root folder create a new folder called controllers and inside that folder create a file called todo.ts

Let's first touch the controllers/todo.ts file:

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

We are simply exporting an object here with some named functions which are empty (for now).

Next go inside your file routes/todo.ts and type this:

import { Router } from "https://deno.land/x/oak/mod.ts";

const router = new Router();
// controller
import todoController from "../controllers/todo.ts";

router
  .get("/todos", todoController.getAllTodos)
  .post("/todos", todoController.createTodo)
  .get("/todos/:id", todoController.getTodoById)
  .put("/todos/:id", todoController.updateTodoById)
  .delete("/todos/:id", todoController.deleteTodoById);

export default router;

This might look familiar to people who have worked with Node and Express.

All we are doing here is importing Route from oak and then setting up a new instance of Router by doing const router = new Router();.

Next we import our controllers by doing:

import todoController from "../controllers/todo.ts";

One thing to notice here in Deno is every time we import a local file in our Deno project we have to provide the file extension. This is because Deno doesn't know whether the file being imported is a .js or .ts file.

Moving forward we simply set all of our routes according to REST conventions:

router
  .get("/todos", todoController.getAllTodos)
  .post("/todos", todoController.createTodo)
  .get("/todos/:id", todoController.getTodoById)
  .put("/todos/:id", todoController.updateTodoById)
  .delete("/todos/:id", todoController.deleteTodoById);

The code above will translate to our API definition like this:

and at the end we simply export our router by doing _export_ _default_ router;.

We are done with creating our routes structure. (Now, each route doesn't do anything because our controllers are empty, we will add functionality to them in a bit.)

Here's the last piece of the puzzle before we start adding functionality to each route controller. We need to attach this router to our app instance.

So head over to server.ts file and do the following:

• Add this to the very top:

// routes
import todoRouter from "./routes/todo.ts";

• Remove this piece of code:

const router = new Router();
router.get("/", ({ response }: { response: any }) => {
  response.body = {
    message: "hello world",
  };
});
app.use(router.routes());
app.use(router.allowedMethods());

• Replace it with:

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

This is it – we are done. Your server.ts file should look like this now:

import { Application } from "https://deno.land/x/oak/mod.ts";
import { green, yellow } from "https://deno.land/std@0.53.0/fmt/colors.ts";

// routes
import todoRouter from "./routes/todo.ts";

const app = new Application();
const port: number = 8080;

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

app.addEventListener("listen", ({ secure, hostname, port }) => {
  const protocol = secure ? "https://" : "http://";
  const url = `${protocol}${hostname ?? "localhost"}:${port}`;
  console.log(
    `${yellow("Listening on:")} ${green(url)}`,
  );
});

await app.listen({ port });

If you got stuck anywhere while following this, simple head over to the source code of this tutorial here.

Awesome, now we have our routes with no functionality at the moment. So let's add that functionality in our controllers.

But before we do that we have to create 2 more (tiny) files.

• In your root folder create a new folder called interfaces and inside that folder create a file called Todo.ts (make sure Todo is capitalized, as it won't give any syntax error here if you don't – these are just conventions.)
• Also in your root folder create a new folder called stubs and inside that folder create a file called todos.ts

Let's create an interface in our interfaces/Todo.ts file. Simply add the following code:

export default interface Todo {
  id: string,
  todo: string,
  isCompleted: boolean,
}

What is an interface?

One of the core things in TypeScript is checking the shape that value has. Similar to const port: number = 8080 or { response }: { response : any }, we can also type check an object.

In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.

Here is an another example of an interface:

// We have an interface
interface LabeledValue {
  label: string;
}

// the arg passed to this function labeledObj is 
// of type LabeledValue (interface)
function printLabel(labeledObj: LabeledValue) {
  console.log(labeledObj.label);
}

let myObj = {label: "Size 10 Object"};
printLabel(myObj);

Hopefully this example gives you a bit more insight into interfaces. If you want more detailed information check out the docs on interfaces here.

Now that our interface is ready, let's mock some data (since we don't have an actual database for this tutorial).

Let's create a mock list of todos first in our stubs/todos.ts file. Simply add the following:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interface
import Todo from '../interfaces/Todo.ts';

let todos: Todo[] = [
  {
    id: v4.generate(),
    todo: 'walk dog',
    isCompleted: true,
  },
  {
    id: v4.generate(),
    todo: 'eat food',
    isCompleted: false,
  },
];

export default todos;

• Two things to notice here: we add a new package and use its method v4 by doing _import_ { v4 } _from_ "https://deno.land/std/uuid/mod.ts";. Then every time we use v4.generate() it will create a new random string of id.

The id can not be a number, only a string because in our Todo interface we have defined id as a string.

• The other thing to focus on here is let _todos_: _Todo_[] = []. This basically tells Deno that our todos array is of type Todo (which is awesome, our compiler now automagically knows that each item in our array can only have {**id**: _string_, **todo**: _string_ & **isCompleted**: _boolean_} it will not accept any other key).

If you want to learn more about interfaces in TypeScript check out this amazing detailed documentation on interfaces here.

Awesome. If you have come this far, give yourself a pat on the back. Good job everyone.

The Rock appreciates all the effort you are doing

Let's work on our controllers

In your file controllers/todo.ts:

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Let's write the controller for getAllTodos:

// stubs
import todos from "../stubs/todos.ts";

export default {
  /**
   * @description Get all todos
   * @route GET /todos
   */
  getAllTodos: ({ response }: { response: any }) => {
    response.status = 200;
    response.body = {
      success: true,
      data: todos,
    };
  },
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Before I begin on this block of code, let me explain that every controller has an argument – let's call it context.

So we can deconstruct _getAllTodos_: (context) => {} to:

getAllTodos: ({ request, response, params }) => {}

And since we are using typescript we have to add type checking to all of these variables:

getAllTodos: (
  { request, response, params }: { 
    request: any, 
    response: any, 
    params: { id: string },
  },
) => {}

So we have added type checks to all 3 { request, response, params }

• request is what the user sends us (information like headers and JSON data)
• response is what we send the user back in the API response
• params is what we define in our router routes, that is:

.get("/todos/:id", ({ params}: { params: { id: string } }) => {})

So the :id in /todos/:id is the param. Params are a way to get information from the URL. In this example we know that we have an /:id . So when the user tries to access this API (that is, /todos/756) 756 is basically the :id param. Since it is in the URL we know it is of type string.

Now that we have our basic definitions defined let's get back to our todos controller:

// stubs
import todos from "../stubs/todos.ts";

export default {
  /**
   * @description Get all todos
   * @route GET /todos
   */
  getAllTodos: ({ response }: { response: any }) => {
    response.status = 200;
    response.body = {
      success: true,
      data: todos,
    };
  },
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

For getAllTodos we only need response . If you remember, response is what is needed to send data back to the user.

For people coming from a Node and Express background, one big thing that is different here is that we don't need to return the response object. Deno does this for us automatically.

All we have to do is set response.status which in this case is 200.

More on response statuses here.

The other thing we set is the response.body which in this case is an object:

{
  success: true,
  data: todos
}

I will go ahead and run my server:

$ deno run --allow-net server.ts

Revision: The ---allow-net property tells Deno that this app gives the user permission to access its content via the port opened up.

Once your server is running, you can access the GET /todos API. I am using postman which is a Google Chrome extension and can be downloaded here.

You can use whatever rest client you like. I like using postman because I think it is very easy.

In Postman, open up a new tab. Set the request to type GET and in the URL bar type http://localhost:8080/todos. Hit Send and this is what you see:

GET /todos API response

Cool! 1 API done, 4 more to go. ??

If you feel stuck anywhere just have sneak peak at the source code directly here.

Let's move on to our next controller:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  /**
   * @description Add a new todo
   * @route POST /todos
   */
  createTodo: async (
    { request, response }: { request: any; response: any },
  ) => {
    const body = await request.body();
    if (!request.hasBody) {
      response.status = 400;
      response.body = {
        success: false,
        message: "No data provided",
      };
      return;
    }

    // if everything is fine then perform
    // operation and return todos with the
    // new data added.
    let newTodo: Todo = {
      id: v4.generate(),
      todo: body.value.todo,
      isCompleted: false,
    };
    let data = [...todos, newTodo];
    response.body = {
      success: true,
      data,
    };
  },
  getTodoById: () => {},
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Since we are going to be adding a new Todo to our list, I have imported 2 modules in the controller file.

• import { v4 } fromhttps://deno.land/std/uuid/mod.ts; this will be used to create a new unique one for the todo being created
• import Todo from "../interfaces/Todo.ts"; this will be used to ensure that the new todo that is being created follows the same structure.

Our createTodo controller is async meaning there are some promises used inside the controller.

Let's break it into smaller parts:

const body = await request.body();
if (!request.hasBody) {
      response.status = 400;
      response.body = {
        success: false,
        message: "No data provided",
      };
      return;
}

First we get the content of the JSON body that the user has sent us. Then we use oak's built-in method called request.hasBody to check if the user has even sent any content. If not then we can do if (!request_._hasBody) {} inside this if block.

We set the status to 400 (400 means that the user did something they were not suppose to do) and the body is set to {success: false, message: "no data provided }. Then we simple add return; to ensure that no further code below is executed.

Next we do this:

// if everything is fine then perform
// operation and return todos with the
// new data added.
let newTodo: Todo = {
  id: v4.generate(),
  todo: body.value.todo,
  isCompleted: false,
};
let data = [...todos, newTodo];
response.body = {
  success: true,
  data,
};

We create a new todo by doing this:

let newTodo: Todo = {
  id: v4.generate(),
  todo: body.value.todo,
  isCompleted: false,
};

let newTodo: Todo = {} ensures that newTodo follows the same structure as the rest of the todos. We then assign a random id by using v4.generate(), set todo to body.value.todo and isCompleted to false.

The thing to notice here is all the data the user sends us we can access from body.value in oak.

Next we do the following:

let data = [...todos, newTodo];
response.body = {
  success: true,
  data,
};

Append the newTodo to our current list of todos and simply set the body to {success: true & data: data.

And we are done ✅ with this controller as well.

Let's restart our server:

$ deno run --allow-net server.ts

In my postman, I open up a new tab. Set the request to POST type and in the URL bar type http://localhost:8080/todos. Then hit Send and this is what you see:

I send an empty request and get a 400 status error code along with an error message

Then I send some content in the body of the request payload and try again:

Awesome, POST /todos with body content { todo: "eat a lamma" } is success & we can see content appended to our current todo list

Cool, we can see that our API is working as expected.

Two APIs down, three more to go.

We are almost there. Most of the hard work is done. ☺️ ? ? ?

Let's move on to our third API:

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  /**
   * @description Get todo by id
   * @route GET todos/:id
   */
  getTodoById: (
    { params, response }: { params: { id: string }; response: any },
  ) => {
    const todo: Todo | undefined = todos.find((t) => {
      return t.id === params.id;
    });
    if (!todo) {
      response.status = 404;
      response.body = {
        success: false,
        message: "No todo found",
      };
      return;
    }

    // If todo is found
    response.status = 200;
    response.body = {
      success: true,
      data: todo,
    };
  },
  updateTodoById: async () => {},
  deleteTodoById: () => {},
};

Let's talk about our controller for GET todos/:id. This will get us a todo by ID.

Let's break this down into smaller parts and discuss it:

const todo: Todo | undefined = todos.find((t) => t.id === params.id);
if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

In the first part we set a new const todo and set its type to either Todo or undefined. So todo will either be an object with the Todo interface shape or it will be undefined – it can not be anything else.

We then _todos.find_((_t_) => t.id === params.id); use Array.find() to find the todo with the id provided in params.id. If it matches we get a Todo with shape todo, otherwise undefined.

If todo is undefined, it means that this if block will run:

if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

Here we simply set the status to 404 which means not found along with our standard failure response or { status, message }

Cool, right? ?

Next we simply do this:

// If todo is found
response.status = 200;
response.body = {
  success: true,
  data: todo,
};

Set a 200 success response and in our response body we set success: true & data: todo.

Let's run this in our postman.

Let's restart our server:

$ deno run --allow-net server.ts

In my postman, I open up a new tab. Set the request to GET type and in the URL bar type http://localhost:8080/todos/:id, then hit Send.

Since we are generating ID's randomly, first get all todos by hitting theget all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

Let's go:

404 status, no record found case

Provided it a known ID and it returned the todo associated with that ID along with status 200

If you need to reference the original source code of this tutorial go here.

Great, 3 APIs done, 2 more to go.

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  /**
   * @description Update todo by id
   * @route PUT todos/:id
   */
  updateTodoById: async (
    { params, request, response }: {
      params: { id: string },
      request: any,
      response: any,
    },
  ) => {
    const todo: Todo | undefined = todos.find((t) => t.id === params.id);
    if (!todo) {
      response.status = 404;
      response.body = {
        success: false,
        message: "No todo found",
      };
      return;
    }

    // if todo found then update todo
    const body = await request.body();
    const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
    let newTodos = todos.map((t) => {
      return t.id === params.id ? { ...t, ...updatedData } : t;
    });
    response.status = 200;
    response.body = {
      success: true,
      data: newTodos,
    };
  },
  deleteTodoById: () => {},
};

Let's talk about our controller for PUT todos/:id. This will update a todo by ID.

Let's break this down into smaller bits:

const todo: Todo | undefined = todos.find((t) => t.id === params.id);
if (!todo) {
  response.status = 404;
  response.body = {
    success: false,
    message: "No todo found",
  };
  return;
}

This is something we did exactly the same with the previous controller as well, so I won't go into much detail here.

Pro tip here: You can if you want make this piece of code a generic code block and then use it in both controllers.

Next we do this:

// if todo found then update todo
const body = await request.body();
const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});
response.status = 200;
response.body = {
  success: true,
  data: newTodos,
};

The piece of code I want to talk about here is the following:

const updatedData: { todo?: string; isCompleted?: boolean } = body.value;
let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});

First we do const updatedData = body.value and then add type checking to updatedData like the following:

updatedData: { todo?: string; isCompleted?: boolean }

This piece of code is telling TS that updatedData is an object which can have/not have todo: string and also can have/not have isCompleted: boolean.

Then we simply map over all todos like this:

let newTodos = todos.map((t) => {
  return t.id === params.id ? { ...t, ...updatedData } : t;
});

And where params.id match with t.id we simply append everything to that object we get from the user.

We are done with this API as well.

Let's restart our server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to PUT and in the URL bar type in http://localhost:8080/todos/:id, then hit Send:

Since we are generating ID's randomly, first get all todos by hitting get all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

404 status returned and no todo found error message given

Provided a known ID, updated todo content in body. It returned the updated todo along with all the other todos

This is amazing – four APIs done and just one more to go.

import { v4 } from "https://deno.land/std/uuid/mod.ts";
// interfaces
import Todo from "../interfaces/Todo.ts";
// stubs
import todos from "../stubs/todos.ts";

export default {
  getAllTodos: () => {},
  createTodo: async () => {},
  getTodoById: () => {},
  updateTodoById: async () => {},
  /**
   * @description Delete todo by id
   * @route DELETE todos/:id
   */
  deleteTodoById: (
    { params, response }: { params: { id: string }; response: any },
  ) => {
    const allTodos = todos.filter((t) => t.id !== params.id);

    // remove the todo w.r.t id and return
    // remaining todos
    response.status = 200;
    response.body = {
      success: true,
      data: allTodos,
    };
  },
};

Let's talk about our controller for Delete todos/:id this will delete a todo by ID.

We simply run a filter on all todos:

const allTodos = todos.filter((t) => t.id !== params.id);

Remove the todo.id that matches with params.id and return the rest.

Then we do this:

// remove the todo w.r.t id and return
// remaining todos
response.status = 200;
response.body = {
  success: true,
  data: allTodos,
};

Simply return all the todos left which do not have the same todo.id.

Let's restart our server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. This time set the request to DELETE and in the URL bar type http://localhost:8080/todos/:id and hit Send.

Since we are generating ID's randomly, first get all todos by hitting get all todos API. Then from any todo get one of its ID to test this newly created API.
Every time you restart this Deno application, new ID's will be generated.

With this we are all done with all five APIs.

Now we only have two things remaining:

• Add a not found route middleware so that when the user tries to access an unknown route it gives an error.
• Add a logger API that consoles the response time it took to return data from one API endpoint.

Creating a route middleware for routes that aren't found

In your root folder create a new folder called middlewares. Inside that folder create a file called notFound.ts and inside this file add this code:

export default ({ response }: { response: any }) => {
  response.status = 404;
  response.body = {
    success: false,
    message: "404 - Not found.",
  };
};

Here we aren't doing anything new – it is very similar to our controllers structure. Just returning a status 404 (which means not found) along with a JSON object for { success, message }.

Next go in your server.ts file and add the following content:

• Add this import somewhere at the top:

// not found
import notFound from './middlewares/notFound.ts';

• And then just below your app.use(todoRouter.allowedMethods()) add this line like this:

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

// 404 page
app.use(notFound);

The order of execution is important here: every time we try to access an API end point it will first match/check routes from our todoRouter. If none are found, it will then execute app_.use_(notFound);.

Let's see if this works.

Restart the server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to GET and in the URL bar type http://localhost:8080/something-unknown, then hit Send.

So we now have a route middleware that we put at the end of our routes in server.ts as app_.use_(notFound);. If no route matches this middleware it will execute and return a 404 status code (which means not found). Then we simply send a response message like always which is {success, message}.

Pro tip: We have decided that {success, message} is what we return in failed scenarios and {success, data} is what we return to user in success scenarios. So we can even make these to object/shapes as interfaces and add them to our project to ensure consistency and safe type checking.

Cool, now we are done with one of our middlewares – let's add the other middleware for logging our APIs in the console.

Reminder: If you get stuck anywhere you can use the source code here.

Logging APIs in console

In your middlewares folder create a new file called logger.ts and enter the following code:

import {
  green,
  cyan,
  white,
  bgRed,
} from "https://deno.land/std@0.53.0/fmt/colors.ts";

const X_RESPONSE_TIME: string = "X-Response-Time";

export default {
  logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },
  responseTime: async (
    { response }: { response: any },
    next: Function,
  ) => {
    const start = Date.now();
    await next();
    const ms: number = Date.now() - start;
    response.headers.set(X_RESPONSE_TIME, `${ms}ms`)
  },
};

In your server.ts file add this code:

• Import this somewhere at the top:

// logger
import logger from './middlewares/logger.ts';

• Just above your todoRouter code add these middlewares like this:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

Now let's discuss what we just did.

Let's talk about the logger.ts file and break it down into bits:

import {
  green,
  cyan,
  white,
  bgRed,
} from "https://deno.land/std@0.53.0/fmt/colors.ts";

I am importing some console colors and console background colors that I want to use in API logging.

This is similar to what we did in our eventListener in our server.ts file. We will use colors in our console to log API requests.

Next I set const X_RESPONSE_TIME: string = "X-Response-Time";. This is the header we will inject in our API requests as they come into our server. I am calling this X_RESPONSE_TIME and its value is X-Response-Time. I will demonstrate its usage in a bit.

Next we simply export an object like this:

export default {
    logger: async ({ response, request }, next) {}
    responseTime: async ({ response }, next) {}
};

And then we simply use it inside our server.ts file like this:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

Let's now discuss what is happening in our logger middleware code and discuss it execution style using next():

Execution of order of logging middleware when GET /todos API is called.

The only difference here and in the controllers we had before is the use of the next() function. This functions helps us jump from one controller to the other as shown in the image below.

So in:

export default {
  logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },
  responseTime: async (
    { response }: { response: any },
    next: Function,
  ) => {
    const start = Date.now();
    await next();
    const ms: number = Date.now() - start;
    response.headers.set(X_RESPONSE_TIME, `${ms}ms`)
  },
};

Keep in mind that this is what we have in our server.ts file:

// order of execution is important;
app.use(logger.logger);
app.use(logger.responseTime);

app.use(todoRouter.routes());
app.use(todoRouter.allowedMethods());

The order of execution is as follows:

• logger.logger middleware
• logger.responseTime middleware
• todoRouter controller (whatever path is called by the user, for the purpose of explanation I am assuming that the user called GET /todos API to get all todos.)

So it will first execute logger.logger middleware which is this:

logger: async (
    { response, request }: { response: any, request: any },
    next: Function,
  ) => {
    await next();
    const responseTime = response.headers.get(X_RESPONSE_TIME);
    console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
    console.log(`${bgRed(white(String(responseTime)))}`);
  },

It will come inside this function and immediately as it reads await next() it quickly jumps to the next middleware which is responseTime:

Sharing the image above again for revision.

Inside responseTime, it only executes two lines which are (look at execution order 2 in image above):

const start = Date.now();
await next();

before jumping to the getAllTodos controller. Once it goes inside getAllTodos it will run the entire code inside that controller.

Since in that controller we are not using next() it will simply return the flow of logic back to responseTime controller. There it will run the following:

const ms: number = Date.now() - start;
response.headers.set(X_RESPONSE_TIME, `${ms}ms`)

Now keeping in perspective of the order of execution which is 2, 3, 4 (look at the image above).

This is what happens:

• We capture the data in ms by doing const start = Date.now();. Then we immediately call next() which goes to getAllTodos controller and runs the entire code. Then it comes back in the responseTime controller.
• We then subtract that start date with whatever the date is at that moment by doing const _ms_: _number_ = _Date.now_() - start; ms. Here it will return a number which is basically the difference in milliseconds that will tell us all the time it took Deno to execute our getAllTodos controller.

Sharing the image once again for review:

• Next we simply set headers in our response like this:

response.headers.set(X_RESPONSE_TIME, `${ms}ms`)

Which just sets the header value X-Response-Time to the milliseconds it took Deno to execute our API.

• Then from execution order 4 we move back to execution order 5 (have a look at the image above for reference).

Here we simply do:

const responseTime = response.headers.get(X_RESPONSE_TIME);
console.log(`${green(request.method)} ${cyan(request.url.pathname)}`);
console.log(`${bgRed(white(String(responseTime)))}`);

• We get the time we passed in the X-Response-Time
• Then we take that time and simply console it colourfully in the console.

request.method tells us the method used to call our API, that is GET, PUT etc while request.url.pathname will tell the API which path the user used i.e, /todos

Let's see if this works.

Restart the server:

$ deno run --allow-net server.ts

Open up a new tab in Postman. Set the request to GET, type in http://localhost:8080/todos, and hit Send.

Hit the API a couple of times in Postman. Then when you go back to the console, you should see something like this:

API being logged in our console

This is it – we are done.

If you still feel stuck, take a look at the entire source code for this tutorial here: github.com/adeelibr/deno-playground/tree/master/chapter_1:oak

I hope that you found this article useful and that it was able to help you learn something today.

If you liked it, please do share it on social media. If you want to have a discussion about it, reach out to me on Twitter.