760 reads

Everything Wrong About Deno as a Runtime System for Enterprise Applications

by onedermanJune 21st, 2020

Too Long; Didn't Read

The main issue of the Deno package manager is that it's terrible for use with the CI/CD. It's rather strange that Deno can't have almost all these features integrated by default ('out of the box') since its using area is pretty clear. Large enterprise applications will need a lot of permissions, so, from my point of view, the policies must be indicated for each package. At least for now, Deno is a bad choice for enterprise applications. At least when we have Node.js with all its developed features.

featured image - Everything Wrong About Deno as a Runtime System for Enterprise Applications

Hey there! In this article, I'm sharing my thoughts about Deno as a bad runtime system for enterprise applications. At least for now.

Note, if you have some useful information on this topic, please put it in the comments, I will be appreciated.

Package manager

The main issue of the Deno package manager that it's terrible for use with the CI/CD. I mean, if you need your CI/CD process to be fast, all the packages must be loaded manually to your app Git (otherwise, developers and testers will need to wait until everything is loaded from the web for each CI/CD launch - it's just a waste of the development time and budget). If you choose the Git option, then your developers will need to do all the upgrades manually as in the previous century (or use Node.js with the NPM instead).

import { connect } from "https://deno.land/x/amqp/mod.ts";
import * as base64 from "https://denopkg.com/chiefbiiko/base64/mod.ts";
import { createLogger } from "https://denolib.com/yamboy1/deno-structured-logging/mod.ts";
...

Also, I don't like the idea that there is no one file with all indicated packages. This will create a mess in big enterprise apps. Just imagine that 20+ developers import packages without any systematic approach. And there are no versions at all (only in some URLs or in manually created file with dependencies, which is not strictly default). It's not right from my point of view.

Packages

I expected Deno to have all the Express features so it can be used without any framework. Instead of this, we have that oak framework ('oak' is its name):

https://deno.land/x/oak

.
And for logging purposes, we need to import one more package:

https://deno.land/x/deno_structured_logging

.
And for other simple development features - more and more packages:

https://deno.land/x/

.
It's rather strange that Deno can't have almost all these features integrated by default ('out of the box') since its using area is pretty clear. At least for the most basic features like routing, logging, and debugging.

Security policies

Deno's security policies look okay only for relatively small applications. Large enterprise applications will need a lot of permissions, so, from my point of view, the policies must be indicated for each package. That's why the one root file or generator (for the monolith app, services, etc.) with packages is needed. With the current approach, one permission for the entire app is not effective if one package was infected and the permission was provided for another package on the app level (the infected package will have the permission then).

deno run  --allow-net .\main.ts
# it allows running the server via the net
# basically, there is one permission for the whole app right now

Preliminary сonclusions

From what I see right now, Deno is a bad choice for enterprise applications. At least when we have Node.js with all its developed features.

N.B. I'd like to change my opinion, so, as I wrote in the Introduction section, please share your thoughts in the comments. Thank you for your attention.