DEV Community

Cover image for Building a restful API using Deno (Part1)

Building a restful API using Deno (Part1)

Vinicius Cerqueira Bonifácio
Self-taught MERN stack developer, technology passionate, Ruby on Rails admirer, Ubuntu evangelist, ex mountain guide, active football player, inactive surfer, professional backpacker and hitchhiker.
Updated on ・4 min read

Hey, dear mates!

How is it going? I hope you all are fine. :)

So, one week has already passed and it is time to put hands-on in the first part our project, right? Yeahhhh!

If you have no clue what I am talking about, please read my last two posts Deno is not here to replace Node, Building a restful API using Deno (Intro) and Building a restful API using Deno (Part2)

I assume you guys have already some Javascript experience but feel free to point out if you didn't understand any code you saw, (through comments or DM me if you are shy), also if you know a best approach or even correct me if I made a mistake.
All questions here worth gold and also helps me improving my way to learn, teach and create better content.

"Anyone who has never made a mistake has never tried anything new." (Albert Einstein)

We are trying something brand new (DENO) so let's make mistakes together.

So, take your coffee mug, put The Sims build mode as your background music and "letis getty ztared".


I am going to be as succinct as possible in order to avoid being overwhelming so we can focus in the important parts that really need to be explained.
Said that, let's kill two birds with just one bullet (NOT literally saying).

Open your VSCODE, click Terminal > New Terminal and type:

curl -fsSL | sh
Enter fullscreen mode Exit fullscreen mode

Now we have Deno installed.
*OPTIONAL: You can add the following VSCODE extension for better experience. Visual Studio | Marketplace.

Just that? Yes.
(HINT: When following tutorials ALWAYS research what you are typing / copying and pasting in your terminal and from which source it came from.)

Project Structure Folder

We could simply add all the code in just one file but it is a good practice to separate each module and their own folder/ file even our project is small.

I though in a structure similar to this:

Alt Project Structure on VSCode


Create a config folder with a config.js file inside of it.

/* I separated this small chunk of code in its own file because
   we will implement environment variables soon using Deno.env.toObject() */

export const PORT = env.PORT || 5000;
export const HOST = env.HOST || "";
Enter fullscreen mode Exit fullscreen mode

We simply have just assigned both values of PORT and HOST in order to use them to start our server.

NOTE: When we have sensible data that must not be exposed, for instance, a MongoDB connection string, we could use as an alternative, a .env file and "git ignoring" it in your repository. By the way, it should be nice add this feature in the future but if you are in a fast pace than us just check the deno-dotenv documentation

app.js file

/* Here we are importing the Deno third part modules
   You can also copy and paste this URL in your browser to check the 
   documentation :) */ 
import { Application } from "";

/* This line creates the new Application*/
const app = new Application();

export default app;
Enter fullscreen mode Exit fullscreen mode

I know, there are actually more comments in this file than Javascript code. Please, be patient.

server.js file

/* We are importing the values from the config file we created previously*/
import { PORT, HOST } from "./config/config.js";

/* The same with happening with this file line*/
import app from "./app.js";

/* console.log() our best friend */
console.log(`Listening on ${HOST}:${PORT}`);

/* Our application will listen in the host and port we assign*/
await app.listen(`${HOST}:${PORT}`);

Enter fullscreen mode Exit fullscreen mode

Did you notice something weird in this file other than my comments? No?
Read it again carefully. Not yet?
Wait, we are using await without async and no, it was not my mistake. Different of Node, Deno is async by default, in other words, when in global scope you don't have to create an async wrapper function just to use await. That is one of the magical features that Deno brings for us.

Let's run our tiny but not least application. I assume that you are in your project directory's folder.

deno run server.js
Enter fullscreen mode Exit fullscreen mode

We got the error below but I will explain why.

error: Uncaught PermissionDenied: access to environment variables, run again with the --allow-env flag
at file:/home/kako77sub/deno_projects/deno-restful-improved/config/config.js:1:22

Enter fullscreen mode Exit fullscreen mode

Deno entirely controls what programs can access / run or not. The security is the main reason why Deno exists and it is why we should draw our attentions on it. Let's run it again but this time adding the --allow-env flag.

deno run --allow-env server.js
Enter fullscreen mode Exit fullscreen mode

We got another error. It happened because our app.js file imports content from external resouces (e.g. Easy peasy lemon squeezy, the error message already gave us a hint.

deno run --allow-env --allow-net server.js
Enter fullscreen mode Exit fullscreen mode

If I did everything how it supposed to be done you should see in your terminal something like:

Listening on
Enter fullscreen mode Exit fullscreen mode

We got it!

We already have our server running (To stop it the old CTRL + C should be enough).
So what does it do? Honestly, nothing yet because we didn't implement the routers and controllers.

It is going to be our next task in the next post.

Thanks and see you all on next weekend.

Discussion (2)

seanmclem profile image

Just curious, why not use typescript? Thanks for the post! I'm enjoying Deno so far

vinicius77 profile image
Vinicius Cerqueira Bonifácio Author

Hi Seanmclem,

Thanks for you comment. :)

I chose Javascript instead Typescript because there are lots of tutorials written using it out there.

But no doubts that Deno / TS combination is more powerful than Deno / JS.