Categories
程式開發

对企业应用程序而言,Deno是一个糟糕的选择


在本文中,我会分享自己的一些想法,谈一谈为什么 Deno 不适合用作企业应用程序的运行时系统,至少现在如此。欢迎大家在评论中补充有用的信息。

包管理器 Deno 包管理器的主要问题是,它在 CI/CD 中很难用。我的意思是,如果你需要快速执行 CI/CD,则必须将所有软件包手动加载到你的应用 Git 中(否则,每次 CI/CD 启动后开发人员和测试人员都需要等待从网络加载所有内容——这只是在浪费开发时间和预算)。如果选择 Git 这个选项,那么你的开发人员需要像上世纪那样手动进行所有升级(或者干脆换成带有 NPM 的 Node.js)。

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";
...

另外,我不喜欢 Deno 不在一个文件中指示所有包的做法。在大型企业级应用程序中这是会造成混乱的。试想一下,超过 20 位开发人员无需任何系统化方法即可导入软件包。而且根本没有版本控制(仅在某些 URL 中或手动创建的带有依赖项文件中才有,这不是严格的默认设置)。我认为这是不对的。

我希望 Deno 具有所有 Express 功能,这样就不用任何框架了。但 Deno 并没有这样做,而是引入了那个 Oak 框架(“Oak”是它的名字):

https://deno.land/x/oak

为了记录日志,我们需要再导入一个包:

https://deno.land/x/deno_structured_logging

为了其他一些简单的开发功能——我们需要越来越多的包:

https://deno.land/x/

奇怪的是,Deno 默认(“开箱即用”)几乎没有集成其中的任何功能,要知道它的使用场景是非常清晰的。至少应该集成最基本的功能,例如路由、日志记录和调试吧。

安全策略

Deno 的安全策略仅适用于相对较小的应用程序。大型企业应用程序需要大量权限,因此在我看来,我们必须为每个软件包指定策略。这就是为什么我们需要一个带有包的根文件或生成器(用于单体应用、服务等)的原因所在。使用现在的方法时,如果一个包被感染,并且在应用级别为另一个包提供了权限(所以被感染的程序包将具有该权限),那么整个应用的这个权限都会失效。

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

初步结论

从我现在看到的情况来看,对于企业应用程序而言 Deno 是一个糟糕的选择。Node.js 有那么多成熟的特性,我们至少可以继续用它。

原文链接:
https://hackernoon.com/everything-wrong-about-deno-as-a-runtime-system-for-enterprise-applications-eb1b3yyi