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 见解。

开发环境​

Installation | Manual | Deno

默认情况下 deno 会根据不同的系统，选择相应的安装目录，以及依赖目录，你可以配置环境变量来改变 deno 的默认行为。

这里我选用 vscode 进行开发，安装deno 官方插件。此时创建一个项目工程文件夹，打开 vscode，并创建 .vscode/settings.json 内容如下

{
  "deno.enable": true,
  "deno.lint": true,
  "editor.formatOnSave": true,
  "[typescript]": {"editor.defaultFormatter": "denoland.vscode-deno"}
}

在 vscode 中默认会将 ts 代码认为是 node 运行时环境，因此需要在项目工程下手动配置并启用 deno，让 vscode 以 deno 运行时环境来语法解析 ts 代码。

deno 的一些亮点💡​

因为 deno 与 node 一样，都是 javascript 运行时（deno 合理来说是 typescript 运行时）。所以在 javascript 的部分就没什么好说的了，主要对比 deno 相比与 node 的优势，或说我个人觉得一些使用亮点。

官方所介绍的亮点​

以下是官方所介绍的亮点，我对其做了翻译

• 提供web 平台功能，采用网络平台标准。例如，使用 ES 模块、Web worker 和支持 fetch()。

• 默认安全。除非显式启用，否则无法访问文件、网络或环境。

• 支持开箱即用的 TypeScript。

• 提供单个可执行文件 （deno）。

• 为编辑器提供内置的开发工具，如代码格式化程序 （deno fmt）、linter （deno lint）、测试运行程序（deno test）和语言服务器。

• 拥有一组经过审查（审核）的标准模块，保证与 Deno 一起使用。

• 可以将脚本捆绑到单个 JavaScript 文件或可执行文件中。

• 支持使用现有的 npm 模块

以下会针对部分亮点，进行个人的见解。

自带实用工具​

deno 则是自带代码格式化（deno fmt）、代码风格（deno lint）、代码测试（deno test）、依赖检查器（deno info）等等的功能。而这些在 node 中，你需要通过第三方的库，如 eslint，jest 才能实现。

你可以在项目工程中添加配置文件 deno.json来定制化代码风格（rust 中也有类似的功能），但在 node 中必须要借助第三方的库，或是 IDE 才能实现。

不过也能理解，在当时的编程环境背景下，javascript 还主要作为前端的脚本语言使用，又怎能让 node 来做相关规范呢？（这句话可能有点不妥）

这点我认为对开发者是否选用你这门语言的一个加分项，并且这些功能也应该作为编程语言所自带的，有官方的背书（保证），对代码风格才更有所保障。

这里有份 官方小抄 可以知道通过deno xxx等命令能够做到 node 原本需要通过第三方库才能实现的功能。

远程导入​

与 node 不同，使用 node 通常需要从 npm 官方包来下载并导，有 npm 这样的包管理器来统一管理这些包（package），我们通常称这种为中心化，而 deno 与 go 的做法很像，你可以将你的封装好的代码定义成一个包，并将其放在任何网络可访问的地方，比如 github，或是私有地址，然后通过网络读取文件的方式来导入，这种称为去中心化。

关于中心化与去中心化管理，各有优缺，这里不做细致讨论。

以下是 deno 官方远程导入的代码示例：

Command: deno run ./remote.ts

import {add, multiply} from 'https://x.nest.land/ramda@0.27.0/source/index.js';

function totalCost(outbound: number, inbound: number, tax: number): number {
  return multiply(add(outbound, inbound), tax);
}

console.log(totalCost(19, 31, 1.2));
console.log(totalCost(45, 27, 1.15));

/**
 * Output
 *
 * 60
 * 82.8
 */

而这里的 https://x.nest.land/ramda@0.27.0/source/index.js 可以替换成任何 ES module 特性（import/export）的模块。

http 的方式运行代码​

既然都能通过 http（cdn）远程导入模块，那远程运行文件自然也不成大问题。有时候像快捷体验一下别人的代码，或是想要在浏览器中运行一下代码，这时候就可以通过 http 的方式来运行代码。

这里我准备了一段代码，并部署到我的站点上，你可以通过如下命令得到该代码的执行结果（如果你有安装 deno 的话），放心这段代码并无危害，就是一段简单的 console.log 输出。

deno run https://deno.kuizuo.cn/main.ts

在第一次使用时下载并缓存代码，你可以通过

deno info http://deno.kuizuo.cn/main.ts

来查看文件信息，如下

deno info 还可以查看 deno 的相关配置，默认缓存都设置在 C 盘，你也可以设置DENO_DIR 环境变量来更改 deno 目录，可以到 Set Up Your Environment 查看 deno 相关环境变量。

依赖管理​

经常使用 node 的开发者应该对 node 的依赖感到无比厌烦，关于这部分强烈建议看 node_modules 困境，你就能知道 node 的 node_modules 设计的是有多少问题。看完你也就能知道为啥越来越多的 node 项目都使用 pnpm 作为包管理。

虽然 node 有了 pnpm 包管理器这种情况会好一些，但本质在项目目录还是需要 node_modules 文件。也许你用过其他语言的包管理器，你会发现基本都是将所有用到的依赖全局缓存起来，当不同的项目工程需要用到依赖时，直接去全局缓存中找，而不是像 npm 一样，下载到项目工程目录下，存放在 node_modules 里。

而 deno 也是采用这种这种方式，no npm install，no package.json，no node_modules/ ，使用 npm 包可以像下面这样，当你使用 deno run 时便会下载好依赖置全局缓存中。

// @deno-types="npm:@types/express@^4.17"
import express from 'npm:express@^4.17';
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World');
});

app.listen(3000);
console.log('listening on http://localhost:3000/');

deno 刚发布的时候，甚至还不支持 NPM 软件包，这无非是要告诉用户 deno 社区没有轮子，要求用户自己去造一个。不过 deno 团队还是做出了比较正确的选择，支持 npm 软件包，并且还非常友好。

不过如果你在 deno 中使用了 npm 包，可能会存在一些兼容性问题，万一遇到了，也可以通过添加 --node-modules-dir 标识，在当前运行目录下创建 node_modules 文件夹。详见 --node-modules-dir flag

安全​

Permissions

在 2022 年 npm 出现过一些恶性的库，如 lodash-utils, faker.js, chalk-next。万一你不小心安装了上面，轻则项目无法运行，输出无意义乱码，重则删除本地文件。

又因为 npm 几乎没有代码审计的机制，任何开发者只需要有一个 npm 的账号就能在上面随意发布他想发布的包。通常来说电脑病毒都是通过随意读取与写入本地文件来达到病毒的目的，但在 deno 中，代码如果尝试写入与读入文件，都需要询问开发者是否允许操作。并且在 linux 系统，你可以指定像 /usr /etc 这样非 root 角色来操作该文件，避免真是病毒文件导致删除不该删除的文件。

此外像命令执行，网络访问，环境变量这些极易危害电脑的权限，deno 都会检测到，并做出提示告诫开发者是否允许执行。总之你能想到的电脑安全隐患，deno 都为你做好了。

内置浏览器环境（运行时）​

这是我认为 deno 最大的亮点。

总所周知，浏览器的 js 代码有很大概率是无法直接在 node 中跑起来的，原因就是 node 的全局对象中没有浏览器的对象，如 window，document，甚至连localStorage 都有！

这说明什么，往常如果你从别的网站扣了一段代码下来，想在 node 运行会发现什么 window is not defined，xxx is not defined。如果想在 node 运行，你必须需要补齐浏览器的环境，此外可以借助 js-dom，happy-dom 等 npm 包。而 window，xxx 这些全局只有浏览器才定义的全局对象在 deno 的运行时同样定义了，可以到这里查看支持的 Web 平台 API。

虽说与真实浏览器全局对象有些许差异，但这也足够让开发者少做很多工作。比如 Web 逆向者通常要扣取浏览器的 js 代码，并补齐环境使其能够在 node 中运行，而有了 deno 这将变得非常轻松！

与其说是 javascript/typescript 运行时，我更愿意说是浏览器运行时！

Web 框架​

你可以在 Web Frameworks 中看到 deno 官方所推荐的 Web 框架，其中 Fresh 也是最为推荐使用的（后续我也会尝试使用该框架）。

而在 node 社区中，你会看到像 express，koa，nestjs 等等这种非 Node 官方或大背景的 web 框架（而且还很多），而这时对于初学者而言，就有点不知道该如何做出抉择。

而像 java 中你完全可以不用担心该学什么，说学 spring 就是在学 java 这可一点都不为过。可能这也是国内 java，尤其是 spring 的开发者尤为诸多的原因。

吐槽归吐槽，但我想表明的是在有官方的支持下，用户和开发者能够统一使用某个框架，一起维护与使用一个更好的框架。而不是个个 Web 框架的都有各自的优缺点，让使用者去选择，搞得这个框架是另一个框架的轮子一般。

所以我认为这种支持是很有必要。

公共托管服务​

Project - Deploy (deno.com)

deno 像 vercel/netfily 一样提供了一个代码托管服务，可以将你的 deno 应用部署上去。对，目前来看还无法部署前端应用，因为要指明一个入门文件（main.ts）。

你可以通过 https://kuizuo.deno.dev/ 来访问我使用 deno Deploy 所创建的一个在线项目。将会输出一个Hello World! 的页面。

提供一个免费的线上环境体验，对开发者而言尤为重要，尤其是在将自己的项目成果分享给他人展示时，成就感油然而生。

node 转 deno 开发的一些帮助​

deno 相关的亮点我也差不多介绍完了，也许你对 deno 已经有一丝兴趣想尝试一番，以下我整理的对你也许有所帮助。

• 如果你是一个 Node 用户，考虑切换到 Deno，这里有一个官方小抄来帮助你。

• 如果你不想刷 deno 文档，想快速上手 deno 的话，这里我建议推荐看看 deno 官方所推荐的deno 代码例子 ，能够非常快速有效了直接了解 deno 标准库以及依赖导入导出。

• deno 是集成了 node 与 npm 的，也就是说允许直接使用 npm 包与 node 标准库，如果你想用 deno 来写 node，也行，详看Interoperating with Node.js and npm。

• 想要在 deno 中连接数据库，可看Connecting to Databases。

• 如果想看 deno 如何使用 deno 生态的 Web 框架创建一个 Web 服务，推荐fresh框架，并查看该例子fresh/examples/counter

node 火吗?​

关于 deno 就暂且落下笔墨，不妨思考一个问题，node 火吗。

作为 node 开发者，我肯定会说 node 火，不过更多是对 javascript 来说火。

如今 typescript 大势所趋，说 javascript 就等同于说 typescript，而 javascript 和 node 绑定已成事实，而前端也与 javascript 所绑定，如今的前端工程师要是不会 node，都不好意思说自己是个前端工程师。就现阶段看，没了 nodejs，前端技术得倒退十年（不夸张）。

如果是在 Web 前端，Node 确实已经火的一塌糊涂了，然而它的诞生并不是为了 Web 前端，而是希望将 javascript 作为服务器端语言发展。只是后来没有想到的是 Node.js 在前端领域却大放异彩，造就了如今大前端的盛世。

所以在 Web 后端的领域，Node 确实是不温不火，更多的公司都宁可选主流的后端开发语言，而不是优先考虑 Node。不过倒是在 Serverless 领域中，Node 有着一席之地。

所以我想 deno 的出现，不仅是针对 Node.js 的缺陷，更是针对 Node.js 后端开发的不足。至于说 deno 能否完成原先 node 的使命，只有时间能给我们答案。

总结​

从上述看来，你应该会发现 deno 并不和 node 一样是一个纯运行时环境。因为他不仅仅做了 javascript/typescript 运行时环境，还做了很多开发者好评的功能，一个为 javascript/typescript 提供更好的开发支持的产品。

但好评并不能直接决定销量，这些功能看似可有可无，没有激起用户从 Node.js 切换过来的杰出之处。就我体验完发现，好像 deno 能做的东西 node 大部分也能做，只是相对繁琐重复一些而已。但人们更倾向于做一件繁琐重复的事情，而不是做一个新的事情。

扪心自问，我真的很希望 deno 能火，就开发体验而言，比 node 好用太多了，但好用的东西代表不了用的人就多，这个领域中，生态尤为重要。想要让 node 用户转到 deno 开发还有很长一段路要走。

再来反问自己，我现在会将 deno 作为 node 替代品吗，我想我和多数 node 开发者一样，都不会将 deno 作为主力语言(因为有很多项目都已经使用node来进行开发与推动)。但作为个人开发者，尤其是 node 开发者，我认为还是非常有必要去尝试一番 deno，亲手目睹"下一代Node"。

希望本文能对你了解 deno 有所帮助。

相关推荐文章​

Deno vs. Node.js 哪个更好 - 掘金 (juejin.cn)

为什么 Deno 没有众望所归？超越 Node.js 还要做些什么？ - 掘金 (juejin.cn)

连发明人都抛弃 node.js 了，还有前途吗？ - 知乎 (zhihu.com)

已经 2022 年了 Deno 现在怎么样了? - 知乎 (zhihu.com)

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

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

有关 WebAssembly 不做过多介绍，你可以到 MDN 中查看相关介绍。本文重点于 Rust + WebAssembly 实践与相关工具，在 Rust and WebAssembly (github.com) 或 https://github.com/rwasm 中查看 rustwasm 相关生态。

使用 wasm-pack 打包 rust 为 wasm 文件​

下载 wasm-pack，用于将 rust 代码打包成 .wasm 文件

cargo install wasm-pack

