写点什么

Deno VS Node(含 Deno 真实业务场景实践体验)

用户头像
秋呈
关注
发布于: 2021 年 02 月 28 日
Deno VS Node(含Deno真实业务场景实践体验)

前言

我应该算是 node 的忠实拥护者与积极实践者,在校时许多项目,能使用 node 基本都上 node,甚至于目标检测等科研任务我也极力想通过某些桥接方法通过 node 调用 python(推荐 boa)。开发项目时 Express/koa 基本换着用一下,node 的源码也通过很多的博客与前辈的指导下不断地在阅读。在司工作时,接触了企业级的 node 应用,在 koa/Express/egg 等上都有一些企业级项目经验。


最近尝试真实业务场景落地 Deno,github 上发现了一个类似 koa 的中间件框架 oak【A middleware framework for Deno's net server 🐿️ 🦕】。不得不说这些人真会玩🙄。


两者区别

2021 算是 deno 元年吧,不知道“元年”两字是否适当,在 deno 发布后,狂热追求者们铺天盖地,阅读相关文章后,deno 与 node 的区别总结如下:


deno与node的不同


Deno 是一个错误的 js runtime?


deno 中文社区有这样一篇翻译文章,为什么我认为 Deno 是一个迈向错误方向的 JavaScript 运行时?,觉得还是写的中规中矩又不失道理。


原作者 Mehul 在原文以及两个视频中到底想要说 Deno 为什么没那么好?对 deno 的优点进行了对应的挑战。其观点大致梳理如下:


Deno 和 Node 确实有竞争关系,因为你必须在你的下个项目中作出选择。

Deno 现在所做的成果并不是很多,大多特性都可以在 Node 生态中较好地解决掉。

URL import 还是一场灾难。NPM 中已经有很多明星项目“竟然只有一行代码”、“暗中偷窃用户数据”、“注入挖矿代码”、“兼容性出现问题导致很多上游库受影响”等问题,URL import 本身并不能解决这些问题,更没有一个像 Node 一样强壮的社区来保证受人信任的依赖库,也就不会有更多的开发者愿意加入到 Deno 生态中。

由于 TypeScript 是 JavaScript 的超集,完全可以选择跳过类型验证,此时推荐新手在 Deno 上直接使用 TypeScript 编程坑会很大,很可能会出现一堆 any 类型。在经常性的调试报错下,TypeScript 的学习成本也较高,很容易写出低质量代码。

TypeScript 并不是直接在 Deno 上跑的,其实还是变成了 JavaScript 来跑,何必一定要集成到 Deno 中呢?

安全是一个很难的事情,Deno 宣传自己的“安全沙箱”注定要承担很大的责任。Deno 安全沙箱也没有必要,完全可以用 Docker 等容器或虚拟化技术来支持。同时,真正想搞破坏的脚本也会找到自己的方式来规避安全问题。

以当时版本下的 deno --allow-run 运行主进程从而开启的子进程能轻松突破安全沙箱的验证来获得更多权限为例,发现 Deno 的“安全沙箱”并没有所说的那么安全。

Deno 没有必要集成太多工具链(代码格式化、测试工具、TypeScript 等等)于一体,让各种第三方工具链来一起共建生态的同时,保证 Deno 本身的专注性并提供更友好的插件支持会很好。

Node 的异步模型并没有被淘汰,promise 和事件侦听器模型也没有被淘汰,因此不确定 Deno 将如何解决这些没有被淘汰的问题。

未来并不确定会有多少开发者愿意将 npm 中的成熟库逐渐迁移到 Deno 中。


实践出真知

你要知道

这不是一篇教你怎么开发一套短网址服务的教程,这是我体验 deno 真实开发后的感受。真理源于实践,两者同是 JS 的 runtime,出于同一作者。出于验证心理,我使用 deno 实现了一下很实用的短网址服务,通过开发这个服务深度体验了 deno 的优缺点,下面我来大概谈谈自己的实现过程和开发感受。

实践体验与感受:

