A super-simple Deno app that pulls (from an API) national COVID-19 stats for India, and displays the total count of people who have recovered from the disease till yesterday*.
* the API we use for fetching data provides stats for up to a day prior
What else did you expect? Let's spread some positivity in tough times!
- Writing a Deno program (
index.js
) - Writing TypeScript (all code + interfaces inside
models/
) - Running a Deno program (see Running)
- Security and permissions (see Running)
- Importing external modules (inside
tests/util_test.js
) - Making network calls (inside
index.js
) - Debugging a Deno program (see Debugging)
- Unit testing (see Testing)
- Inspecting dependencies (see Dependency Inspection)
- Creating a browser-friendly bundle (see Bundling)
- Continuous integration & deployment (see CI/CD)
deno run --allow-net index.ts
Produces an output like (as of 05-Jun-2020):
108450 out of 226714 people are healthy again 😄
deno test
Produces an output like:
running 2 tests
test getDateString() works correctly with single-digit date ... ok (3ms)
test getDateString() works correctly with double-digit date ... ok (1ms)test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (4ms)
Using VS Code's debugger is not very complicated even in the case of Deno apps. It's a tad similar to how we use it with pure, simple Node.js programs. See the file .vscode/launch.json
to learn more.
To start debugging, go to VS Code's Run sidebar and start the "Deno Debug" script. Then on, you should be able to do something like this:
Since unlike Node.js Deno does not use a package manager and rather relies on the use of distributed http-hosted external modules, manually keeping a tab on a file's dependency tree may get difficult.
You can use Deno's built-in tool for the purpose:
deno info <file or URL>
For example, our util_test.ts
file depends on a local module (util.js) and an external module called asserts.ts. The asserts.ts module in turn depends on more modules. How do find that out? Simple:
$ deno info tests/util_test.ts
...
deps:
file:///Users/anurag/Code/Sandbox/hello-deno/tests/util_test.ts
├─┬ https://deno.land/std/testing/asserts.ts
│ ├── https://deno.land/std/fmt/colors.ts
│ └── https://deno.land/std/testing/diff.ts
└── file:///Users/anurag/Code/Sandbox/hello-deno/util.ts
One of the key goals behind Deno is to keep its APIs as close to the web standards as possible. So classes, functions and variables outside of Deno namespace are named as per modern web standards. Eg. fetch, TextEncoder, console, crypto, window, and so on.
This is a powerful thing. It means that we can potentially run the same Deno program on both server and browser.
Our little program index.ts
is browser-friendly. We can use Deno's built-in bundler to combine all dependencies and generate a single file to use as a script/module inside a static HTML file:
deno bundle index.js > public/bundle.js
Also see the CI/CD section below on how we are using this feature for continuous deployment.
This repo uses the wonderful Travis CI service for continuous integration & deployment, and the surge.sh service as our deployment/web server.
Our CI pipeline is probably the simplest one possible: it just runs unit tests and builds a JS bundle. Our CD pipeline then picks up the bundle and deploys it to Surge.
Since official support for Deno does not yet exist in most (or any!) CI providers, we have to rely on our own hacks. Before running the pipeline, we instruct Travis to install Deno and make it available globally:
before_install:
- curl -fsSL https://deno.land/x/install/install.sh | sh
- sudo mv ~/.deno/bin/deno /usr/local/bin
script:
- deno test
- deno bundle index.ts > public/bundle.js
Check this page for details on configuring your own Surge deployment.
If all goes well, your Surge site will look like this:
Deno Package Manager (dpm)
Copyleft 2020 • MIT licensed
Anurag Bhandari [email protected]