使用 cargo 有可能无法安装 wasm-pack（笔者就安装不了 openssl-sys），可以到 wasm-pack 官网下载对应的二进制文件进行安装。

构建 rust lib​

 cargo new --lib hello-wasm

将会创建 rust 库工程，并创建 src/lib.rs。修改为以下内容（先不必在意代码）

extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    pub fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

接着在 Cargo.toml 文件中添加 wasm-bindgen 依赖，wasm-bindgen 来提供 JavaScript 和 Rust 类型之间的桥梁，允许 JavaScript 使用字符串调用 Rust API，或调用 Rust 函数来捕获 JavaScript 异常。

[package]
name = "hello-wasm"
version = "0.1.0"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"

打包​

wasm-pack build

WebAssembly 构建产物将会输出在 pkg 目录下，如下

├─pkg
|  ├─.gitignore
|  ├─hello_wasm.d.ts
|  ├─hello_wasm.js
|  ├─hello_wasm_bg.js
|  ├─hello_wasm_bg.wasm
|  └─hello_wasm_bg.wasm.d.ts

wasm-pack build --scope mynpmusername

借助 wasm-pack 可以非常轻松的将 rust 打包成 wasm，同时还提供了 js 相关支持。直接打包成 js 可导入的 npm 包，而不是让用户导入 wasm 文件然后通过浏览器 WebAssembly 对象来加载 WebAssembly 代码，其他语言的 WebAssembly 开发也是如此。

此外 rustwasm 还提供了对应的模板 rustwasm/wasm-pack-template，可以帮你省去上面的一系列配置操作，专注于你的 wasm 开发。

运行​

由于上面我们已经将其打包成了一个 npm 包，只需要将配置好 package.json 的依赖即可，本地的话可通过下方格式，将 pkg 目录更改为 hello-wasm，并放置在根目录下。

  "dependencies": {
    "hello-wasm": "file:./hello-wasm"
  },

这时候就可以通过 js 直接导入使用

const js = import("./hello-wasm/hello_wasm.js");
js.then(js => {
  js.greet("WebAssembly");
});

在 vite 生态中有个 rwasm/vite-plugin-rsw 插件，能够在 vite 中快速使用 wasm-pack。下文中的一个应用示例也将采用该插件进行开发。

Rust 实现 MD5 算法​

回到一开始的标题，在实现这个功能我一般会想 js 如何实现 MD5 算法，通常来说 MD5 算法是个比较流行的加密算法，通过搜索引擎能够快速帮我找到一份 js 的 MD5 算法。不过我更习惯通过包管理器导入的加密库，如crypto-js。

同理，在 rust 中可以到 crates.io 中也可以找到你想要的库，如 digest，不过我这里主要是实现 MD5 算法便使用的是 md-5。以下是我的封装代码。

use md5::{Digest, Md5};

fn md5(input: &str) -> String {
    let mut hasher = Md5::new();

    hasher.update(input.as_bytes());

    let result = hasher.finalize();
    format!("{:x}", result)
}

fn main() {
    let result = md5("123456");
    println!("{}", result);
}

然后将这一部分的代码替换到一开始的示例中。

extern crate wasm_bindgen;
extern crate md5;

use wasm_bindgen::prelude::*;
use md5::{Digest, Md5};

#[wasm_bindgen]
pub fn md5(input: &str)-> String {
    let mut hasher = Md5::new();

    hasher.update(input.as_bytes());

    let result = hasher.finalize();
    format!("{:x}", result)
}

此时通过 wasm-pack 将上述代码打包成 npm 包形式即可在 js 中调用 rust 提供的 md5 函数，至此就已经完成了本标题的内容了。

在项目中使用​

这里我所借用 rwasm/vite-plugin-rsw 插件，在 vite 中配合 wasm-pack 进行开发的一个实例。代码部分就不做解读了，有兴趣可自行到翻阅源码：kuizuo/rust-wasm-md5

在线地址：http://rust-wasm-md5.kuizuo.cn （不保证地址长期可用）

思考：为何不使用 js 的 md5 而是 wasm 的 md5​

众所周知，你在浏览器中按下 F12 打开 DevTools，并选择源代码面板中就可以看到当前访问的网站的所有代码。

而对于一些具有熟练度的逆向分析者中，如果不经过任何处理的代码被打包到生产环境中能够快速的定位出某个功能的具体代码位置。

而通过 wasm 就能很有效的将代码隐藏起来，不让逆向分析者查看，就像下面这样

这里我并没有将 md5 更改成不易猜测的名字，你也可自行下断点尝试一番，定位代码。当你定位到具体代码后，就会得到上图的二进制代码格式，几乎无法解读其意思。

不过虽说解读不出 wasm 的原代码（至少目前来说很难反编译成原始代码），但可以通过扣代码的方式来调用 wasm 对外提供的函数（这里为 md5 函数）。

这里仅是 wasm 的一种实际用例，更多情况下应该还是用 Wasm 来提高 web 应用性能的。

相关链接​

编译 Rust 为 WebAssembly - WebAssembly | MDN (mozilla.org)

Rust and WebAssembly

前端入门 ｜ Rust 和 WebAssembly - Rust 精选

rwasm/vite-plugin-rsw: 🦞 wasm-pack plugin for Vite (github.com)

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

现在回头回顾学习编程时间，用一个成语对自己做个评价——差强人意。在这些时间段，我其实荒废过一段时间，厌倦过，贪玩过，荒废过，从我的 Github 热力图 中其实就能看得出来。就导致欠下技术的，都需要后续花时间去弥补。

要让自己保持每天都处于学习状态真的太难了 😩，生活总有源源不断的琐事打扰着你。在忙碌的时候总是感觉时间不够用，哪怕有时一天花费了数十个小时，也总感觉做的事情太少了；哪怕每天计划都规划得好好的，但总是有一半还未完成。生活中大量的碎片化时间，而编程学习最不需要的就是这些碎片化时间。

回顾整个编程生涯有太多可感慨的，整个旅途几乎是一个人走完的，期间遇到的坎坷就只得依靠搜索引擎来解决，搜索引擎是我再生父母都不为过。没有人给我指引明确的道路，只依靠心中对技术的憧憬不断前行。走过低谷，登过山峰，而如今站稳身子就足矣。

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

为什么要写年终总结​

先回答一个问题，为什么要写年终总结？

我从高中开始，每年都会记录这一年所发生的比较有印象的事情并写下自己的感悟。所以写年终算是个人习惯，并且我希望能够一直坚持下去，写到不能写为止。

写年终总结是个非常好的自我总结与反思的方式，总结这一年自身的变化，有哪些精彩与满足，有哪些遗憾和不足。同时定制明年的规划，以该目标不断前行，而不是漫无目的地活着，就失去了很多人生的意义。

同时也算是自我评价与建议，很多时候我们会收到很多别人有关自己的评价与建议，可人总会对他人有莫名的排斥感，就难以虚心听从他人的建议，从而犯错许多（说的是我就对了）。年终总结还有个作用就是弥补自己对某件事情未来可能要发生的情况，要如何做到不犯错，预先有个明确的预防意识。

即便可能要花数天的周期去回顾与总结，我也很愿意去总结，我常说回顾过去，就是在仰望未来。写年终所做的也就是这个过程。

写年终总结也算是种分享，分享自己的开发经历，当他人阅读时或许有所启发。

过去的，就过去了，别将当下的遗憾留到未来，这就是年终的最大意义。

为什么是 Web 开发？而不是逆向​

今年大部分的开发时间都花在 Web 开发上，在此期间也接触到许多技术，并通过博客笔记的方式记录下来。

我很庆幸我的 Web 开发从一个 Beginner 到 Intermediate，现在回忆整个学习路程，一路学得都很野很随意，从未系统学习过，总是学到一半，就自认为已经掌握了，便开始进行实战项目，可以说很多知识都是在实战探索中了解的。

虽然很多人都直称我为大佬，但我离 Advanced 还有一大段的路途要走，而这段路途是无比的艰难与漫长。不过好在路不歪，只要肯走终会到达终点 👨‍🦲。

而带我入门的逆向技术，在今年没有丝毫的长进，说得过分点，就是弃坑了。也正如标题所说，至于缘由，细看下文。

逆向​

熟悉我的人应该知道我之前是做爬虫与逆向分析，但是为何今年的技术栈彻底转型到 Web 开发上。

我常常和别人说起我的技术栈转型（从逆向转到开发），不过比较多的都会比较好奇我为什么不继续深造下去。

在此我也回顾了我从逆向转变到 Web 开发的过程，顺带也回答这个问题。不过在这里先说说我个人对逆向的看法：

逆向需要的技术知识面比较广。​

就我接触逆向的过程来说，接触了易语言，JavaScript，Python，Java，Php 等等编程语言。

使用过了一堆的逆向工具，如 Frida、IDA、JEB、jadx 等等（我目前能想到比较有名的）。此外还有一堆知识，包括但不限于以下技术：自动化脚本、TCP/HTTP 协议、抓包、爬虫、加密学、图像识别（验证码、滑块位置）、汇编、反编译、AST 反混淆。

要我说我在逆向中学到的不是如何使用这些工具或掌握某个技能，而是锻炼出一定的阅读与分析代码能力。工具与技能总是瞬息万变，但阅读与分析代码能力却是实实在在，一成不变的，也是逆向中最值得学习的。

有接触过 CTF 想必再熟悉不过逆向工程的技术面广了。

越来越多的网站或应用程序不断加强安全防护，未来只会越来越难逆向。​

逆向分析，说白话就是去看别人的代码，进行一些修改手段，达到自己想要的目的。比如修改某个软件的标题或作者信息、将别人的代码“偷”过来用、爬取某些网站或软件的数据。

但是随着现在越来越多潜在的安全问题，很多框架底层，服务厂商，都会对一些可能有安全问题的代码进行警告或者底层处理。比如使用 ORM 框架能够有效防止 SQL 注入，前端框架中涉及 XSS 攻击也会有相应的错误提示与处理，再如浏览器跨域以及跨站点 cookie 不共享，都是为了用户的安全而去考虑的。这样的例子有太多了。

简单说说安卓逆向的过程：拿到一个 Apk，发现有加壳（给代码加固让逆向者不易于看到源代码），这时候就需要通过脱壳才能查看到源代码；此时就算脱完了壳，接下来可能将面对经过混淆过的代码，这份代码难以用人眼去阅读，不调试运行，单靠静态分析很难分析出东西，这时候可能就要借助 AST 对代码进行还原；还原完了配合动静分析将代码给扣出来，而在分析的时候可能又有各种检测，比如抓包，反调试以阻碍逆向进度；最后就算逆向工作都做完了，代码也扣下来了，还要尝试运行扣完的代码，这时候极大可能还不一定能运行，然后又要回头看看到底那一步做错了。

可以说逆向的工作就是不断地调试，不断分析，最终拿到想要的结果。整个过程可以说非常耗时且折磨人，心智如果不够强大，真的容易劝退（我当下耐心也早不如当初了）。但是得到最终的目的，将非常爽，成就感爆棚，相当于一个解了几小时的题，最终被攻克的感觉。

前阵子在逆向圈中，看到过一张图，大致也把我的逆向学习流程也表达了出来，最终我的逆向学习也确实止步在 Flutter 上。

上面所说到的逆向技术中，例如加壳，代码混淆，反调试，风控等等，都是阻碍逆向手段。同样对于爬虫而已，通常会采取反爬措施，包括但不限于封 IP、封账号、JS 参数加密、代码混淆、浏览器指纹、TLS 指纹、验证等。而且防护手段可以说是越来越多，逆向的难度也就越来越大。并且在服务开发那边只需要修改一点东西，逆向可能就需要从头再来一遍。

未来逆向的难度只增不减，但薪资可不一定保证这趋势。

风险​

从上面也不难看出逆向常常与安全挂钩，如果一个网站或软件不是那么好被逆向，那么间接说明安全性是比较高的。可一旦涉及到安全，同时又是互联网，就免不了网络安全与法律相关的风险。

在大多数逆向的对象（网站，软件）中，多数都是他人的劳动产物，当你未经他人允许的情况下，去爬取他人的数据，或是修改一些版权信息再次发布出来，就属于非法行为。本质和未经他人允许，偷人家的东西性质是一个样的。并且在有防护措施的情况下，绕过网站防护措施获取数据属于违背权利人意愿读取、收集数据，将有较大可能被认定为对计算机信息系统的 “侵入”。

要知道在逆向的行业中，有很多都是擦边灰产，至少我所在的逆向圈是这样的，抱着【仅供学习为参考，请勿用于非法用途】的想法做逆向工程。路子极易走歪，很少能够正常去走安全岗位的。相信你应该能看到许多类似的案件，如【某某程序员因非法侵入 xx 网站，获刑 x 年】。这不是危言耸听，目前国家对网络安全以及非法数据获取的打击力度，也将决定了这些案件将会越来越多，爬虫逆向也将会越来越邢。

自身因素​

简单介绍完我认为爬虫和逆向的看法后，再来说说自身因素。

更想写代码，而不是看代码​

我是很享受写代码的过程，一份高质量的代码会让人赏心悦目。我为此特意学习下设计模式、重构技巧以及 TDD 测试。这些在逆向中基本难以涉及，但是这些对开发的体验和代码的健壮性都是非常重要的，也是让我个人觉得技术有所提升的技能点。

在逆向分析中，大部分时间都不是在写代码而是在看（分析）代码，而反编译出来的代码，很有可能是带有混淆过的代码，而你想要分析这一块代码的作用，只能去一步步调试，将代码啃下来，从而推断运行时某变量的值，或是某个函数的作用。

虽然说开发岗位中，有很多情况下也是在看代码的日子中度过的，但相比反编译阅读代码而言，至少不至于那么晦涩难懂。

