Introduction to the newline guide to building and deploying a REST API using Deno.

Welcome to Build and Deploy a REST API with Deno!

In this lesson, we will install Deno and create our setup for the rest of the course.

How to Install Deno Locally and in Docker Containers

Introduction

Deno vs Node: A Deno Fresh Start to JavaScript Runtimes

We will look at the command line interface for running Deno

How to Use the Deno REPL Command Line Interface

In this lesson, we will look at general usage of Deno by running a file and also introduce the config file

Executing TypeScript Files With Deno With the Config File

Learn how to use the Deno standard library and other external modules with URL imports

Deno vs Golang's Standard Library

How to Start a Deno Server and Set Permissions

You will learn how to make a simple token authentication in Deno

How to Build a Token Authentication Server With Deno

Getting Started with Deno

Using Databases with Deno

How to Use PostgreSQL in Docker with Deno

How to Integrate MySQL or MariaDB With Deno

How to Add SQLite to Deno with deno-sqlite

Connect to a database

Introduction to database migrations - what, why and how

What is Database Migration? The Strategy to Migrate Data

Get started with database migrations using Nessie

How to Add Nessie to Deno to Migrate Databases

We will go through creating a migration using the Nessie CLI

How to Create a New Database Migration With Deno Nessie

We will look at how to write a migration script where we create a table

Edit a Deno Nessie Database Migration to Catch Errors

We will run our migration and learn how to roll back the migration

How to Run and Roll Back a Database Migration With Deno Nessie

We will create a seed file using the Nessie CLI

How to Create a Database Seed File With Deno Nessie

We will run our seed file and populate our database

How to Import JSON Data and Seed a Database With Deno Nessie

Database migrations

Introduction to the concept of REST APIs and why we use them

REST API Introduction

We will go through the thought process of planning an application.

Best Practices for a REST API: Endpoints and Database Schema

We will create the initial project files and set up our environment

How to Prepare Deno to Build a REST API

We will create the router and look at how to test our endpoints

How to Build REST API Endpoints in Deno

It's time to add Nessie! We will now initialize Nessie in our project and also spin up our development database

Integrate a PostgreSQL Database With Nessie Into a Deno API

Time to connect our models to our database!

Building a MySQL or PostgreSQL Database Pool in Deno

In this step, we will create our first data model and create a corresponding table using a migration

Migrating Data to PostgreSQL and Modeling Data in Deno

Creating the methods to access the database

Build API Calls That Generate SQL Queries in Deno

Creating the server endpoints for the Duck namespace

Create a Database Controller in Deno

We will look at how to set up authentication and further authorize the requests

How to Authenticate and Authorize REST API Requests in Deno

We will create two new tables using a migration and create the equivalent models

Create New Tables and Models With Deno Database Migration

We will create our Quack service and controller

Add List, Create, Read, Update, and Delete Requests in Deno

The last stretch! We will create our final namespace, Crumb, and connect it to our other models and our router

How to Build Many-to-Many Namespace Connections in Deno

Now that our application is completed, we will consider some improvements and discuss alternative approaches.

API Afterthoughts

REST API

We will introduce deployments and what we will learn in this module

Deployment Introduction

We will create a Docker image for our application

How to Create a Docker Image to Containerize an Application

You will learn how to create a basic CI file for GitHub and GitLab, and run tests on them

How to Create Continuous Integration Files for GitHub and GitLab

We will deploy our application to a server using CI, SSH and git.

How to Deploy a Deno API Server With the Digital Ocean API

We will deploy our application to Digital Ocean Apps. This is by far the easiest (but most costly) approach.

How to Deploy a Deno Docker Image to Digital Ocean

Similar to how we did it in lesson 1, we will be deploying using CI and SSH, but instead of git, we will be using Docker.

Deploy with Docker

Deployment

