deno.tar.gz

deno_code

deno_unit_test_author

deno_spa

deno_spa_5200

deno_spa_server

deno_compile

deno_install

deno_spa_copy1

deno_spa_copy2

deno_spa_copy3

Deno is a runtime environment for JavaScript and TypeScript. Since it’s built to improve upon the earlier version of Node.js, Deno offers significant upgrades to improve security and real-world performance while offering developers modern instrumentation.

In this course, you’ll discover Deno’s main features and explore its similarities and differences in relation with Node.js. You’ll then be led through a series of detailed project examples and practical code exercises to master its runtime.

By the end of the course, you’ll be ready to create professional, highly performant JavaScript or TypeScript applications with Deno.

Master the Deno JavaScript Runtime

# Solution code
The code widget below contains the complete application to create a REST API server with Deno.

> **Remember**: There are different ways to implement the same project, therefore it is absolutely fine if your solution has a different structure than the one shown below.

import { Application, Router } from "https://deno.land/x/oak@v10.2.1/mod.ts";
import { oakCors } from "https://deno.land/x/cors@v1.2.2/mod.ts";
import { initDb } from './data/data.ts'

import { getAllEmployees, getEmployeeById, updateEmployee, addEmployee, deleteEmployee } from './api/employeeApis.ts';

const port = 8280;
const app = new Application();


const router = new Router();

router
  .get('/employees', getAllEmployees)
  .get('/employees/:id', getEmployeeById)
  .put('/employees/:id', updateEmployee)
  .post('/employees', addEmployee)
  .delete('/employees/:id', deleteEmployee);

app.use(oakCors());
app.use(router.routes());
app.use(router.allowedMethods());

app.addEventListener("listen", ({ hostname, port, secure }) => {
  console.log(`--- Listening on: ${secure ? "https://" : "http://"}${hostname ?? "localhost"
    }:${port} ---`
  );

  console.log(`--> You can now navigate to http://${hostname ?? "localhost"}:${port}/employees`);
});

// Init in-memory DB
initDb();

await app.listen({ port });


import React from 'react';
import { shallow, configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

import HelloWorld from './app';

var TestResult = function() {
    this.succeeded = false;
    this.reason = "";
    this.input = "";
    this.expected_output = "";
    this.actual_output = "";
}

export const executeTests = function() {

  var results = [];

  result = new TestResult();
  result.input = 'HelloWorld Component';
  result.expected_output = "span containing text 'Hello World'"

  let wrapper = shallow(<HelloWorld />);

  // Call your Challenge function here.

  let type = wrapper.type();
  let testSuccessful = true;
  let failureReason;

  if (type !== 'span') {
    testSuccessful = false;
    failureReason = "You need to render exactly one span HTML element";
  } else if (wrapper.props().children != "Hello World") {
     testSuccessful = false;
     failureReason = "You have rendered wrong message in your span element";
  }

  result.actual_output = wrapper.html();

  if (testSuccessful) {
    result.succeeded = true;
    result.reason = "Succeeded"
  } else {
    result.succeeded = false;
    result.reason = failureReason;
  }

  results.push(result);

  return results;
}


React

Dart

GoJS React

Typescript React

Vue.js

# Explanation

## `server.ts`

- **Lines 13--18**: We define our routes. When our server receives an HTTP request, it will check if the requested URL matches any of the routes we defined here. If there is a match, it invokes the callback passed as a second parameter.


- **Lines 20--22**: We register different middleware for the routes and CORS with the `use()` methods.

## `data/data.ts`

This class represents our data layer and simulates the interaction with a persistence solution, like a database.

- **Lines 3--9**: We define some mock records for our application.

- **Lines 11--18**: We add the created mock records to the `localStorage` to simulate a database and make the exercise more *real*.

- **Lines 20--85**: CRUD methods interact with the persistence tool (`localStorage` in our case). It is always important to verify that the objects received as parameters are correct. For instance, for the `deleteRecord` method, we need to check that the target record `id` is valid and the relative entity exists in the `localStorage`. If this is not the case, we return `false` and stop the method execution.

- **Lines 88--90**: This utility method checks that the given `Employee` object has a valid `id` property. It returns `false` if the object does not have the `id` property, hence it is not a valid `Employee` object, or `true` otherwise.

- **Lines 92--94**: The method verifies if a passed `id` parameter belongs to an existing `Employee` in the `localStorage`.

## `model/employee.ts`

- **Lines 1--6**: This interface describes our `Employee` model that we use in the exercise.


## `api/employeeAPIs.ts`
This file contains the business logic for the CRUD methods.

- **Lines 4--6**: The `getAllEmployees` method returns the whole collection stored locally.


- **Lines 8--17**: The `getEmployeeById` method returns a specific employee, given its `id` passed as parameter. If the employee is found, then we return a `200` as response code and the `Employee` object in the response body.
If the `id` does not refer to any employee, then we return a `404 Not Found` code and an empty response body.

- **Lines 19--32**: The`addEmployee` method expects that a new `Employee` object is passed in the request payload. If this is not the case, we immediately return a `400 Bad Format` code.
If the `body` payload is valid, we generate a random `UUID` as the identifier for the new record, and then we invoke the `addRecord` method from the data layer to add the object to the `localStorage`. In this case, we return a `201` or `500` respectively if the operation is successful or an error occurs.

- **Lines 34--69**: The `deleteEmployee` and `updateEmployee` have a similar structure. A unique employee identifier is passed and we use it to verify whether it belongs to a record in our `localStorage` and, if not, we return a `404 Not Found` code.
While the `deleteEmployee` method simply removes an entity, the `updateEmployee` method expects a set of `Employee` properties to update the existing values of the matching record (**line 63**).

> We can process *partial* updates, which means that we can send our API only the subset of properties that we want to edit, rather than the whole `Employee` object.

Let’s look at the solution for the REST API exercise.

__default

REST API: Exercise Solution

Solution code