更想碰新技术，而不是旧技术​

其次，在逆向分析中，遇到的网站或软件所用的技术一般都是较为稳定成熟的技术，而这些技术往往不是很新，因此需要去了解很多旧的技术，但这些旧技术仅仅只对逆向分析有用，甚至过段时间很有可能就会遗忘。并且要了解的旧技术还不少，学得将会特别杂。

而我又是一个喜新厌旧的人，对任何新鲜事物都抱有好奇尝试的态度。我终将认为旧的技术被淘汰是迟早的问题，新技术的出现肯定不是无缘无故的出现，必然是为了解决某些问题而诞生的，如性能，开发体验，安全等等。

这里有篇我对新技术的看法，推荐阅读一番。[深谈个人对新技术的看法 - 愧怍的小站 (kuizuo.cn)](https://kuizuo.cn/talk-new-technologies-opinion'深谈个人对新技术的看法 - 愧怍的小站 (kuizuo.cn)')

更想开源，而不是闭源​

在逆向开发，不，是在灰产开发中，有很多代码是别指望开源出来的，这背后会涉及到商业利益或是版权等问题。一旦代码放出来，将意味着你的代码将有很大的可能被别人利用做坏事，最终甚至祸及到自己。所以大多数情况下，你多半只能将自己的应用发布出去，而不是将源码开源，通常也就带有商业化的性质。

我想任何开发者肯定是希望自己的代码走的更远，走的正规，而不是被拿来做违背自身意愿的事情。

开源不仅能为自己提升一些技术知名度，展现自身技术的一面，同时代码被他人使用与认可，这番成就感就足够继续坚持开源下去。因为我有很多技术都是通过开源项目中学到的，所以我能感受到开源带来的魅力，也是对于前人的崇拜，想走开源的原因。

因为淋过雨，所以很想为别人撑把伞

小结​

其实在今年出头我还特意复习了一波安卓逆向，为了更深入了解了更底层的知识与工具（当然现在忘得也差不多了），因一些特殊原因我的电子设备不在了，别问，问就是坏了到现在还没修好。就导致我的编程语言环境，逆向工具，虚拟机配置，代码等数据直接灰飞烟灭，也让我停滞了 1 个月的学习。

我想这才是我从逆向转 Web 开发的最重要的理由了。

逆向的学习对我开发有很大的帮助。例如开发中的安全问题，我在开发中都会时刻考虑去考虑该问题。如加壳、SQL 注入、代码混淆、接口限流、接口幂等性（Fiddle R 包）等等安全性问题。

我庆幸我学过逆向，让我学到很多在开发中比较难学到的技能，如调试，阅读源码，而这些也是绝大多数 Web 开发者都欠缺的能力。

逆向应该就暂以告终，未来会有很长的一段时间，甚至以后不再接触深入专研逆向。

每当回想，【当时那么难的加密算法都能搞得定，开发一个功能还能有多难】，保持着这种心态，也让我保持着开发。

也是逆向激起我对编程的兴趣，可以说没有接触逆向开发，我也不太可能会接触到 Web 开发。

但 Web 开发就一定好吗？​

上面对逆向的看法仅个人分析而言，但是 Web 开发就一定好吗？我不敢下绝对的肯定，不同人不一定适合相同的技术，但是我特别看好 Web 技术（尤其是 JavaScript，偏前端向），以下是我看好的点。

应用性广​

目前仍有很多人还停留在 JavaScript 只能编写前端页面的水平，自从 Node.js 问世，目前绝大多数的应用都可以使用 JavaScript 进行编写。

换句话说，只要你会 JavaScript 就可以编写很多应用了。有个在国外经常被应用的一条和 JavaScript 有关系的著名定律：

Atwood 定律：任何可以用 JavaScript 编写的应用程序，最终都会用 JavaScript 编写

Web 前端开发不用多说，目前还得用 JavaScript 来编写。而后端开发通过 Node.js 也有一己之力。近几年特别流行跨平台开发，也就是一份代码，多端运行。

使用 React Native 或是 Uniapp 这样的前端应用框架，顺带去了解一下相应平台的 API，就能够编写出安卓或 IOS 应用，做过小程序开发肯定知道小程序的技术栈就使用到前端开发的技术栈，如果你会前端开发，就能很轻松的上手小程序开发了。

并且越来越多的软件都是网页版优先，然后再通过 Electron 这样的跨平台解决方案，实现不同平台间的程序。诸如 Vscode，Typeorm 等等便是其中的佼佼者。

不过本质上都是在不同应用的平台上套浏览器的壳，然后接入一些该平台的接口，因此普遍应用的体积与内存都相对比较大，与原生相比自然是略逊与原生，不过这点性能上的差异在如今硬件升级如此普遍的物质生活也显得微不足道了。

但借助浏览器自带的跨平台性，你所编写的应用能够非常轻松的让他人访问，只需要用户有个浏览器，并且通过上述跨平台的解决方案，也能够有效的将你的 web 应用转成其他平台的应用，而不是在耗费时间与精力去编写另一套代码。

在一些技术文档上，会有 API/SDK 的支持，而绝大多数都支持使用 JavaScript/Node.js，也许该功能本身并不是使用 JavaScript 来编写的，但完全可以通过 JavaScript 来轻松调用该功能。并且如今 JavaScript 生态如此庞大，你不必担心库/包的问题，npm 作为世界上最大的开放源代码的生态系统（包管理器），在这里你几乎找得到你所想要的库/包。

此外有越来越多的第三方服务平台（通常称 Fass，函数即服务），专门提供数据接口与用户鉴权，如 firebase/supabase 或是国产的云开发产品（如小程序）。前端程序员只需要专注与业务代码，借助第三方开发平台，就能够编写一个高可用的应用。反而也映衬了，Web 开发好像可以没有后端，但必须要有前端的观念。

工作量将越来越多​

这句话的意思可能有点加班那味道，但我所要表明的是可以做的事情多了，意味着你的工作量增加了，同时你的编码价值也就提升了，不过实际价值（工资）的话不一定提升，因为这主要看老板和地区。

怎么理解呢，我举几个例子。

现在大部分的 web 应用都采用前后端分离的形式，但在曾经则是由后端通过模板语言渲染成 HTML 直接返回，通过前后端分离的形式，前端只需要专注页面交互的编写，而后端只需要保证接口可靠性。并且前后端分离也有一个特别显著的特点，能非常有效的节省服务器的资源，原本服务器的渲染动作迁移至客户端来做。也许有人会说，那这样 SEO 优化该怎么办，这不就有了 Next.js、Nuxt.js 这样的 SSR（服务端渲染） 框架，而这些工作，也是前端要做的。

并且越到后面你越能感觉到客户端（前端）远比服务端（后端）做的东西来的多，比如开发阶段的数据 Mock，前端国际化，设计原型等等。之所以会有这种感觉，也许是因为我的大部分开发都是前端，这里你也可以回想当下的工作量与往年相比是多了还是不变。

技术更新快​

前端真的是每隔一段时间，必定会出一些新的技术，也不由让不少前端学习者感叹真的学不动。但伴随着新的技术出现，必然会有新的岗位与机会，这也是我看好前端的一个点。

不过这种机会在国内不太多见，反而在国外特别普遍。 多的不说，自行体会。

忘记从哪看到的一句话：“前端工程师的一大焦虑：永远能（且必须要）看到大量前沿的技术，但自己手上的活儿跟不上，导致眼高手低。”

不只是前端，做技术这行的，必须要跟着技术发展的角度，并且要时刻关注最新，主流的技术。

有关 Web 开发的一些想法与感悟就写到这，其实还有蛮多可写的，比如选择 Vue 与 React？为什么是 JavaScript？有太多自我审问的话题了，不过由于当下时间相对紧迫，有机会的话再续写吧。

综上，也就是我看好 Web 技术的几个点，也回答了我未来的方向。希望这些能够帮助一些不知抉择方向的伙伴。

在实践中学习​

回顾整个技术栈，基本都是在项目实践中不断学习。也许是因为逆向的缘故，因为逆向基本上都是靠实战出来的，导致我的学习路线也趋于实践。

不过在我看来，写项目是最直接能体现出所想学的技术。我在学习一门新技术时，我通常会用项目或者博文的形式来总结我的学习过程。我也乐意花时间在这上面，并将其分享出来。当有其他人也在学习这门技术时，看到该项目或博文，我就认为非常有意义。

我在学任何一门技术，会使用该技术写点东西；换言之是为了写点东西，而去学点不一样技术。

技术心态的变化​

如今来看，确实没那么想写代码，尤其是那种工作量大，重复性强的代码，而编写这些代码，其实与搬砖无任何区别，本质也是重复性与劳动性的任务。

曾经可能是因为接触得比较少，对于很多软件背后的原理及实现一概不知，所以看到啥就都想写写看，最终很多项目都成为半成品。

而随着越深入的学习，反而自己所想实现的东西，前人都已经帮我们实现好了。完全可以借用前人的代码，在此基础上学习与使用，而不必从头再来，耗费很多不必要的时间。

到最后为了实现一开始所想实现的东西，不用再费尽心思，去开源社区搜寻一番，总能找到与自己所要实现的类似的产品，此时只需要会看，会改，总能达到自己最终要实现的东西，有时候自己也称为了别人口中的 CV 工程师。

也正因如此，写代码的欲望就不再那么强烈。很多自认为无意义的代码或者是以后都不一定用得上的代码就少写了许多。于是乎缺少了很多自我思考与专研的时间，虽说也确实节省了很多不必要的时间，加快最终功能的实现，但这就是自己想要的编程生活吗？或者说这就是绝大多数人的编程生活。

何来的自驱力​

现在回想，是什么驱使我学习，我心中的答案是无能。

当你什么都不会时，或者是目前的能力还不足够将某件事情做好，你就会不断地焦虑，犹如热锅上的蚂蚁，想做但又怕做不好。

我有很多社会技能是欠缺的，比如人际交往，谈话技巧，合作行为等等，并且我本身也不愿去学习这些技能。正因如此，只有不断发挥自身长处，用自己所擅长的领域弥补自己的短板，以提升自我在社会的竞争力，以至于不那么容易被淘汰。

返校的一年​

今年也是我重归学校的一年，倘若，去年没有休学一年的话，如今我可能已经在外实习了，转瞬一年就过去了，如今的我还沉浸在当初休学和别人创业工作的日子。

也是因为当时休学急迫，后事做得并未完善，学校的一些课程并未申请缓考，最终视为缺考，即挂科。然后此前对大学的课程也是抱着可有可无的心态，也挂了几门课程，如果不是辅导员告知，我还有 34 学分要补（20 学分为严重预警，40 学分为退学或降级处理），我都不曾了解自己在学校挂了这么多科 😂。最离谱的是有个同班同学正好就被降级处理了，不过好在今年上半年并未挂科，加上下半年也重修了一些课程，还不至于离本科毕业证书越走越远。

回到学校后，就感觉如同坐牢一般，只不过环境相对舒适一番，尤其是在疫情当下更是如此，我这一年出校玩乐的次数好像不超过 10 次。当我仔细回想一下大学的真正意义是什么？貌似就是混个日子，混个证书。我也想不出大学能够有什么实质性的作用，也许是因为我所处的学校不行，换个好一点的大学或许都不是这样了。

不过今年回学校反而去参加了曾经都不怎么看上的社团（虽然现在也差不了多少），给社团写了些项目，主要也为了给自己重返学校带点个人知名度。但因为学校不是那么有名（臭名可能有），所以这里就不便放上相关信息。

考研​

明年的话我就大三下了，面对我的有条熟知的考研路。说实话，从目前来看，我对考研不抱有太大的希望，我是属于实践派的那种，我坚信没有什么是试不出来。背理论，刷八股，我很反感。

不知道由于什么原因，总感觉一段时间不写代码，真的就不会写代码。仿佛与自己写的代码成为了陌生人一般（所以写注释的重要性就体现出来了）

倘若读研的话，必然将会有数个月的时间重心不在代码上，到时候回来编写代码时，又发现自己好像又重新学了一遍似的。加之万一上岸失败的心理落差，会让自我觉得这几个月的努力都白费。而我又恰好是一位结果论者，即只在意结果，不在意过程如何。在别人的眼中，是难以看到你考研备战努力的过程，只会在意你上没上岸。这便是我不想考研因素之一。

但今年在互联网上所认识伙伴中挺多给我过于高的评价，都认为我作为一个学生，能有这水平是不是在某某牛逼的高校读书。然而并不是，我甚至都不好意思述说自己的高校，感觉是当下的污点。也正因如此反而让我有点过于焦虑，就从身份上，这不得让我萌生读研的一丝丝想法，也不至于死绝考研。

自我认为离真正的大佬还差很长的一段距离，我只是靠着三分钟热度，加上爱折腾，才维系下去，而那些真正的大佬是肯花费大量时间去编写他们所认为有意义的代码。

结语​

今年的年终就告一段落，与之前的年终总结相比，篇幅缩减了许多，主要感觉之前写的挺多流水账的，废话挺多的。也有一点是因为时间相对紧迫，其实 12 月我还没放假，都处于线上上课，线上考试的状态，而线上考试的方式我就不得吐槽了，提前打印给定的答题纸，题目以电脑的方式展示，最终将答案手写到答题纸上并通过手机扫描（扫描全能王）成 PDF 的格式提交，当然摄像头必然也是有的。总之麻烦事还是有的，还没到彻底闲下来闭关学习的时候。

按往常可能还有明年的规划，但我现在认为很多时候都难以依照自身意愿做事，而规划正好自己所设想美好的计划，很容易事与愿违。因为回顾过往的规划，有太多美好的计划，但在实际分析下也将变得不堪一击。不止项目需要可行性分析，人生计划同样需要，一些天马行空幻想，其实就不再有意义去记录了。

坚持做自己想做的事情，而不是逼自己做不愿做的事情。这是我编程学习中座右铭，也是给予他人编程学习的建议。

写于2022年12月22日 By 愧怍

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

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

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

关于 GraphQL 介绍，详见官网 GraphQL | A query language for your API 或相关介绍视频 GraphQL 速览：React/Vue 的最佳搭档

GraphQL 与 Restful API 相比​

Restful API​

Restful 架构的设计范式侧重于分配 HTTP 请求方法（GET、POST、PUT、PA TCH、DELETE）和 URL 端点之间的关系。如下图

但是实际复杂的业务中，单靠 Restful 接口，需要发送多条请求，例如获取博客中某篇博文数据与作者数据

GET /blog/1

GET /blog/1/author

要么单独另写一个接口，如getBlogAndAuthor，这样直接为调用方“定制”一个接口，请求一条就得到就调用方想要的数据。但是另写一个getBlogAndAuthor 就破坏了 Restful API 接口风格，并且在复杂的业务中，比如说还要获取博文的评论等等，后端就要额外提供一个接口，可以说非常繁琐了。

有没有这样一个功能，将这些接口做一下聚合，然后将结果的集合返回给前端呢？在目前比较流行微服务架构体系下，有一个专门的中间层专门来处理这个事情，这个中间层叫 BFF（Backend For Frontend）。可以参阅 BFF——服务于前端的后端

但这些接口一般来说都比较重，里面有很多当前页面并不需要的字段，那还有没有一种请求：客户端只需要发送一次请求就能获取所需要的字段

有，也就是接下来要说的 GraphQL

GraphQL​

REST API 构建在请求方法（method）和端点（endpoint）之间的连接上，而 GraphQL API 被设计为只通过一个端点，即 /graphql，始终使用 POST 请求进行查询，其集中的 API 如 http://localhost:3000/graphql，所有的操作都通过这个接口来执行，这会在后面的操作中在展示到。

接下来便会在客户端中体验下 GraphQL，看看 GraphQL 究竟有多好用。

在线体验 GraphQL​

可以到 官网 中简单尝试入门一下，在 Studio 可在线体验 GraphQL，也可以到 SWAPI GraphQL API 中体验。

下面以 apollographql 为例，并查询 People 对象。

query​

查询所有 People 并且只获取 name、gender、height 字段

查询 personID 为 1 的 Person 并且只获取 name，gender，height 字段

查询 personID 为 2 的 Person 并且只获取 name，eyeColor、skinColor、hairColor 字段

从上面查询案例中其实就可以发现，我只需要在 person 中写上想要获取的字段，GraphQL 便会返回带有该字段的数据。避免了返回结果中不必要的数据字段。

{
    person{ 
        # 写上想获取的字段 
    }
}

如果你不想要 person 数据或者想要其他其他的数据，不用像 Restful API 那样请求多条接口，依旧请求/graphql，如

mutation​

GraphQL 的大部分讨论集中在数据获取（也是它的强项），但是任何完整的数据平台也都需要一个改变服务端数据的方法。即 CRUD。

GraphQL 提供了 变更(Mutations) 用于改变服务端数据，不过 apollographql 在线示例中并没有如 createPeople 字段支持 。这个片段在线体验中就无法体验到，后在后文中展示到。这里你只需要知道 GraphQL 能够执行基本的 CRUD 即可。

fragmen 和 subscribtion​

此外还有 fragment 与 subscription 就不做介绍。

小结​

尝试完上面这些操作后，可以非常明显的感受到 GraphQL 的优势与便利，本来是需要请求不同的 url，现在只需要请求 /graphql，对调用方（前端）来说非常友好，香是真的香。

可目前只是使用了别人配置好的 GraphQL 服务，让前端开发用了特别友好的 API。但是，对于后端开发而言，想要提供 GraphQL 服务可就不那么友善了。因为它不像传统的 restful 请求，需要专门配置 GraphQL 服务，而整个过程是需要花费一定的工作量（定义 Schema，Mutations 等等），前面也提到想要一条请求就能得到客户端想要的数据字段，那服务端必然需要额外的工作量。

不仅需要在后端中配置 GraphQL 服务，用于接收 GraphQL 查询并验证和执行，此外前端通常需要 GraphQL 客户端，来方便使用 GraphQL 获取数据，目前实用比较多的是Apollo Graph，不过本文侧重搭建GraphQL 服务，因此前端暂不演示如何使用 GraphQL。

你可能听过一句话是，graphq​l 大部分时间在折磨后端，并且要求比较严格的数据字段，但是好处都是前端。把工作量基本都丢给了后端，所以在遇到使用这门技术的公司，尤其是后端岗位就需要考虑有没有加班的可能了。

以下便会开始实际搭建 GraphQL 服务，这里会用 Nest.js 与 Strapi 分别实践演示。

Nest.js​

官方文档：GraphQL + TypeScript | NestJS

模块：nestjs/graphql

仓库本文实例代码仓库： kuizuo/nest-graphql-demo

创建项目

nest new nest-graphql-demo

安装依赖

npm i @nestjs/graphql @nestjs/apollo graphql apollo-server-express

修改 app.module.ts

import {Module} from '@nestjs/common';
import {GraphQLModule} from '@nestjs/graphql';
import {ApolloDriver, ApolloDriverConfig} from '@nestjs/apollo';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: true,
    }),
  ],
})
export class AppModule {}