In this course, we will learn how to work with [Deno](https://deno.land) to create a REST API using TypeScript with the web framework [Oak](https://github.com/oakserver/oak) and the migration tool [Nessie](https://github.com/halvardssm/deno-nessie). 
Deno is a JavaScript runtime created by [Ryan Dahl](https://tinyclouds.org), the same creator for Node, as an attempt to simplify the JavaScript landscape by strictly following the WebAPI specs. 
If you are interested in learning more about the motivation behind Deno, you can watch this video where Ryan Dahl explains "[10 Things I Regret About Node.js](https://www.youtube.com/watch?v=M3BM9TB-8yA)"

We will explore how to create an application using the powers of TypeScript, and learn how to traverse the Deno ecosystem which is much like the native web ecosystem. 
There are 5 modules that will take you from installing Deno and running your first lines of code, to working with web frameworks and databases, and in the end, deploying your application to a web server using a deployment pipeline.

Throughout this course, you will experience all the different aspects of Deno which you will need to create your own application in the future. 
And from this course, you will get a good feeling for if Deno is ready to be your next default for new projects.

In this course, we will learn how to create and deploy a REST API with Deno from scratch.

Build and deploy a REST API with Deno

Integrating databases into your application

Importance of database migrations in production applications

Deploying Deno applications to production using CICD

Now that we have confirmed our bare bones work, we can start adding the
endpoints, but first we need to add some error handling and create some helpers.

Every API you will find in the wild is different and opinionated, so the way you
will learn from me will of course be the same! There is no one correct way of
doing things, and some ways will be better than others for particular use cases.

In the following sections, we will be adding a lot of code, so let's prep our

Let's start with creating a unified response structure. One of the most
important things when creating a serverwith multiple endpoints which will be
consumed by a potential client, is to create standards. The most important
standard to establish is the response structure.

We will be adhering to the web standards, and therefore also actively be using

 to
tell the requester how the request went. An alternative is to always return

 and be more verbose in the body, but I would personally not recommend
this as it is easier to be web compliant.

To be a bit more verbose, I always recommend to have a standard response body.
This is my preferred format, which we will also use in this application:

{
    error: string|undefined,
    body: responseData|undefined,
}

But as creating this response for each endpoint can be a bit tiresome, we can
add a helper function.

We will start by adding a couple of type helpers to 

 since we will need
it across our application, and now is a good time to add them.

import {
  Application,
  Context,
  isHttpError,
  RouteParams,
  RouterContext,
  RouterMiddleware,
  State,
  Status,
  STATUS_TEXT,
} from "oak";
import { config as readEnv } from "dotenv";
import { router } from "./src/router.ts";
import { createErrorResponse } from "./src/utils.ts";

export interface AppState extends State {}
export type AppContext = Context<AppState>;
export type AppRouterContext<R extends string = string> = RouterContext<
  R,
  RouteParams<R>,
  AppState
>;
export type AppRouterMiddleware<R extends string = string> = RouterMiddleware<
  R,
  RouteParams<R>,
  AppState
>;

We want to keep the root project folder as clean as possible which is why we
place as much code as possible into 

 folder should be kept separate from the rest of the code.

import { Status } from "oak";
import { AppContext } from "../main.ts";

export function createResponse(
  ctx: AppContext,
  status: Status,
  data: Record<string, unknown> = {},
  errorMessage?: string,
) {
  ctx.response.type = "json";
  ctx.response.status = status;
  ctx.response.body = {
    error: errorMessage,
    data,
  };
}

We are passing in four arguments, two of them optional. The first argument is
the app context which contains the request and response object, the second is
for setting the status code, the third one is the data that we want to send
back, and the fourth one is to be used in case of any errors.

In certain applications, the response can include files or other data, but in
our case, we know that we will always only return JSON. We therefore set the
default value to an empty object.

---
title: How to Build REST API Endpoints in Deno
description: We will create the router and look at how to test our endpoints
code: https://gitlab.com/fullstackio/books/newline-course-apps/halvard-morstad-build-and-deploy-a-rest-api-with-deno-app/-/tree/main/app_with_sqlite_db%20(updated)/module_4.3?ref_type=heads
---

## REST API endpoints

Now that we have confirmed our bare bones work, we can start adding the
endpoints, but first we need to add some error handling and create some helpers.

Every API you will find in the wild is different and opinionated, so the way you
will learn from me will of course be the same! There is no one correct way of
doing things, and some ways will be better than others for particular use cases.

In the following sections, we will be adding a lot of code, so let's prep our
`import_map.json` file before we begin.

```typescript { actualFilename=../../code/module_4.3/import_map.json endChar=136 endLine=7 startChar=0 startLine=1 statedFilename=import_map.json url=https&#x3A;//gitlab.com/fullstackio/books/build-a-rest-api-with-deno-and-postgresql/module_05/lesson_03/.../code/module_4.3/import_map.json }
{
  "imports": {
    "oak": "https://deno.land/x/oak@v11.1.0/mod.ts",
    "dotenv": "https://deno.land/std@0.155.0/dotenv/mod.ts"
  }
}
```

### Response structure

Let's start with creating a unified response structure. One of the most
important things when creating a serverwith multiple endpoints which will be
consumed by a potential client, is to create standards. The most important
standard to establish is the response structure.

We will be adhering to the web standards, and therefore also actively be using
[HTTP status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) to
tell the requester how the request went. An alternative is to always return
`200 - OK` and be more verbose in the body, but I would personally not recommend
this as it is easier to be web compliant.

#### Response body

To be a bit more verbose, I always recommend to have a standard response body.
This is my preferred format, which we will also use in this application:

```txt
{
    error: string|undefined,
    body: responseData|undefined,
}
```

But as creating this response for each endpoint can be a bit tiresome, we can
add a helper function.

We will start by adding a couple of type helpers to `main.ts` since we will need
it across our application, and now is a good time to add them.

```typescript { actualFilename=../../code/module_4.3/main.ts endLine=27 startLine=1 statedFilename=main.ts url=https&#x3A;//gitlab.com/fullstackio/books/build-a-rest-api-with-deno-and-postgresql/module_05/lesson_03/.../code/module_4.3/main.ts }
import {
  Application,
  Context,
  isHttpError,
  RouteParams,
  RouterContext,
  RouterMiddleware,
  State,
  Status,
  STATUS_TEXT,
} from "oak";
import { config as readEnv } from "dotenv";
import { router } from "./src/router.ts";
import { createErrorResponse } from "./src/utils.ts";

export interface AppState extends State {}
export type AppContext = Context<AppState>;
export type AppRouterContext<R extends string = string> = RouterContext<
  R,
  RouteParams<R>,
  AppState
>;
export type AppRouterMiddleware<R extends string = string> = RouterMiddleware<
  R,
  RouteParams<R>,
  AppState
>;
```

-   `AppState` is the global state which will contain global accessible
    properties. We add this state to our contexts, and you will see in a later
    module why this is useful.
-   `AppContext` is the base Context type which we use with middlewares.
-   `AppRouterContext` is the Router Context which we will use in our models and
    controllers.
-   `AppRouterMiddleware` is the Router Middleware, it is used by our controllers.

Now, create a new folder `src` and add to it the file `utils.ts`.

> We want to keep the root project folder as clean as possible which is why we
> place as much code as possible into `src`. The exceptions are `main.ts`
> because it is an entry point, and `nessie.config.ts` because it is a config
> file. The `db` folder should be kept separate from the rest of the code.

Add the following method:

```typescript { actualFilename=../../code/module_4.3/src/utils.ts endLine=16 startLine=1 statedFilename=src/utils.ts url=https&#x3A;//gitlab.com/fullstackio/books/build-a-rest-api-with-deno-and-postgresql/module_05/lesson_03/.../code/module_4.3/src/utils.ts }
import { Status } from "oak";
import { AppContext } from "../main.ts";

export function createResponse(
  ctx: AppContext,
  status: Status,
  data: Record<string, unknown> = {},
  errorMessage?: string,
) {
  ctx.response.type = "json";
  ctx.response.status = status;
  ctx.response.body = {
    error: errorMessage,
    data,
  };
}
```

We are passing in four arguments, two of them optional. The first argument is
the app context which contains the request and response object, the second is
for setting the status code, the third one is the data that we want to send
back, and the fourth one is to be used in case of any errors.

In certain applications, the response can include files or other data, but in
our case, we know that we will always only return JSON. We therefore set the
default value to an empty object.