这篇文章将使用 deno 的 web 框架 Fresh，一个简单的 Web 应用 Link Maker，一个用于将链接转换成卡片样式的预览效果。

这个项目也放在了 fresh 的 Showcase，感兴趣的可以查看一番。

Deno 是一个安全的 JavaScript 和 TypeScript 运行时，作者是 Ryan Dahl（也是 Node.js 的原作者）。Deno 的诞生之初是为了解决 2009 年首次设计 Node.js 时的一些疏忽。我认为这种改造动机很有道理，因为我相信每个程序员都希望有机会能重写他们已有 10 年历史的代码。

deno 刚出的时候就听闻了，传言 deno 是下一代 node.js。不过如今看来，还革不了 node.js 的命。如果要说两者字面上的区别，Deno 的来源是 Node 的字母重新组合（Node = no + de），表示"拆除 Node.js"（de = destroy, no = Node.js）。

趁着假期学了一段时间的 deno（指文档刷了一遍），想分享本人作为 node 开发者在学习 deno 时认为的一些亮点，以及个人对 deno 与 node 见解。

我初识 WebAssembly 是当初想要分析某个网站的加密算法，最终定位到了一个 .wasm 文件，没错，这个就是 WebAssembly 的构建产物，能够直接运行在浏览器中。在我当时看来这门技术很先进，不过如今看来绝大多数的 web 应用貌似都没使用上，迄今为止我也只在这个网站中看到使用 WebAssembly 的（也许有很多，只是没实质分析过）。

恰好最近正在接触 Rust，而 Rust 开发 WebAssembly 也非常方便，因此本文算是我对 Rust + WebAssembly 的初探。

距离上一篇博文有一个月之久，距离上次编写代码也有一周之久，由于疫情封控全面放开，加上福建省教育厅通知的提前返乡，反而让我感到有些不适。往常这个时间点我忙于期末考试，会把代码的事情放一边，等到彻底放假后，开始闭关潜心学习。然而剩余的半个月变成了线上形式，课还是要上，考试还是要考，虽说身在家乡，但心不在焉的。

12 月已过半，也是时候该写年终总结了。迄今为止，我已学习了 3 年半的编程（还好不是两年半）。当下的技术不再是当初只会易语言的小伙了。只是当下已没有当初如此强烈的热情与精力了，我称之为老了。

今年主要总结我为何从逆向转 Web 开发，并明确我未来所要走的方向，也是本文的主题。仅作为个人感悟，不作为建议参考。

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。

大概率你听说过 GraphQL，知道它是一种与 Rest API 架构属于 API 接口的查询语言。但大概率你也与我一样没有尝试过 GraphQL。

事实上从 2012 年 Facebook 首次将 GraphQL 应用于移动应用，到 GraphQL 规范于 2015 年实现开源。可如今现状是 GraphQL 不温不火，时不时又有新的文章介绍，不知道的还以为是什么新技术。

近期准备写一个工具包 @kuizuo/utils，由于要将其发布到npm上，必然就要兼容不同模块（例如 CommonJS 和 ESModule），通过打包器可以很轻松的将代码分别编译成这不同模块格式。

恰好 rollup 3 正式发布，也算是来体验一下。

目前技术圈的发展速度可谓是有目共睹，尤其是前端，每隔一段时间就出新的技术，可以说让很多初学者非常畏惧，没有一个明确的方向不知道从何学起。

同时也有很多人，只局限于使用手头已掌握的技术，而不愿去尝试新技术。举个例子，如今 vue3 都已经正式发布，但仍还有停留在 vue2 不愿尝试 vue3 的开发者。而 java 都发布 18 版本了，可还有很多人都还使用着 java8，这种现象可以说是非常常见了。

这里说说我个人编码经验与看法，仅作为个人观点，没别的意思。

如果你的项目要长期使用并维护的话，那么代码自动测试就非常有必要使用。因为没人能保证在修改代码后，不会引发其他额外 bug（功能失效，渲染失败），而在修改完代码后，跑一遍测试就能很大程度让开发者发现自己所修改的代码是否存在问题，是否会导致原有功能失效。

尤其是在其他人接手这个项目时，诱发 bug 的概率自然也就更高（因为他有很大的可能不知道这部分代码的上下文的功能用途），所以这也就是为什么很多开源项目与大型企业的公司都会使用自动化测试，以及要求一定的代码覆盖率。

当然如果项目不是长期维护的，那么完全没必要编写测试代码，这么做无疑是在浪费开发者的时间。

之前搭建过 Gitlab，但是就只是搭建而已，并未实际使用，因为我大部分的代码还是存放在 Github 上。

并且大部分项目都是在 Vercel 上运行的（Vercel 是真好用），但是最近国内访问 vercel 情况不容乐观，貌似被墙了呜呜。然后 Gitlab 的资源占用非常严重，几乎占用了一半的服务器性能，可 点我 查看运行状态。与此同时，随着很多私有项目越来越多，使用 git 私有仓库以及 Vercel 部署，肯定不如自建私有 git 服务和自有服务器部署使用体验来好。

于是就想搭建一个轻量级仓库，同时支持 CI/CD。经过一番的调研，决定使用 Gitea 和 Drone 作为解决方案。