resolver​

设置了autoSchemaFile: true ，nest.js 将会自动搜索整个项目所有以 .resolver.ts 为后缀的文件，将其解析为 schema.gql 比如说创建app.resolver.ts

import {Resolver, Query} from '@nestjs/graphql';

@Resolver()
export class AppResolver {
  @Query(() => String) // 定义一个查询,并且返回字符类型
  hello() {
    return 'hello world';
  }
}

在 graphql 中 resolver 叫解析器，与 service 类似（也需要在 @Module 中通过 providers 导入）。resolver主要包括query(查询数据)、mutation(增、删、改数据)、subscription(订阅，有点类型 socket)，在 graphql 项目中我们用 resolver 替换了之前的控制器。

这时候打开http://127.0.0.1:3000/graphql，可以在右侧中看到自动生成的 Schema，这个 Schema 非常关键，决定了你客户端能够请求到什么数据。

尝试输入 GraphQL 的 query 查询（可以按 Ctrl + i 触发代码建议（Trigger Suggest），与 vscode 同理）

此时点击执行，可以得到右侧结果，即app.resolver.ts 中 hello 函数所定义的返回体。

Code first 与 Schema first​

在 nestjs 中有 Code first 与 Schema first 两种方式来生成上面的 Schema，从名字上来看，前者是优先定义代码会自动生成 Schema，而后者是传统方式先定义Schema。

在上面一开始的例子中是 Code First 方式，通常使用该方式即可，无需关心 Schema 是如何生成的。下文也会以 Code First 方式来编写 GraphQL 服务。

也可到官方示例仓库中 nest/sample/31-graphql-federation-code-first 和 nest/sample/32-graphql-federation-schema-first 查看两者代码上的区别。

快速生成 GraphQL 模块​

nest 提供 cli 的方式来快速生成 GraphQL 模块

nest g resource <name>

比如创建一个 blog 模块

nest g resource blog --no-spec
? What transport layer do you use? GraphQL (code first)
? Would you like to generate CRUD entry points? Yes
CREATE src/blog/blog.module.ts (217 bytes)
CREATE src/blog/blog.resolver.ts (1098 bytes)
CREATE src/blog/blog.resolver.spec.ts (515 bytes)
CREATE src/blog/blog.service.ts (623 bytes)
CREATE src/blog/blog.service.spec.ts (446 bytes)
CREATE src/blog/dto/create-blog.input.ts (196 bytes)
CREATE src/blog/dto/update-blog.input.ts (243 bytes)
CREATE src/blog/entities/blog.entity.ts (187 bytes)
UPDATE src/app.module.ts (643 bytes)

便会生成如下文件

import {Resolver, Query, Mutation, Args, Int} from '@nestjs/graphql';
import {BlogService} from './blog.service';
import {Blog} from './entities/blog.entity';
import {CreateBlogInput} from './dto/create-blog.input';
import {UpdateBlogInput} from './dto/update-blog.input';

@Resolver(() => Blog)
export class BlogResolver {
  constructor(private readonly blogService: BlogService) {}

  @Mutation(() => Blog)
  createBlog(@Args('createBlogInput') createBlogInput: CreateBlogInput) {
    return this.blogService.create(createBlogInput);
  }

  @Query(() => [Blog], {name: 'blogs'})
  findAll() {
    return this.blogService.findAll();
  }

  @Query(() => Blog, {name: 'blog'})
  findOne(@Args('id', {type: () => Int}) id: number) {
    return this.blogService.findOne(id);
  }

  @Mutation(() => Blog)
  updateBlog(@Args('updateBlogInput') updateBlogInput: UpdateBlogInput) {
    return this.blogService.update(updateBlogInput.id, updateBlogInput);
  }

  @Mutation(() => Blog)
  removeBlog(@Args('id', {type: () => Int}) id: number) {
    return this.blogService.remove(id);
  }
}

此时 Schema 如下

不过nest cli创建的blog.service.ts 只是示例代码，并没有实际业务的代码。

此外blog.entity.ts也不为数据库实体类，因此这里引入typeorm，并使用sqlite3

集成 Typeorm​

安装依赖

pnpm install @nestjs/typeorm typeorm sqlite3

import {Module} from '@nestjs/common';
import {AppController} from './app.controller';
import {AppService} from './app.service';
import {GraphQLModule} from '@nestjs/graphql';
import {ApolloDriver, ApolloDriverConfig} from '@nestjs/apollo';
import {AppResolver} from './app.resolver';
import {BlogModule} from './blog/blog.module';
import {TypeOrmModule} from '@nestjs/typeorm';

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type: 'sqlite',
      database: 'db.sqlite3',
      entities: [__dirname + '/**/*.entity{.ts,.js}'],
      synchronize: true,
    }),
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: true,
      playground: true,
    }),
    AppModule,
    BlogModule,
  ],
  controllers: [AppController],
  providers: [AppService, AppResolver],
})
export class AppModule {}

将 blog.entity.ts 改成实体类，代码为

import {ObjectType, Field} from '@nestjs/graphql';
import {
  Column,
  Entity,
  PrimaryGeneratedColumn,
  CreateDateColumn,
  UpdateDateColumn,
} from 'typeorm';

@ObjectType()
@Entity()
export class Blog {
  @Field(() => Int)
  @PrimaryGeneratedColumn()
  id: number;

  @Field()
  @Column()
  title: string;

  @Field()
  @Column({type: 'text'})
  content: string;

  @Field()
  @CreateDateColumn({name: 'created_at', comment: '创建时间'})
  createdAt: Date;

  @Field()
  @UpdateDateColumn({name: 'updated_at', comment: '更新时间'})
  updatedAt: Date;
}

其中 @ObjectType() 装饰器让 @nestjs/graphql 自动让其视为一个 type Blog

而 @Field() 则是作为可展示的字段，比如 password 字段无需返回，就不必要加该装饰器。

为 BlogService 编写 CRUD 数据库业务代码，并在 dto 编写参数效验代码，这里简单暂时部分代码。

import {Injectable} from '@nestjs/common';
import {InjectRepository} from '@nestjs/typeorm';
import {Repository} from 'typeorm';
import {CreateBlogInput} from './dto/create-blog.input';
import {UpdateBlogInput} from './dto/update-blog.input';
import {Blog} from './entities/blog.entity';

@Injectable()
export class BlogService {
  constructor(
    @InjectRepository(Blog)
    private blogRepository: Repository<Blog>,
  ) {}

  create(createBlogInput: CreateBlogInput) {
    return this.blogRepository.save(createBlogInput);
  }

  findAll() {
    return this.blogRepository.find();
  }

  findOne(id: number) {
    return this.blogRepository.findOneBy({id});
  }

  async update(id: number, updateBlogInput: UpdateBlogInput) {
    const blog = await this.blogRepository.findOneBy({id});
    const item = {...blog, ...updateBlogInput};
    return this.blogRepository.save(item);
  }

  remove(id: number) {
    return this.blogRepository.delete(id);
  }
}

import {InputType, Field} from '@nestjs/graphql';

@InputType()
export class CreateBlogInput {
  @Field()
  title: string;

  @Field()
  content: string;
}

此时

CRUD​

下面将演示 graphql 的 Mutation。

新增​

修改​

删除​

Query 就不在演示。

小结​

至此，在 Nest.js 中配置 GraphQL 服务的就演示到此，从这里来看，Nest.js 配置 GraphQL 服务还算比较轻松，但是做了比较多的工作量，创建 resolver，创建 modal（或在已有实体添加装饰器），不过本文案例中只演示了基本的 CRUD 操作，实际业务中还需要涉及鉴权，限流等等。

Strapi​

Strapi 官方提供 GraphQL 插件 免去了配置的繁琐。更具体的配置参见 GraphQL - Strapi Developer Documentation

这里我就选用 kuizuo/vitesse-nuxt-strapi 作为演示，并为其提供 graphQL 支持。

strapi 安装

npm install @strapi/plugin-graphql

接着启动 strapi 项目，并在浏览器打开 graphql 控制台 http://localhost:1337/graphql，以下将演示几个应用场景。

例子​

查询所有 todo​

查询 id 为 2 的 todo​