1.内置 TS,确实方便不少,不用再 babel,不用再有 dist🤓,当然只是省掉了人工成本

2.ESM 我并没有感觉多么的改善 node_module,import 确实让我感觉回到了 module 之前的不断地 script+async 引入 js 文件的感觉。同时,也需要一个好的包管理器(社区可能有我没用)。

3.初次运行需要缓存所有的 import,遇到墙很麻烦

4.安全沙箱,确实安全,需要各种 allow,就开发效率运行安全综合感觉不要 os 层面的安全,在包管理处做好安全感觉是最好的选择

5.实践只做了正向的服务开发,相关的集成开发,运维,log 等模块还有待社区壮大

6.顶层直接支持 promise,async/wawit 写着确实爽

7.花了 2 天采坑实现 shorturl,以上是目前的感受

短链接服务(shorturl)

你一定经历过因为某款软件发布动态有字长限制,而你想要分享的链接又超长。

你一定收到过各种 isp 短信,例如:移动啥啥啥,给你发的短信中包含一段网址,点击跳转浏览器后变成了一段特别长的网址

......

以上都是短网址服务的实际应用场景


基于以上的思考,利用 deno 开发一个短网址服务 idea 就产生了,花了小 2 天时间,因为踩了 deno 的各种坑,用 node 可能就 2 小时。最终的服务如下: 点击访问官网

短链接服务演示截图


简单的理解不难想象出,短链接的直观功能是:

1.输入一段长 url,并提交

2.服务器收到长 url 后,通过相关的定长算法(hash 等)生成唯一定长的短 url

3.存入数据库进行持久化

4.访问短链接,服务通过短链接查询到原链接,并通过 301 或 302 进行重定向


开发过程

1.环境安装

我是在 Mac 上开发的,服务器是 windows server,Mac 上利用 curl 安装即可


curl -fsSL https://x.deno.js.cn/install.sh | sh
复制代码


Windows 上利用 powershell,安装很方便,不知道是因为是云服务器的原因还是为何,mac 遇见的墙 windows 并没有遇见,下载安装也十分的快。


iwr https://x.deno.js.cn/install.ps1 -useb | iex
复制代码


2.mvc 构建

网上好多都是一个 ts 文件搞定(这也是最终目的),但为了项目的后期维护与开发,我还是上了 mvc,现在的文件结构是这样的,开发过程中我一度觉得我在写 egg😄,真的是超像!有时候就觉得那些外国大佬是不是太无聊了,需要开源个东西圈开源基金。

项目结构


3.数据库连接

数据库连接用了自带的 client 创建连接池,本想找个 orm 的,找了半天也没找到,就自己封装 model 进行 query 了。

总结

一个是 c++的底层 runtime,一个是 rust 的底层 runtime,node 和 deno 的比较不仅是两者开发实践效率,性能,社区完备性(这个可能暂时也没法比,但我看 deno 的 star 已经和 node 相差无几了,社区也会不断火起来的)等的对比,更是底层语言的比拼。


新技术的成熟需要数以年计的社区维护,需要数以万计的开发者加入,node 已经发展数年,社区成熟的包,成熟的方案能解决绝大部分开发问题,deno 的发展还得看社区。


至于 deno 和 node 最终谁会成为 hoster,我觉得大可不必,作为技术人,技术是自己的,不用过多的参与社区非 A 即 B 的讨论,这世界本就是多元的,我们是做不到最好的,只能做到最优,提升自己,在面对问题时,能够给出最优的解决方案才是我们应该做的。


发布于: 2021 年 02 月 28 日阅读数: 60
用户头像

秋呈

关注

半吊子技术人,三分钟热情积极实践者 2019.09.06 加入

计算机硕士研究生 擅长深度学习的目标检测方向 喜爱前端,喜爱新技术,喜爱新技术带来的创新 喜爱前端与新技术的结合(前端智能化方向) 曾在爱奇艺、腾讯、阿里巴巴任职软件工程师职位

评论

发布
暂无评论
Deno VS Node(含Deno真实业务场景实践体验)