请选择 进入手机版 | 继续访问电脑版

登录 

游客您好!登录后享受更多精彩

查看: 709|回复: 3

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

[复制链接]

2

主题

5

帖子

13

积分

新手上路

Rank: 1

积分
13
发表于 2020-7-29 15:20:00 | 显示全部楼层 |阅读模式
​​在本文中,我会分享自己的一些想法,谈一谈为什么 Deno 不适合用作企业应用程序的运行时系统,至少现在如此。欢迎大家在评论中补充有用的信息。


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




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




初步结论



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


参考阅读:
https://hackernoon.com/everything-wrong-about-deno-as-a-runtime-system-for-enterprise-applications-eb1b3yyi​​​​
回复

使用道具

1

主题

5

帖子

13

积分

新手上路

Rank: 1

积分
13
发表于 2020-7-29 16:20:00 | 显示全部楼层
没用过
回复

使用道具

4

主题

7

帖子

168

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
168
发表于 2020-9-10 11:02:28 | 显示全部楼层
我倒觉得未必,有缺陷很正常,最重要的是有人持续维护,时间是 检验最好的工具。
回复

使用道具

0

主题

1

帖子

0

积分

新手上路

Rank: 1

积分
0
发表于 6 天前 | 显示全部楼层

认真看过

回复

使用道具

您需要登录后才可以回帖

本版积分规则

粤ICP备20043801号-1  Copyright ©广州市开放邑软件科技有限公司

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表