查询 id 为 2 的 todo 并只返回 value 属性​

新增 todo​

更新 todo​

删除 todo​

由于 Nuxt Strapi 提供 useStrapiGraphQL 可以非常方便是在客户端调用 GraphQL 服务。

<script setup lang="ts">
  const route = useRoute();
  const graphql = useStrapiGraphQL();

  // Option 1: use inline query
  const restaurant = await graphql(`
  query {
    restaurant(id: ${route.params.id}) {
      data {
        id
        attributes {
          name
        }
      }
    }
  }
`);

  // Option 2: use imported query
  const restaurant = await graphql(query, {id: route.params.id});
</script>

小结​

对于 Strapi 来说，搭建 GraphQL 服务基本没有配置的负担，安装一个插件，即可配合 Strapi 的 content-type 来提供 GraphQL 服务。

总结​

GraphQL 翻译过来为 图表 Query Language，我所理解的理念是通过 json 数据格式的方式去写 SQL，而且有种前端人员在写 sql 语句。在我看来 GraphQL 更多是业务数据特别复制的情况下使用，往往能够事半功倍。但对于本文中示例的代码而言，GraphQL 反倒有点过于先进了。

如今看来，GraphQL 还处于不温不火的状态，目前更多的站点主流还是使用 Restful API 架构。我不过我猜测，主要还是大多数业务没有 API 架构的升级的需求，原有的 Restful API 虽说不够优雅，但是也能够满足业务的需求，反而 GraphQL 是一个新项目 API 架构的选择，但不是一个必须的选择。

至于如何选择，可以参阅官方 GraphQL 最佳实践，至于说有没有必要学 GraphQL，这篇文章 都快 2022 年了 GraphQL 还值得学吗 能给你答案。我的建议是了解即可，新项目可以考虑使用，就别想着用 GraphQL 来重构原有的 API 接口，工作量将会十分巨大，并且还可能是费力不讨好的事。反正我认为这门技术不像 Git 这种属于必学的技能，我的五星评分是⭐⭐

但多了解一门技术，就是工作面试的资本。回想我为何尝试 GraphQL，就是因为我无意间看到了一份 ts 全栈的远程面试招聘，在这份招聘单中写到 【会 graphql 编写是加分项】。所以抱着这样的态度去尝试了一番，说不准未来就是因为 graphql 让我拿到该 offer。当然也是因为很早之前就听闻 GraphQL，想亲手目睹下是否有所谓的那么神奇。

kz-admin 使用 NestJs + TypeScript + TypeORM + Redis + MySql + Vben Admin 等技术栈，并采用 monorepo 管理项目，希望这个项目在 ts 全栈的路上能够帮助到你。

详细介绍可以参见 kz-admin后台管理系统

为何重构​

前段时间基于我的 kz-admin 模板写了一个link-admin的项目（可以访问 link.kuizuo.cn 在线体验，账号 admin，密码a123456），是一个“一次性”充值链接管理系统，具体自行体验即可（项目未开源）。

该项目有前端管理页面，后端服务，和一个链接使用页面，共三个项目。

每次启动时候，都需要进入到对应项目下，打开终端，输入命令。要么使用npm-run-all 来批量执行 dev 与 build 命令。

想到后续项目的应用场景大概率也可能是多项目的，于是就准备使用 turborepo 将项目重构为 monorepo 管理，将前后端项目都统一放到一个仓库中，并且将 nestjs 版本升级到 v9，顺便在完善一下api接口文档，并提供 ApiFox 文档。

monorepo重构​

monorepo的重构相对简单，首先使用 Turborepo 新建一个 monorepo 的仓库，目录结构如下

将 packages 与 apps 下的文件清空，然后把原 kz-admin 的前端项目与后端项目放到 apps 下。修改下 README.md 与 package.json 其启动命令即可。

依赖升级​

我原先的nestjs依赖是8.0.0，但是技术发展太快，nestjs 9.0.0都已经发布了，所以这次更新属于大版本更新，通常属于破坏性更新，可能会导致原代码失效，所以更新依赖要慎重。

我使用的是antfu/taze 来更新依赖，也可以使用 yarn upgrade-interactive -- latest。

npx taze -r

由于此次属于大版本更新，所以使用taze major，小版本则使用 taze minor。

npx taze major -r -w 将更新依赖写入到package.json下，接着执行pnpm i更新依赖即可。

既然都将nestjs更新了，那么nestjs相关生态的库自然也是要更新的，于是就遇到的typeorm 0.2.0 → 0.3.0用法的问题，主要是将findOne等方法改写，如 findOne(id) → findOneBy({ id }) 。整个过程还算顺利，

使用ApiFox编写接口文档与接口测试​

在原项目中我Swagger写的其实够完善，但是在代码协同上只给前端一个Swagger地址不是很友好。但直到我接触并体验一段时间ApiFox后，让我更想去编写Swagger，给前端同事一个良好的Api接口测试体验，因为我自身也作为前端开发者，我太清楚API接口文档的重要性了。

其实早听闻ApiFox，但当时我还在用ApiPost，觉得ApiPost足够好用就没有更换的欲望。直到看到别人给我分享用ApiFox编写的接口文档时，让我眼前一亮，至于有多好用，可以参阅官方的介绍视频21分钟学会Apifox。发自使用者内心的好用，下面会有些实际接口案例来说明到底有多好用。

你可以访问 https://admin.kuizuo.cn/swagger-ui 来查看kz-admin的Swagger文档

json格式为https://admin.kuizuo.cn/swagger-ui/json，用于导入ApiFox中。

ApiFox在线链接: https://www.apifox.cn/apidoc/shared-7a07def2-5b82-4c71-bf57-915514f61f25 访问密码: kz-admin

数据实体​

本次重构对于数据实体花费的时间比较多，主要就是数据实体重命名，如

• CreateUserDto → UserCreateDto

• UpdateUserDto → UserUpdateDto

• DeleteUserDto → UserDeleteDto

• PageUserDto→ UserPageDto

• ...

将操作动词后置，这样做好处就是不用从一堆CreatxxxxDto中找一个CreateUserDto，而是转变成从几个UserxxxxDto找UserCreateDto，就像下图这样，左侧Swagger，右侧ApiFox，在数据实体比较多的时候显示的会更加直观。

当然在ApiFox中可以通过搜索来筛选模型，但在开发体验方面，我认为此次重命名重构还是非常有必要的。

定义数据实体（Schemas）非常重要，这样我们就能知道该请求接口应该传递什么参数，会接收到什么样的数据。

接口文档​

Apifox是以文档作为驱动的，可以说把Swagger文档写好，Apifox就会好用。直接上例子

以用户新增和分页查询用户为例，直接上效果图（左侧是ApiFox，右侧为Swagger代码）

在定义完Swagger并通过ApiFox导入后，不用修改ApiFox就能得到上述效果。这里强烈建议将ApiFox接口问题，与nestjs的Swagger代码进行对比，就能体会到写好Swagger就能得到一份如此优雅的Api文档。

做前端和做后端看到这文档，这不得发自内心的赞美。

了解更多​

此外 ApiFox 的好处远远不止于此，篇幅有限，好东西不是一句两句就能说明白的东西，建议自行体验一番，绝对会有不一样的收获。

回顾项目​

Vben admin 是我21年6月当时接触 Vue3 的第一个项目，在当时Vue3测试版已经发布，而vue-element-admin都早已烂大街了，也有点审美疲劳了。想给自己换一个后台管理系统的模板，恰好无意间刷到了 Vben Admin，管理面板的效果让我眼前一亮，迄今为止我都认为非常耐看。

但是Vben Admin仅仅只是前端模板与mock数据，并无后端数据，于是就正好利用我使用的 Node 后端框架 Nestjs 来编写后端服务。但当时项目并不完善，在我编写了几个相似的后端管理的项目后，将核心部分抽离出来，并将其封装出来，kz-admin也就此诞生。

鸣谢 hackycy/sf-nest-admin，我的后端 nestjs 架构与部分代码都借鉴该项目。

最后也要感谢 Vben 项目，在当时让我进一步了解到 Vite + Vue + TypeScript 等最新前端相关技术。

Artwork from Nuxt3

Protocol

🧪 一个用于快速复现请求协议的 Web 开发模板。

🖥 在线预览

为什么我要写这样的一个模板(网站)​

我曾经是做 API 请求的，经常要模拟某些请求（协议复现）。所以写过比较多的 api 请求代码，在此期间尝试编写过许多代码方式和软件形态。但都不令我满意，不是过于繁琐，就是开发太慢，都达不到我想要的预期。尤其是开发体验，可以说是苦不堪言。

就在前段时间接触了 SSR 框架（Nuxt3）与 Serverless Function，并用其写了一些项目，如 api-service 。而某了个羊刷次数的网站的实现，则让我意外发现这貌似就是我理想中的的协议复现最佳实现？于是我立马开启了 VSCode，将我的这一想法用代码的方式来实现出来，在经历了两周几乎不间断的开发，最终达到了我的预期效果！

在 模拟请求|协议复现方案 这篇文章中我对协议复现的一些方案总结，而这篇就是对 SSR 框架方案的一个具体实践。

技术栈​

这个模板基于Nuxt3开发的，该框架拥有全栈开发能力（即全栈框架），并有诸多模块，即装即用。同时由于采用Serverless Function 方式来定义 api 接口，可以轻易地部署在自有服务器或Vercel， Netlify这样的平台上。由于要做到敏捷开发，该模板集成了Naive UI 组件库，组件库的质量足够胜任常规前端业务开发。此外还封装了一些我个人的所用到的工具库以提高开发效率。

为此我给这个模板起名 Protocol，即协议，也可以认为是礼仪。一个用于快速复现请求协议的 Web 开发模板。

废话不多数，就正式来介绍下 Protocol。

目录结构​

protocol
├── assets # 前端静态资源文件
├── components # 组件
├── composables # 组合式API
├── content # content 模块
│   ├── changelog.md # 更新日志
│   └── help.md # 帮助说明
├── data # 持久化数据
│   └── db
├── layouts # 布局
├── nuxt.config.ts # nuxt 配置文件
├── package.json # 依赖包
├── pages # 页面
├── plugins # 插件
├── public # 服务端静态资源文件
│   └── logo.svg
├── server # 服务端文件
│   ├── api # 后端接口
│   └── protocol # 协议请求逻辑代理
├── stores # pinia 状态管理
│   └── user.ts # 用户状态
├── types # 类型定义
│   └── user.d.ts # 用户类型声明文件
├── ecosystem.config.js # pm2 配置文件
├── nitro.config.ts # nitro 配置文件
├── app.config.ts # 前端配置文件
└── app.vue # 入口文件

从这个项目的目录结构中其实就可以看出，本项目是集成了全栈能力，并且使用 Vue 与 Node 来编写前端与后端，并不会产生前后端分离的分割感，只需要打开一个项目即可开始工作。这得益于Nuxt3 与 Nitro。

由于是基于 Nuxt3 开发的，所以使用该项目是需要一些 SSR 开发经验。如果你还没有接触 SSR，可以根据你熟悉的前端框架选择对应的 SSR 框架来尝试体验一番。都要 2023 年了，不会还有前端程序员没用过 SSR 框架吧。

基本功能​

全栈开发​

这里我不想过多介绍 Nuxt3 的基本功能与使用，在我的一个 基于 Nuxt3 的 API 接口服务网站 的项目中，有简单介绍过 Nuxt3，有兴趣可以去看看。

这里你只需要知道 Nuxt3 具有全栈开发的能力，如果你想，完成可以基于 Nuxt3 这个技术栈来实现 Web 开发的前端后端工作。

类型提示​

首先，最重要的就是类型提示，对于大多数 api 请求而言，类型往往常被忽略。这就导致不知道这个请求的提交参数、响应结果有什么数据字段。举个例子

这是一个 post 请求用于实现登录的，但是这个响应数据 data 没有任何具体提示（这里的提示是 vscode 记录用户常输入的提示），这时候如果一旦拼接错误，就会导致某个数据没拿到，从而诱发 bug。同理提交的请求体 body 不做约束，万一这个请求还有验证码 code 参数，但是我没写上，那请求就会失败，这是就需要通过调试输出，甚至需要抓包比对原始数据包才能得知。

最主要的是没有类型约束的情况下，非常容易出现出现访问的对象属性不存在，做 js 开发的肯定经常遇到如下错误提示。

Uncaught TypeError: Cannot read properties of undefined (reading 'data')

有太多很多时候就是因为没有类型，无形间诱发 bug。就极易造成开发疲惫，不愿维护代码，这也是很多做 api 接口都常常忽视的一点。包括我之前也是同样如此。

对于 js 而言，上述情况自然是解决不了，但这种场景对于 ts 来说在适合不过了。所以 Protocol 自然是集成了 ts，并且有良好的类型提示。下面展示几张开发时的截图就能体会到，当然你前提是得会 ts 或者看的懂 ts。

上面的类型提示演示代码仅仅作为体现类型的好处，将类型定义（interface，type 等）和核心逻辑都在同一个文件自然不好，容易造成代码冗余。实际开发中，更多使用命名空间，将类型写到 ts 声明文件.d.ts 中。比如将上面的改写后如下

就在我写这篇文章做代码演示的时候，又发生了拼写错误，如下图。由于使用 ts 类型与 eslint，所以在开发时的问题我就能立马发现，而不是到了运行时才提示错误。

有了类型提示能非常有效的避免上述问题。同时 ts 并不像 java 那样的强类型语言，你完全可以选择是否编写 ts 的类型（type 或 interfere），这由你决定，你乐意都可以将 typescript 写成 anyscript，因为确实有些人确实不喜欢写类型。

