deno todo

The canonical example of a new webservice. This is implemented
on deno using the oak
webservice framework.

installation

deno dynamically downloads and installs dependencies, so all
you need to do is install deno itself. There’s docs on their
site that explain installation.

I installed it on OSX using homebrew with the following
command:

$ brew install deno
$ deno --version
deno 1.0.0
v8 8.4.300
typescript 3.9.2

running

In order to start the server, you just need to run the server.ts
script. Since deno requires you to explicity grant permissions for
different actions, you’ll need to pass a couple flags for it to work:

$ deno run --allow-net --allow-write --allow-read server.ts

or, more dangerously:

$ deno run -A server.ts

The server will then be available at http://localhost:8080.

tests

There’s a simple e2e test that runs that exercises the 4 endpoints made
available. First, make sure you have the the server above runing. Secondly,
make sure you haven’t modfied todos.json. Finally, you can
execute them using deno’s built in test runner:

$ deno test --allow-net test.ts
unning 5 tests
test GET todos ... ok (2ms)
test POST todo ... ok (2ms)
test POST todo: returns the ID ... ok (0ms)
test PUT todo ... ok (1ms)
test PUT todo ... ok (0ms)

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (7ms)

thoughts

Overall, it was suprisingly easy to get going with deno considering how new
the platform is. The biggest shift is moving away from a package manager. Just
importing files from remote locations is a wild departure from the node world.
For the most part, everything moves quickly enough that it’s barely noticeable.
It’ll be interesting to see how this potentially less centralized model will
work. Remote code execution is scary; however, browsers have been doing it for
years, and that is the permission model deno is based off of.

Around that, I’m curious how many people will just be default add the -A flag
to the deno run command, which entitles the script to all permissions. I could
easily see folks getting confused why their script isn’t working and, after a
quick search, adding that flag.

I look forward to the future evolution of the standard library. I ran into some issues trying to use the fs module with typescript files. That lead to using
the built in Deno methods. On that note, having a standard library that is
written utilizing promises and async/await along with top level aysnc removes a
lot of the annoyances/complexity from writing small utility scripts.

The biggest annoyance to start was the delay compiling typescript. Start up with
a cached compliation is instantaneous, but can take a handful of seconds as all
the .ts files get sent through the standard tsc. There’s notes in the
1.0 blog post about a solution shifting
the type checking to Rust. Don’t expect that any time soon.

I might look to use deno for scripting problems where I would normally reach
to python. I’ll sometimes use node in these cases, but I find myself needing
to piece together a ton of small modules. Having the batteries included
simplifies the cognitive load, and let’s me stay focused on the problem.