5 Ways to Build a HTTP Server With Deno

Deno’s growth has started to accelerate at an unprecedented rate. Partly because the creator is Ryan Dhal and partly because the JavaScript runtime looks extremely promising. Already, we have several different ways to create an HTTP server, the base for almost every modern application.

In this article we will explore five ways to create a HTTP server with Deno, using the standard library and four packages.

You can find all the code here: https://github.com/tomanagle/deno-http-servers

Note: None of these solutions is a great choice for a brand new application. Deno is not ready for you to risk your job with, so it’s best to wait a while before you start suggesting Deno for your company’s next big project.

Standard library

The Deno standard library provides a rich set of features that can be used as the building blocks for almost any application. Like most modern programming languages and runtimes, Deno‘s primary use will be web applications, specifically servers that interface over HTTP.

The standard library provides a clean and simple way to make a HTTP server. The library alow includes packages for managing cookies.

If you’re not familiar with Deno, there are three things you will notice about the simple HTTP server above:

There’s no package.json, you import files from a link — This is a really cool feature that eliminates the need for a bloated package.json and allows you to do cool things like this:

The await keyword is not inside an async function — Deno has top-level await out of the box, a feature that’s in stage 3 for Node.js.

You need to add — allow-net — allow-read to your run command — Deno is secure by default. If you want to poke holes through the V8 JavaScript Engine sandbox, you need to explicitly say so.

Documentation: https://deno.land/std/http

Run the server: deno run — allow-net — allow-read https://raw.githubusercontent.com/tomanagle/deno-http-servers/master/standard-library.ts

Oak

Oak is one of the most promising HTTP servers available for Deno, partly because it was founded by Kitson Kelly and partly because it was inspired by Koa, a popular HTTP server for Node.js.

Creating a server with Oak is very simple and the layout is a little bit nicer than the standard library server, mainly because there is no for loop.

Documentation: https://github.com/oakserver/oak

Run the server: deno run — allow-net — allow-read https://raw.githubusercontent.com/tomanagle/deno-http-servers/master/oak.ts

Servest

Servest is one of the most progressive HTTP module suites for Deno. It has its own implementation of the HTTP/1.1 and allows you to render and server JSX.

Unfortunately, I could not get Servest to render and serve JSX, it may be because my editor didn’t like the syntax. From my experience, being able to render and serve JSX, even HTML from the server is not a feature that is useful in most applications.

Rendering JSX from the server is something that you've been able to do with Express for a long time. Instead, many developers are opting for an entirely different application to handle their client and server-side rendering, such as Next.js.

Furthermore, the handle request looks a lot like Hapi, a Node.js framework that is popular, but not one that I’m particularly thrilled to work with.

While the Servest team has done a great job to get a Deno server out the door very quickly, it feels like more of an experiment than a production-grade server. Experiments are extremely important and have a lot to offer the community, but are not suitable for building companies on.

Documentation: https://github.com/keroxp/servest

Run the server: deno run — allow-net — allow-read https://raw.githubusercontent.com/tomanagle/deno-http-servers/master/servest.ts

Abc

Abc claims to be a better Deno framework to create web applications. While it is a little bit different, it’s hard to tell why exactly it's better, beyond the cleaner code structure. Like Servest, Abc also provides support for JSX, a feature that might be interesting at first, but I’ve never really found a need for it beyond experimentation.

Abc allows you to chain your routes together from the app method. This style of routing looks nice for small applications, but it may get quite large in more complex scenarios.

Abc also allows you to split the routes off in more of an Express style.

Documentation: https://github.com/zhmushan/abc

Run the server: deno run — allow-net https://raw.githubusercontent.com/tomanagle/deno-http-servers/master/abc.t

Pogo

Pogo is inspired by Hapi and encourages reliable, tested application development. It also allows you to render and serve JSX.

Like Hapi, Pogo offers a lot of flexibility in the way routing is configured. You can call the server.route method for each endpoint, or pass an array of configuration objects to the server.route endpoint. This helps keep your routes clean and maintainable in large applications.

Documentation: https://github.com/sholladay/pogo

Run the server: deno run — allow-net https://raw.githubusercontent.com/tomanagle/deno-http-servers/master/pogo.ts

Conclusion

A common these among Deno frameworks is the support for JSX rendering, which I find surprising. It may be that it’s an actual requirement for a lot of projects that I’m not aware of, or it’s an easy way to provide a unique selling point to a framework. If you know what you think in the comments.

So, what would I choose if I was to start a new project with Deno? Firstly, I would only start a new project with Deno right now to test it out and play around. But if I was going to do that, I would start with the standard library and then adopt Oak when the requirements increased.

I am a full stack JavaScript developer, living in Melbourne, Australia. My preferred stack is Mongoose, TypeScript, Node.js, React & GraphQL.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store