ts 的类型提示仅是其次，此外还配置了 eslint 对代码检查，让代码在 2 个空格缩进，无分号，单引号等代码规范下。保证代码质量，而不会出现这边一个分号，那边来个双引号的情况。

工具库​

要想在实际项目中使用，还需要做很多功课，例如数据格式转换，编码，加解密，cookie 存储，IP 代理等等。这段时间也特此对常用工具封装成 npm 包，也就是 @kuizuo/http 与 @kuizuo/utils。

大部分的代码我都会采用最新的 ECMAScript 标准来编写，目的也是为了简化代码，减少不必要的负担。

数据库​

既然是全栈框架，那么必然少不了数据库的存取，nitro 自然是提供了数据存储选择，即 unjs/unstorage。使用特别简单：

await useStorage().setItem('test:foo', {hello: 'world'});
await useStorage().getItem('test:foo');

不指定则使用内存，当然了想要持久化配置，nitro 也提供了相关配置

// nitro.config.ts
import {defineNitroConfig} from 'nitropack';
export default defineNitroConfig({
  storage: {
    redis: {
      driver: 'redis',
      /* redis connector options */
    },
    db: {
      driver: 'fs',
      base: './data/db',
    },
  },
});

并根据不同前缀（根据 nitro.config.ts 中的 storage 对象的属性）存储在不同存储位置，如

// 存内存缓存中
await useStorage().setItem('cache:foo', {hello: 'world'});
await useStorage().getItem('cache:foo');

// 存db中
await useStorage().setItem('db:foo', {hello: 'world'});
await useStorage().getItem('db:foo');

// 存redis中
await useStorage().setItem('redis:foo', {hello: 'world'});
await useStorage().getItem('redis:foo');

从目前来看，unjs/unstorage并没有提供 sql 数据库的方案。不过对于这类项目而言，似乎也没有上 sql 数据库的必要，文件和 redis 就足以了。如果需要也可以自定义 drivers。

用户凭证存储​

通常来说，有两种用户凭证，Cookie 和 Token，有了上述数据存储的方案，存取用户凭证并不是什么难题。不过用户凭证更多的是用来鉴权的，这时候就需要配置前端Middleware 和后端 Middleware，至于选择哪种，根据实际网站情况来选择即可。

更新日志与帮助说明​

我提供了两个 md 页面，更新日志（ChangeLog）和帮助说明（Usage），如果需要更新内容，在根目录下 content 文件夹中找到对应文件修改即可。

如果你想在创建新的 md 页面只需要在 content 中新建一个文件（如test.md），在页面路由创建同名vue文件(test.vue)，将下方的 path 修改相应文件名即可。

<script setup lang="ts">
definePageMeta({
  layout: 'markdown',
});
</script>

<template>
  <div>
    <ContentDoc class="prose text-left" path="/test" />
  </div>
</template>

打包与部署​

传统的 node 后端框架，通常需要将原文件或者打包后的文件放到服务器上，执行 npm i 下载 package.json 里的依赖文件，然后执行运行命令启动。这一步骤的下载依赖就尤为致命，因为通常下载依赖将会特别耗时。

但 Nuxt3 则是会将前后端的资源文件，打包到 .output 文件夹下，以本项目为例，打包的大小为 14.6MB,gzip 压缩为 3.11MB（写本章时的记录），如果不使用Content 模块体积将会更小。打包完成提示如下

Σ Total size: 14.6 MB (3.11 MB gzip)
√ You can preview this build using node .output/server/index.mjs

然后你只需要将 .output 整个文件夹放到服务器上，并且安装好 node 环境，输入 node .output/server/index.mjs 即可启动项目，默认端口为 3000。当然也可以通过 pm2 的配置文件来启动，配置文件如下

module.exports = {
  apps: [
    {
      name: 'Protocol',
      exec_mode: 'cluster',
      instances: '1',
      env: {
        NITRO_PORT: 8010,
        NITRO_HOST: 'localhost',
        NODE_ENV: 'production',
      },
      script: './.output/server/index.mjs',
    },
  ],
};

接着执行 pm2 start ecosystem.config.js --env production 即可运行。相比传统需要手动下载依赖的方式，Nuxt3 则是直接将 web 项目实际所需要的依赖都打包在一起，只需要在有 node 环境下机器中就可以立马运行，无需等待依赖下载。

如果部署在 Vercel 或 Netlify 就更轻松了，根据官方的步骤即可做到一键部署。

开发流程（形态）​

介绍完工具库，如果不介绍下开发流程，很多人都不知道该如何起手，这里我会用 Github 的 api 作为案例演示，也就是模板源代码中所演示的那样。当然，后续我会根据一些实战项目考虑弄个案例展示（在写中），以来方便使用与完善该模板。毕竟如果开发者自己都不愿意用，又怎么去说服他人来使用呢。

修改内容​

如何修改某文字内容或某图标，这里就不再赘述了，Ctrl + Shift + F 搜索你想修改的内容并修改即可。大部分能修改的配置都写在了 app.config.ts 下。

export default defineAppConfig({ title: 'Protocol', description:
'一个用于快速复现请求协议的Web开发模板。', author: { name: 'kuizuo', link:
'https://github.com/kuizuo', qq: 'https://im.qq.com/', wx: 'https://wx.qq.com/',
}, })

通过 const appConfig = useAppConfig() 获取配置对象数据。

定义协议复现逻辑代码（重要）​

这里以调用 Github 的 api 为例，因为业务相对简单，所以使用的是静态方法来调用，简单展示一下代码

import { AHttp } from '@kuizuo/http'

const http = new AHttp({ baseURL: 'https://api.github.com' })

export class Github {

  static async getUser(username: string) {
    const { data } = await http.get<API.User>(`/users/${username}`)
    return data
  }

  static async getRepos(username: string) {
    const { data } = await http.get<API.Repo[]>(`/users/${username}/repos`)

    return data
  }
}

我个人是习惯也喜欢将逻辑部分用 class 的方式来编写，也推荐用这种去定义这些业务逻辑代码。这里我举个例子来说明，假设现在有一个博客网站，有登陆、获取博文列表、评论等功能。那么我会这么写

import { AHttp } from '@kuizuo/http'

interface User {
  username: string
  password: string
}

export class Blog {
  public http: AHttp
  public user: User

  constructor(user: User) {
    this.http = new AHttp({ baseURL: 'https://blog.kuizuo.cn' })
    this.user = User
  }

  async login() {
    // login logic code
  }

  async getBlogList() {
    // getBlogList logic code
  }

  async comment(id: number) {
    // comment logic code
  }
}

定义完这些后，我只需要实例化一个对象 account，调用 login 方法即可登录，后续的获取博文列表与评论操作我只需要拿这个 account 来操作即可。

const account = new Blog({username: 'kuizuo', password: '123456'});
await account.login();

const blogList = await account.getBlogList();

await account.comment(1);

如果想换一个账号操作，就需要重新按照上面的方式实例化一个新的对象，拿这个对象操作即可。

并且这种方式在迁移代码的时候尤为方便，可以直接将这份代码放到不同的 Node 项目中来运行。

通常也是在这一流程中，会编写大量的类型代码，来完善整个项目，保证代码的健壮。通常我会在同文件下或者在 types 下定义 .d.ts 声明文件，通过声明文件与命名空间，无需导入即可全局使用类型。

定义后端数据接口​

定义完复现协议的逻辑代码后，那么就到前后端数据交互部分了，首先定义后端的接口，由于上面我们已经定义好了协议复现逻辑代码，这边只需要导入使用即可。就像下面这样

import { Github } from '~~/server/protocol/github'
import { ResOp } from '~~/server/utils'

export default defineEventHandler(async (event) => {
  const { username } = event.context.params

  const user = await Github.getUser(username)

  if (!user.login)
    return ResOp.error(404, user.message ?? 'User not found')

  await useStorage().setItem(`db:github:user:${username}`, user)

  return ResOp.success(user)
})

这一部分的代码建立在 Serverless Function 上，每一个接口都是以函数的方式对外暴露出去。这些代码会根据文件位置生成对应的路由，比如说上面的文件为 server/api/user/[username].ts，就映射为 /api/user/:username，前端请求 /api/user/kuizuo 通过event.context.params.username 便可以拿到 username 的值为 kuizuo。

至此后端部分就暂以告告落。

定义前端状态管理​

对于前端而言，肯定是需要全局管理一些数据状态的，这样能够在不同的组件间共享数据，并且需要持久化这些数据，以保证下次用户再次打开网页的时候无需向后台请求数据，pinia 持久化使用到了 pinia-plugin-persistedstate 插件。

同时在状态管理中，会定义一些方法来调用后端接口。如下演示

import { useMessage } from 'naive-ui'

export const useUserStore = definePiniaStore('user', () => {
  const user = ref<API.User | null>(null)
  const repos = ref<API.Repo[]>([])
  const message = useMessage()

  async function getUser(username: string) {
    const { data } = await http.get<API.User>(`/api/user/${username}`)

    if (data.login) {
      user.value = data
      message.success('获取成功')
    }
    else {
      message.error(data.message)
    }
  }

  async function getRepos() {
    const username = user.value?.login
    const { data } = await http.get<API.Repo[]>(`/api/repo/${username}`)
    repos.value = data
  }

  async function reset() {
    user.value = null
    repos.value = []
  }

  return {
    user,
    repos,
    getUser,
    getRepos,
    reset,
  }
}, {
  persist: {
    key: 'user',
  },
})

这里的 http 是经过封装的，因为返回数据格式如：{"code":200,"data":{},"message":"success"} ，但对于业务逻辑而言，我们通常只需要关注 data 里面的数据，而请求的状态 code 与信息 message 则不是所要着重关系的对象。

至于想要返回原数据，还是带有 code, message 的数据，因人而异，我更喜欢后者将数据格式规范化，这样我就能知道本次请求的状态结果，在响应拦截器中就能够进行预先处理。

在 vue 组件中只需要使用演示如下

<script setup lang="ts">
let username = $ref('kuizuo');
let loading = $ref(false);

const userStore = useUserStore();
const user = $computed(() => userStore.user);

async function getUser() {
  loading = true;
  try {
    await userStore.getUser(username);
  } finally {
    loading = false;
  }
}
</script>

编写前端页面与组件​

这一部分自由发挥即可了，这里我是集成了 NaiveUI 与 Unocss，足够应对大部分的前端开发需求。没什么过多要说的了。

流程总结​

整个开发流程就是这样的，如果我想要添加一个功能，用于获取 Github 用户已点的 Star 项目列表，那么按照上面流程将会清晰的实现出来。

这里仅举调用 Github api 为例，想调用其他第三方的 api 都不成问题，本模板只提供一个这样的开发流程（形态）能够帮助快速实现 Web 站点开发，同时极易部署，做到敏捷开发。

对比传统前后端分离的开发流程，这种开发流程可以说更加清晰，更加规范，更加高效。

一些问题​

遇到图片防盗链怎么办?​

我的做法相对比较简单粗暴，直接在图片中添加referrerpolicy='no-referrer' 就像下面这样。

<img src="src" referrerpolicy="no-referrer" />

如果你想要集成到 HTML 或者 CSS ，可以直接在 <head> 标签下添加如下代码.

<meta name="referrer" content="no-referrer" />

参阅Referrer-Policy - HTTP | MDN (mozilla.org)

跨域问题​

几乎不会遇到跨域问题，因为所有的接口都相当于转发过一遍，不是由前端直接发送，而是后端接收到后，通过服务器来进行发送，然后将数据在返还给前端。

考虑做的​

编写一个后台管理系统​

这个模板如果要实现鉴权是相对比较简单的，前后端配置Middleware 即可实现。使用 cookie 和 token 都随意，甚至第三方的登录。

但这时数据多了，难免需要去管理数据，不如专门为此编写一个后台管理系统，同时提供一个鉴权相关的功能。主要还是借助 ntrio 来开发，毕竟提供全栈开发能力，要实现只是时间开发的问题。

使用 tauri 编译跨平台程序​

编译成跨平台程序有一个好处，就是所有的流量请求与接收都是存放在用户的机器中，就相当于传统的桌面应用开发。而部署在 Web 端请求流量的压力都将会来到服务器上，就避免不了用户量大，导致请求缓慢，甚至 ip 被封禁的问题。

由于我暂且还不会 tauri 开发，也还不会 rust，所以这个功能估计得到寒假才有可能去实现了。electron 占用比较大的资源空间，不作为跨平台框架优先选择。

写在最后​

这种开发形态自打我接触协议复现到前端开发我就考虑过，但奈何在没接触 ssr 框架之前，这种开发形态多半是需要前后端分离，要么使用模板语言，这样接口交互方面将会十分繁琐，开发效率过于低效。

因此当我发觉 ssr框架的可行性后，我几乎整整花费了两周的时间在不断的探索与完善中，希望将其编写成一个我日后随时都会用到的模板，即写即用，极速上线。因为这样的开发场景对我来说太过于常见了，而很多时间就是因为没有一个相应的模板与工具库，代码总是东凑西凑，后续维护与测试总是花费不小的时间去解决。

目前这种方案已有初步雏形，由于一些特殊的因素，我并未将已经写过的站点作为案例放在这上面作为演示，而将 Github api 作为演示，后续大概率会弄个案例展示供参考学习。

后续我还是会不断去完善与维护该项目，并基于该项目去重构我的一些项目。

本模板仅仅是 web 模板，任何开发者用该模板做什么样的站点都与本人无关。仅作为个人技术专研，仅供学习参考。

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

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

为什么不是Webpack？​

rollup 的特色是 ES6 模块和代码 Tree-shaking，这些 webpack 同样支持，除此之外 webpack 还支持热模块替换、代码分割、静态资源导入等更多功能。

当开发应用时当然优先选择的是 webpack，但是若你项目只需要打包出一个简单的 bundle 包，并是基于 ES6 模块开发的，可以考虑使用 rollup。

rollup 相比 webpack，它更少的功能和更简单的 api，是我们在打包类库时选择它的原因。例如本次要编写的工具包就是这类项目。

支持打包的模块格式​

目前常见的模块规范有：

• IFFE：使用立即执行函数实现模块化 例：(function(){})()

• CJS：基于 CommonJS 标准的模块化

• AMD：使用 Require 编写

• ESM：ES 标准的模块化方案 ( ES6 标准提出 )

• UMD：兼容 CJS 与 AMD、IFFE 规范

以上 Rollup 都是支持的。

使用​

官方有一篇文章 创建你的第一个bundle ，不过英文文档比较难啃，同时通过命令方式+选项的方式来打包肯定不是工程化想要的。

配置文件​

所以这里所演示的是通过 rollup.config.js 文件，通过rollup -c 来打包。

一个示例文件如下

export default {
  input: 'src/main.js',
  output: {
    file: 'bundle.js',
    format: 'cjs'
  }
};

执行 rollup -c 就会将main.js 中所引用到的js代码，通过commonjs的方式编写到bundle.js，就像这样。

'use strict';

var foo = 'hello world!';

function main () {
  console.log(foo);
}

module.exports = main;

但是更多的情况下，是需要同时打包多个模块格式的包，就可以在output传入数组，例如

export default {
  input: 'src/main.js',
  output: [{
    file: 'bundle.cjs',
    format: 'cjs'
  }, {
    file: 'bundle.mjs',
    format: 'esm'
  }]
};

便会生成 bundle.cjs, bundle.mjs 两种不同的模块格式的文件。同时在 package.json 中，指定对应模块路径，在引入时，便会根据当前的项目环境去选择导入哪个模块。

{
  "main": "bundle.cjs",
  "module": "bundle.mjs"
}

结合rollup插件使用​

不过更多情况下，rollup需要配置插件来使用。官方插件地址：rollup/plugins: 🍣 The one-stop shop for official Rollup plugins (github.com)

比如使用 rollup-plugin-esbuild 插件来使用esbuild（也是一个打包器，并且构建非常快）来加快打包速度。可以使用 @rollup/plugin-babel 借助babel，编译成兼容性更强的js代码或者代码转换等等。

以下是rollup+插件的配置示例，来源 antfu/utils/rollup.config.js ，也作为本次工具包的配置。

import esbuild from 'rollup-plugin-esbuild'
import dts from 'rollup-plugin-dts'
import resolve from '@rollup/plugin-node-resolve'
import commonjs from '@rollup/plugin-commonjs'
import json from '@rollup/plugin-json'
import alias from '@rollup/plugin-alias'

const entries = [
  'src/index.ts',
]

const plugins = [
  alias({
    entries: [
      { find: /^node:(.+)$/, replacement: '$1' },
    ],
  }),
  resolve({
    preferBuiltins: true,
  }),
  json(),
  commonjs(),
  esbuild({
    target: 'node14',
  }),
]

export default [
  ...entries.map(input => ({
    input,
    output: [
      {
        file: input.replace('src/', 'dist/').replace('.ts', '.mjs'),
        format: 'esm',
      },
      {
        file: input.replace('src/', 'dist/').replace('.ts', '.cjs'),
        format: 'cjs',
      },
    ],
    external: [],
    plugins,
  })),
  ...entries.map(input => ({
    input,
    output: {
      file: input.replace('src/', '').replace('.ts', '.d.ts'),
      format: 'esm',
    },
    external: [],
    plugins: [
      dts({ respectExternal: true }),
    ],
  })),
]

以下是对应的npm 安装命令

pnpm i -D rollup @rollup/plugin-alias @rollup/plugin-commonjs @rollup/plugin-json @rollup/plugin-node-resolve rollup-plugin-esbuild rollup-plugin-dts

关于rollup更多使用，不妨参见 rollup官方文档，以及一些使用 rollup 来打包的开源项目。

类似工具​

类似的工具还有 webpack.js, esbuild, parceljs

不过就打包类库而言，并不要求过强的性能，有个相对简单的配置就足以，而 rollup 正是这样的打包工具。

相关文章​

【实战篇】最详细的Rollup打包项目教程

一文带你快速上手Rollup

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

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

熟悉我的人应该都知道，我对很多新鲜的技术有一种难以用言语表达的情感，又哭又笑。属于是那种看到感兴趣的就会开始尝试，在之前也许更强烈。

驱使我去接触的原因无非就以下几点：

• 开发体验、性能提升
• 对已有技术的厌倦感和对新鲜事物的好奇心
• 更多机会与方向
• 对未来技术趋势有更好的了解

写不完的代码​

首先要知道一点，在任何的软件开发迭代中都没有最终形态的代码。说白话就是代码都是不断更新的，永远写不出最好的代码。

你能看到如今很多开源项目或者商业项目都在不断新增代码或者功能，除非作者不维护了，不然这份代码可以说写到世界末日。

究其原因还是因为社会不断在发展，硬件升级，性能提升，不断的业务需求。毕竟人都在进步，社会难道还不能进步。所以必然会有新的技术出现，只是出现的时间快慢，与技术难点突破。

开发体验、性能提升​

毋庸置疑，在购买方面，肯定是买新不买旧，同样的在技术（软件更新）方面也是则从用新不用旧。驱使软件和框架更新的原因也就是新增了某些功能（特性），对用户（开发者）的体验有所提升。一般而言比较少的会存在反向更新的操作，这里除了某些国产软件（如某信，某 Q 等等）

就我对此的看法也是如此，假设一个开发工具启动花费了 5s 钟启动，而在它的最新版只需要 1s 钟就能够启动，你会选择更新尝试吗？。再比如一个框架原先的代码需要 10 行代码才能实现的功能，由于新版本提供一个语言级别的语法糖，使该功能只需一行。

并且我对开发体验非常在意，尤其是不好用，或者不好配置的东西，我基本秉持能不用就不用的原则，像 vue2 与 webpack 就是这样，我跟愿意使用 vue3 或 vite。诸如此类的替换有非常多，便不一一列举。

要我肯定毫不犹豫的更新去使用，但有些人可能对此提升不是很在意，又或者是升级的成本相对较高，也可能是因为这个开发工具（框架）他用的比较少，更新的意义自然就不大。

对代码厌倦和对新事物的好奇心​

我写代码时常处于三分钟热度的状态，有些东西可能也就一开始的时候感觉比较新奇，然后就不了了之了。我对此的看法主要还是容易对代码产生厌倦感，不想写代码，不愿意学习。当厌倦感产生了，自然而然就放弃编写，也就是三分钟热度的状态。不过也能侧重体验一点，那就是肯定我对此不是那么感兴趣，既然不是那么感兴趣的东西，又何必在写下去呢？

接着过段时间又遇到了一个新的技术，冲击了我的好奇心，开始尝试。 如此重复，就会发现啥都学了一点，但实际是啥都没学到。但至少，让我肯去学习，而不是在原地踏步。而从心底里就想接触的新鲜事物，每次接触到就能满足自己内心的好奇心，就这一点我便知足了。

重构的艺术​

如果回头看看自己 1，2 年前写的代码，会发现原来自己也曾写过丑陋不堪的代码，也成为过自己所讨厌的样子。如果这份代码我将来还会用到，那么我就尝试去重构，也许在当时还不支持某种特性，代码就无法简化。基于现有的水平，便会发现很多代码都有可改善的地方，可以化繁为简。代码重构属于将杂乱摆放的东西，收拾的整整齐齐的样子。重构是在提升观赏度和舒适度的同时，还减少 bug 的诱发概率。

在编程语言级别水平上，也就是我为什么会想去使用最新的版本（ES2022，TypeScript 4.9），即便是兼容性的问题，我也会去使用，就是因为能够满足我对代码的舒适度，这便足以。

生态与解决问题方面​

我是很感谢新技术的出现，他实实在在的解决了一些我已有的痛点，提升了我的开发体验。当然它也让我踩了无数的坑，也折磨过我。但不可否认的是，我的自我解决问题的能力也在不断提升，如果我学的是一门比较流行的技术，那么我所遇到的问题，很有可能别人也遇到过，并将他的解决方案分享出来。而我就很容易根据报错描述找他的解决方案来解决我的问题。但在新技术下，用的人自然而然就少了，所分享的问题解决方案也就少了，所以在这种环境下，我就需要自行翻看源码，查阅文档，提出 issues 才能够解决问题。自然而然解决问题的能力也就有所提升。

像流行框架能有这么有问题解决方案，就是因为强大的生态，同时这也是生态好处之一。

因此也有很多人顾忌使用新技术，就是因为遇到问题不知如何解决。包括我也是，但通常我会观察一段时间，等成熟了我才去尝试，而不是直接上手，避免踩一些不必要且耗时的坑。

总是活在舒适圈​

在圈内有着熟悉的环境，与认识的人相处，做自己会做的事，所以会感到很轻松、很自在。但是当踏出这个圈子的界限的时候，就马上会面对不熟悉的变化与挑战，因而感到不舒适，很自然的想要退回到舒适圈内。

我在阅读英文博客的时候，我也时常感到不舒适，阅读不下去。我也很想回到舒适圈，使用翻译软件来翻译但是这样就会导致我非常依赖翻译软件，就间接失去了一次英文环境与英语能力的提升。

长时间待在舒适圈，会让自己过得很舒服，但是却很难提升自己。不过想想也是，提升的过程不就是苦尽甘来。

以目前来看有一种这样的学习趋势，别人学什么，当下什么技术火，就去学什么。我其实特别反感这种现象，也不推崇这种学习理念。我会做出我的解释：

首先，什么技术会火就学什么，这固然没什么问题，如果一门技术没有热度，没有生态，那么学了的意义不大，一是难有长久稳定的技术发展，二是不能将技术变现。而绝大多数人之所以选择火的技术，有很大一点是因为有前人给他铺了很多“路”，如学习指南，思维导图，视频教程仿佛跟着学就能成为编程大牛似的。可一旦没有这些，就不知道该如何下手。始终都是跟着别人步伐学习，思维很难扩散出去。

并且这种现象必然会导致内卷，首先看看国内的技术，Vue 和 Spring boot 的可以说 10 个 web 开发程序员中有 8 个技术栈是这套，比麻花还是卷了，可薪资呢？

这里我并不想贴相关的薪资图片，你完全可以自行去了解，但是我可以肯定且直接告诉你，React 的薪资普遍会比 Vue 高上一截，而 Java 后端开发，如果技术只停留在 CRUD 的层面，工资普遍也高不了多少。

如果你不去拓展自身的技术栈，不多去了解一些未来的可能会火的技术，还停留在当下，活在舒适圈。那么薪资大概率不变，并且自身会有很大被劝退的概率。

与时俱进，这是我认为不断学习新技术，提升自身技术栈，非常重要的一点。过得舒服，反而过得难受

更多的机会与方向​

技术更新迭代越来，也带来越多的机会，这对于接触前端的我感到尤为明显。假设当下又出了某某技术，那么必然会引起软件开发者的关注，于此同时就带来了维护者，贡献者，甚至是一些金主投资商。像 Tailwind CSS 与 Vercel 就是一个很好的例子，两个前端明星项目，有兴趣可以了解它们的故事。

不过这种机会在国内不太多见，反而在国外特别普遍。

但必须要承认的一个事实，如今技术发展过于迅猛，加上目前就业行情不容乐观，当别人了解过的东西，你却不了解，那么别人所能遇到的机会自然就比你多。说的难听点也就是没有对技术提升的想法，今后项目迭代的过程中使用到一些前沿技术就难以胜任。

没有目标的学习，等同于乱学​

没有一个明确的目标，学任何（新）技术都是乱学，充其量也就只比不学好一点。

这在我初学阶段尤为明显，我一开始也不清楚我以后会从事什么行业，可以说是什么都乱学一顿。在我的一篇年终总结 2019.7-2020.7 编程年记 中可以说是尤为明显，尤其是在 定一下明年的目标 的段落中，最后我真正深入学习的也就是只有 Web 开发。

我相信很多初学者也会遇到类似的问题，不知道学什么，想学好找工作的但是薪资不高，想学感兴趣的但又不知如何下手。说实话，要我回到当初，我也难以抉择。也有可能处于摆烂状态或是乱学一同，到头来啥都会一点点，但是又好像啥也不会的样子。

这里我是奉劝先定一个短期的目标，为了这个目标我要去学习哪些技术知识。这里就说我未来一年的目标为例：我未来一年想写开源项目，为开源社区做一份微薄贡献，乃至从事开源行业。那么我就需要了解写开源我需要那些预备知识，例如 Github 的使用，项目规范，英文交流等对应开源项目的技能知识，这才是我所该学的，并且能够实实在在用到的，且对我未来有用的。

对未来技术趋势有更好的了解​

当你了解的技术越多，你就越能知道自己适合哪些技术。并且当你去尝试过后，更能加深你对某个技术的信仰。

在未来技术只会越来越多，因为当下要解决太多问题，有太多的业务需求开发。只要不断有需求，就不断会有技术更新。但技术更新必然是朝着好的方向去发展，即技术趋势方向。而了解的越多，能看到技术趋势也就更远，方向就更难偏移。

像我目前就比较看好未来 js/ts 的发展，这也是使我从逆向和爬虫转到 Web 开发行业上，并且将会长期发展下去。

但很多程序员就缺乏这种对技术的认可，甚至眼光比较浅薄，认为自己当下所学的就足以，可没却从未到真正的”外面”去看过。

当有了对未来技术趋势的了解，自身就有相对明确的目标学习，而不是漫无目的学习，跟风学习。

我是如何了解到这些技术的？​

也许有些人并不在意新技术是否学习，而是好奇我是如何知道这些技术的。这个问题非常好，我自己简单总结通过那些途径来获取到这些相关技术的新闻。

主要有以下几种来源：

• 多加技术群，不定时看群聊
• 多刷技术大佬文章（推特），或者是技术公众号和掘金（最多的也是最有效的）
• 订阅一些技术周刊，或订阅某个项目

没啥技巧，就靠刷技术文章，自然而然的了解也就越来越多了。

尤其是第二点，也是我了解这些新技术的最直接途径。与其自己去主动了解新的技术，将刷抖音的时间改成刷技术文章，了解新技术就是分分钟的事情。可以说我写博客是因为这个契机，记录自己用到的技术的开发过程，并分享个人的开发体验，让更多人了解到这些新技术。

面对新技术该怎么学？​

其实更多时候是比较在意如何去学一门新技术，而不是找一门新技术，当阅历多了，技术自然就了解的多。这里我分享下我对于新技术是如何起步与学习的。

首先我会列举出我近期感兴趣的技术，这一步很关键，我当然不可能每个技术都去尝试一遍，时间精力根本不够。通常在我了解到这个技术的时候，比如文章与视频中，都会介绍到这个的优点与用法，这就足以了。

但想要进一步的学习，还是得依靠实战项目（至少我都是通过实战项目来学习的），这时候我会看看手头的项目，看看有没有能够基于上面所列举出的新技术升级的想法，如果有的话，那正好就当重构与新技术的学习，这是最好的，也是相对比较节省时间的。

但如果没有的话，我通常是会考虑另写一个项目，而这个项目可能是某个灵感的实现，也可能是久违想写的项目，或者是复刻某个感兴趣的站点，总之从上面所列举出来的技术中去选择一个来进行实践。在项目实践中去尝试使用这些新技术，哪怕只是实现一个简单的demo，也总比单纯的刷文档，看代码来的有效。

在项目实践中学习，永远是最直接也是最有效的。回想你编写课设或者工作的项目，是不是在项目开发中进步的最快？如果这时候还有点时间紧迫感，进步反而会更快。（当然焦虑和压力也会随之提升）

最后感悟​

关于本文，必然有引来一些不同看法与见解，每个人都有对不同事物的理解，我只是将我对新技术的看法，以文章的方式输出出来。本文并未带有任何的技术的偏见，我对任何技术都保持一视同仁，并且愿意去尝试学习。

不必抱怨新技术发展的过快，自己来不及学，学不完。或者担心自己学的东西在未来将会淘汰，等同于白学。学习过程就是一个非常好的经验总结，当你回顾整个学习过程，其实都没有白学。反而多一次的学习过程，在未来学习新的东西时，学习的成效也会显著提升。保持不断学习，就永远来的及学习。

更多时候，不应该只学如何使用，而是该想想这东西是在什么样的契机下如何被创造出来的，解决了什么问题。而这个问题在未来有没有什么更好的解决方案可替代，如果有更好的解决方案，那么必将又将发展出新的技术来更好的解决这个问题。这在我曾经的学习中，我是从未考虑到的，只专注于学习，而没去了解为什么。

我是希望越来越多的新技术出现，无论它是为了解决什么，必然能解决某些人的一些需求，那么它的出现就很有意义。至于未来该技术和相关生态发展如何，不得而知。也没人敢笃定未来这个技术必定会火，就去学这门技术。绝大大多情况下都是比较看好这门技术，认为未来可期，同时又感兴趣，就开始学习并使用。

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

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

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

适合引入自动化测试的场景​

提前简单总结下适合引入自动化测试的场景（优点）：

• 中长期项目迭代/重构（需要频繁的修改代码）

• 准确定位代码问题，提高代码质量

• 引用了不可控的第三方依赖，极易发生 bug（例：beta 版相关的包）

测试的目的在于，及时发现错误，提高代码质量和开发效率，避免存在 BUG 的代码发布上线造成损失。

自动化测试要注意的点

• 并不是所有项目都适合引入自动化测试，反而会增加一定代码成本

• 如果项目开发阶段还不稳定，那么手动测试效率会比自动化测试更好

• 有些代码可能这辈子都不会在碰第二次，就没有编写自动化测试的意义

在代码编写阶段，建议只对重点功能进行测试，没必要一定追求过高的测试覆盖率。注意，是编写阶段

测试思想​

TDD：Test-Driven Development（测试驱动开发）​

• TDD：Test-Driven Development（测试驱动开发）：TDD 则要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行

BDD：Behavior-Driven Development（行为驱动开发）​

• BDD：Behavior-Driven Development（行为驱动开发）：BDD 可以让项目成员（甚至是不懂编程的）使用自然语言来描述系统功能和业务逻辑，从而根据这些描述步骤进行系统自动化的测试

自动化测试类型​

测试类型有以下几种：

• 单元测试（Unit Testing）

  代码中多个组件共用的工具类库、多个组件共用的子组件等。通常情况下，在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。

• 集成测试（Integration Testing）

  测试经过单元测试后的各个模块组合在一起是否能正常工作。会对组合之后的代码整体暴露在外接口进行测试，查看组合后的代码工作是否符合预期。集成测试是安全感较高的测试，能很大程度提升开发者的信心，集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。

• UI 测试 （UI Testing）

  对于前端的测试，是脱离真实后端环境的，仅仅只是将前端放在真实环境中运行，而后端和数据都应该使用 Mock 的。

• 端对端测试（End-to-End Testing）

  将整个应用放到真实的环境中运行，包括数据在内也是需要使用真实的。

关于测试框架，我主要使用 Vitest 与 Cypress。这两个作为测试框架都相对比较新，并且性能与开发上会比 Jest，Puppeteer 来的好。本文的一些测试示例也是基于这两类框架之上。

自动化测试的误区​

自动化测试和普通说的测试是有些不大一样的，有很多测试，其实都不能归类为前端自动化测试。这里我会举个例子来说明一下。

在自动化测试来说有个要求：自动化测试要的不是某次测试执行的是否通过，而是每次执行都必须通过。

怎么理解这句话呢：比方说我要测试获取博客列表的函数，假设实际的接口失效了，那么就会导致结果与预期不一致，就会导致代码测试不通过。既然不通过，那我就要去查看为什么不通过。当我点击这个单元测试的时，发现原来是后端接口失效了。可万一哪天这个接口突然好了，又或者发现刚刚原来没插网线导致的请求失败导致测试不通过。像这些 不稳定因素 在前端自动化测试中就会使用 mock 的方式，强制返回一定格式的数据给测试框架。到这里你可能会好奇，为什么要这么做？

想想看，如果因为接口失效导致测试失败，是因为测试代码的问题吗？那跟测试代码有毛关系，明显是后端或者服务器的问题。我们要测试的是获取博客列表的函数，而不是在测试接口（接口自动化测试）。测试接口不应该是前端要做的事情。确保后端返回正确的响应结果，前端能够对这些数据进行处理渲染，这才是我们要做的。

每次测试都存在不可控的因素，就会导致每次测试结果都有可能不同，这就违背测试的意义了。 所以这也就是为什么要数据 mock 的原因了。

给测试输入的值，在经过测试后，要保证输出的值与我们预期想要结果的值相同。

自动化测试到底在测试什么？​

其实目前前端有个尴尬的点，目前绝大部分实际业务项目里，前端的单元测试都没啥鸟用，UI 自动测试又太难搞。

这就导致很多开发者不清楚到底要测试什么，导致对测试特别不重视，包括我一开始也是如此。看到很多文章都是在演示测试 1+1 =2，介绍测试框架，很少从实际项目中出发进行测试。不过原因无非就是实际项目写的少，就别说测试代码了。再不然就是写过的代码都不怎么维护（重构，阅读），自然的就不会去写测试了。

不过确实没什么好举例的，因为太多东西可以写成单元测试了，比方说formatTime.test.ts, param2Obj.test.ts,validate.test.ts，从文件名就知道在测试什么了，就看开发者想不想写的问题了。

可以到 vitest-dev/vitest / facebook/jest 等测试框架中的 example 中查看测试案例。

关于 UI 测试和 e2e 测试，我非常推荐看看 cypress 的Todo 示例，测试的特别清楚，这里放张官方测试结果供参考。

这里补充一句，vitest 是能做 UI 测试的，可以通过 vuejs/test-utils 库来实现，但是 vitest 的运行环境是 nodejs，通过 jsdom 等库来模拟浏览器环境，而 cypress 是实实在在的运行在浏览器上，而且有可视化页面操作。这两者的区别也就是运行时环境的区别，有些实际场景对真实环境是有需求的，所以针对 UI 测试更多会选择像 cypress 这种直接运行在浏览器的测试框架。

为何我开始重视起测试?​

在之前我根本不会在意测试，就连已有的测试代码我都不会尝试运行。就在前段时间我正重构我的一个项目时，但当我写了一大部分的代码后，我尝试运行发现有些功能失效了。于是我进一步的排查，终于找到我修改代码并还原成我原来的代码。

假设一开始有份完整的测试代码，当我修改一部分代码后，跑一遍测试查看测试情况。发现没问题后，再开始下一步的代码工作，反复测试，直到最终重构完毕。与其浪费代码的时间，不如将这些时间去用来完善测试代码。不仅自己后续使用需要，到时候项目交付给别人的时，别人也不至于修改你的代码时兢兢业业。

究其原因是为了保证代码质量。

当然，虽说重视，但我也不会立马为已有的项目增加测试.耗时且费力不讨好。更多时候只会在准备重构的项目，或者是新项目上去增加测试代码。

编写这篇文章主要解惑我自己对往常对测试的看法，也借此机会养成 TDD 模式的开发的习惯。

参考文章​

试试前端自动化测试！（基础篇） - 掘金 (juejin.cn)

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

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

Gitea​

Gitea 是一个开源社区驱动的轻量级代码托管解决方案，后端采用 Go 编写，采用 MIT 许可证.

你可以在 横向对比 Gitea 与其它 Git 托管工具 查看 gitea 与其他 git 工具的优势与缺陷。

安装​

这里我选用 Docker 进行安装，安装文档可在官方文档中查看其他安装方式

version: '3'

networks:
  gitea:
    external: false

volumes:
  gitea:
    driver: local

services:
  server:
    image: gitea/gitea:1.17.1
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '10800:3000'
      - '2221:22'

根据自身需求配置 docker-compose.yml 内容。运行 docker-compose up 等待部署

服务器防火墙与云服务安全组都需要开放端口才可访问，服务器ip:10800，将会出现如下界面

因为修改配置相对比较麻烦，所以在首次安装的时候，请根据实际需求进行配置安装。

修改配置​

假设要修改其中的配置的话，gitea 的后台管理面板是无法直接修改的。需要到 /data/gitea/conf/app.ini 中修改，具体修改的配置 参阅 自定义 Gitea 配置 - Docs

迁移仓库​

从其他第三方 git 仓库迁移到 gitea，可以访问https://git.kuizuo.cn/repo/migrate 来迁移仓库

稍等片刻，取决于访问 github 仓库的速度。有可能还会迁移失败，就像下面这样。

所以可以申请访问令牌（Access Token），在 New Personal Access Token 处创建。迁移成功后，如下图所示

镜像仓库​

很大部分时间，gitea 只能作为我的副仓库，或者说 github 的镜像仓库。

gitea 也提供镜像仓库的方案，官方文档Repository Mirror

Drone​

由于 Gitea 并没有内置 CI/CD（持续集成/持续部署） 的解决方案，所以需要配置第三方的，这里推荐使用 Drone CI。

Drone 是面向繁忙开发团队的自助服务持续集成平台。相对于常见的Jenkins，选中 Drone 的原因在于它非常简洁，不像 Jenkins 那样复杂，同时它拥有可以满足基本需求的能力，并且提供了许多实用的插件，如GitHub，Email，微信，钉钉等

安装​

由于我们使用了 gitea，所以 drone 中选择 gitea 来安装，这是官方文档 Gitea | Drone，照着操作即可。

需要安装 Server 和 Runner，一个是 Drone 的服务，另一个用于检测 Git 记录，以重新构建项目。

这里贴下 drone 的 docker 配置（根据文档和自己部署的 git 服务配置来替换）。

docker run \
  --volume=/var/lib/drone:/data \
  --env=DRONE_GITEA_SERVER=https://try.gitea.io \
  --env=DRONE_GITEA_CLIENT_ID=05136e57d80189bef462 \
  --env=DRONE_GITEA_CLIENT_SECRET=7c229228a77d2cbddaa61ddc78d45e \
  --env=DRONE_RPC_SECRET=super-duper-secret \
  --env=DRONE_SERVER_HOST=drone.company.com \
  --env=DRONE_SERVER_PROTO=https \
  --publish=80:80 \
  --publish=443:443 \
  --restart=always \
  --detach=true \
  --name=drone \
  drone/drone:2

docker run --detach \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  --env=DRONE_RPC_PROTO=https \
  --env=DRONE_RPC_HOST=drone.company.com \
  --env=DRONE_RPC_SECRET=super-duper-secret \
  --env=DRONE_RUNNER_CAPACITY=2 \
  --env=DRONE_RUNNER_NAME=my-first-runner \
  --publish=3000:3000 \
  --restart=always \
  --name=runner \
  drone/drone-runner-docker:1