![\"IMG_1456.JPG\"](\"https://img.kuizuo.me/2024%2F1231181558-IMG_1456.jpg\")
面临着最后半年的大学生涯，与大多数大学生不同，我无时不在期盼着毕业这天的到来。步入职场进入了一家 AI 初创公司开始了\"牛马\"生活。最终我选择在国庆前裸辞，回到老家开始黑猴 play，却未曾料到，一份远程工作机会和一位新伙伴🐱悄然而至…
\n由于之前经历了转专业+休学以及一系列旷课行为导致挂科学分不够，最终不得不在临近毕业时为这些“买单”（出来混总是要还的）。在大四下的时候，有几场考试的时间被安排在发毕业证之前，这意味着我会比他人晚拿到毕业证(大约 2 周)。
\n不过因祸得福的是，由于延毕所导致我的学生认证资格一直延续到现在，预估明年 6 月毕业季时，我的学生认证才会真正到期。
\n![](\"https://img.kuizuo.me/2024%2F1231191115-20241231191114.png\")
\n要我说读大学对我有什么用的话，我能回答的或许只有学生认证所带来的各种优惠，而非传统大学教育为我提供了什么有价值的东西。
\n上大学对我说算是一种束缚，甚至让我一度怀疑我所读的不是一所的“大学”，反而是所“监狱”。
\n上大学也是我愧对于父母的一件事情，我也一直不愿意与他们诉说我在大学期间做了什么，因为解释给他们晦涩难懂，何况大学期间发生的变故差点让我难以毕业。
\n每当他人提起我的学校，我总会有点莫名的哽咽，因为大学很垃圾，难以说出口，我一直不愿说我是本校的学生，且有意为之将有关学校的信息隐秘于世，宁可告诉别人我没读过大学，也不愿让其知道大学名字。
\n或许当年直接选择辍学而非休学能真正抹除自己内心的阴霾。
\n在结束了毕业论文答辩，于是决定去广州与网友面基。这是我第一次网友线下面基，再次之前我甚至都没有去过北上广深，甚至这是我自己第一次一个人出省玩🥲。
\n面基的第一天网友就带我体验了 livehouse，还用无人机拍下广州塔的美景。
\n
后面一起去深圳参加了 VueConf 大会，也是我第一次参加这种大型技术活动。之后还计划一同去🇭🇰搞卡，然而和去年一样，由于特殊原因，今年的我依旧办理不了港澳通行证😔
\n下半年参加 Feday 有幸见到了一些大佬，技术的氛围感，让我感受到了一种前所未有的激动。明年的我一定要面基更多的网友，去更多的地方，体验更多的生活。
\n结束了短暂的游玩时光，终于要开始苦逼的牛马生活了，吗？
\n和绝大多数刚毕业的应届生一样，在家人的建议和考虑下，我最终选择去福州和我姐一起生活和工作，这样既能照应彼此，减轻一些生活压力的同时，还能提高生活幸福指数。
\n事实也确实如此，在我姐的几年生活经验下，我几乎不用考虑衣行吃住，在福州过得是有滋有味。一向宅男的我在我姐的怂恿下尝试了很多不一样生活的方式，并不是只有宅在家里才是活着（虽然在家里活着确实挺舒服的😂）。
\n在五一的节假日期间，我准备完简历与项目后开始找工作去，这一段的求职与就业的感悟故事我也记录了下来。
\n\n然而在工作了三个月后，我逐渐发现公司内部异常混乱。在这段时间里，我被卷入高管之间的内斗，沦为他们博弈的工具人。试用期结束时，不但被卡转正，还遭遇了疯狂的职场PUA和无止境的压榨。
\n就在我萌生离职念头时，没想到我的前领导竟然比我更快一步离职。而我却做出了一个让我至今懊悔的决定——接手前领导的活，还选择吃下老板画的大饼。在这种超负荷的状态最终只让我坚持了一个月。9月30日这一天，我终于下定决心递交了辞呈，给自己放了一个真正的长假。😇
\n期间所发生的故事尤为精彩，我也将其整理了下来，也算是给我的职业生涯增添了浓墨重彩的一笔。
\n至于说现在这个 AI 初创公司发展的如何，或许是在濒临倒闭的边缘，不过我现在只清晰地记得离职那天一刻无比愉悦的心情😆。
\n离职回到老家的我第一时间玩起了《黑神话·悟空》，之前玩的是《黑公司·牛马》。我特意为此购入了XBox手柄，只为离职之后的娱乐尽兴一把。
\n今年年初在朋友的怂恿下玩《荒野大镖客 2》。也是从这部作品刷新了我对游戏的认知，让我开始对这类游戏产生了浓厚兴趣，让我意识到游戏不仅仅是一个娱乐方式，更像是部电影、艺术，每一帧画面、每一段配乐、每一个剧情都蕴含着制作者的匠心。不仅是对自己兴趣的一次探索，也是一种对高品质游戏制作的致敬。
\n就当我即将结束我的长假之时，一则私信引起了我的注意。
\n![\"image.png\"](\"https://img.kuizuo.me/2024%2F1231181558-imageundefined1.png\")
对方看到我的技术栈与他的项目十分贴合，阅读了我职场故事会（原来写小作文真有用啊），便向我抛出橄榄枝，但当时的我还没那么想要再次进入工作状态，况且这家公司又是 AI 初创公司（我对初创公司已经有 PTSD 了，生怕再经历类似的职场故事🥲），所以当时的我对这份机会此挺无所谓的。
\n后面进一步的了解，发现是老板自己搞 B2B 的项目，不愿招外包，于是就在 X 上招聘，并找到了我。于是安排了场 2 小时视频通话，聊了聊我过往的项目经历，就这样拿到了该 Remote 的 Offer 😄，同时也多了一位美国朋友。
\n即便没有这个 Remote 机会，我也会选择尝试寻求其他海外的远程工作机会，因为我已经对坐班工作产生了厌倦感，我想要的更多是自由，而非束缚。
\n虽说是初创公司，但各种合同手续也都齐全，还是先发工资再干活（用老板的话讲就是：他先发薪资是我欠老板的，我先干活再拿钱是我欠老板的），时间上自由不少(就是要倒时差)， AI 工具服务必须齐全。本来还答应圣诞给我换台 Macbook，不过我还没到换设备的程度（其实是我觉得换设备迁移数据太麻烦了）。
\n业余时间的视频会议还让我看了真🔫，大🚬，这很🇺🇸特色。不过对我最不适应的还是来自于沟通而非技术。也让我深刻意识到了英语在远程工作，乃至未来职业发展的重要性。
\n去年这时候我对我未来的职业规划有所思考，其中就提到了远程工作。如今我确实达到了当初对职场的期望。
\n或许是因为过往的职场经历在简历上不够看，大厂经历或许能给职业生态添金，加上学历的自卑，总让我对大厂一直怀有向往。但当我与一些大厂员工的谈话之后，他们反倒羡慕我的远程工作生活，至少不用 996，不用坐班。或许这就是人们总是向往他人的生活，却不知对方的苦恼。
\n突如其来的变故致使我不得不马上搬家，正当决定新住所的时候，脑海里浮现直接回到老家生活并开始 Remote 工作的决定，并且还能迎接了我的新伙伴😽
\n![\"cat.png\"](\"https://img.kuizuo.me/2024%2F1231181558-imageundefined2.png\")
\n我一毕业就想养猫，但我姐的鼻子对味道特别敏感，与她同住就更不可能了（这才是我回老家的最大原因），因为搬家的变故，养猫成为了现实。
\n养猫让我身心舒畅，但也让我分心乏力。关于养猫的记录，我想过段时间经历了更多再做更细致的分享，是一篇劝退指南😿。
\n相比以往在大学期间自我摸索技术，今年尝试了很多之前不曾接触的事情。网友面基，参加技术大会，游玩方特，远程工作，养猫等等，相比之前大学期间只会宅在家里专研技术，却不懂的体验生活的我，或许是因为喜欢折腾的性格，也或许是因为大学期间的压抑，让我在现在更加渴望体验生活。
\n这一年，从独自摸索到与团队协作，从封闭的校园到远程工作，也让我逐渐认识到，技术只是工具，技术的提升可能是人生中最不起眼的东西，更有意义的是这个过程的体验、成长、感悟。
\n感谢自己愿意尝试未知，希望这份勇于尝试的心态让我始终保持热爱与激情。
\n直入正题，Next.js 自带的 API Routes (现已改名为 Route Handlers) 异常难用，例如当你需要编写一个 RESTful API 时，尤为痛苦
\n![\"image.png\"](\"https://img.kuizuo.me/2024%2F0930171329-image.png\")
这还没完，当你需要数据验证、错误处理、中间件等等功能，又得花费不小的功夫，所以 Next.js 的 API Route 更多是为你的全栈项目编写一些简易的 API 供外部服务，这也可能是为什么 Next.js 宁可设计 Server Action 也不愿为 API Route 提供传统后端的能力。
\n但不乏有人会想直接使用 Next.js 来编写这些复杂服务，恰好 Hono.js 便提供相关能力。
\n这篇文章就带你在 Next.js 项目中要如何接入 Hono，以及开发可能遇到的一些坑点并如何优化。
\n可以按照 官方的 cli 搭建或者照 next.js 模版 https://github.com/vercel/hono-nextjs 搭建，核心代码 app/api/[[...route]]/route.ts 的写法如下所示。
import { Hono } from 'hono'
import { handle } from 'hono/vercel'
const app = new Hono().basePath('/api')
app.get('/hello', (c) => {
return c.json({
message: 'Hello Next.js!',
})
})
export const GET = handle(app)
export const POST = handle(app)
export const PUT = handle(app)
export const DELETE = handle(app)
从 hono/vercel 导入的 handle 函数会将 app 实例下的所有请求方法导出，例如 GET、POST、PUT、DELETE 等。
一开始的 User CRUD 例子，则可以将其归属到一个文件内下，这里我不建议将后端业务代码放在 app/api 下，因为 Next.js 会自动扫描 app 下的文件夹，这可能会导致不必要的热更新，并且也不易于服务相关代码的拆分。而是在根目录下创建名为 server 的目录，并将有关后端服务的工具库(如 db、redis、zod)放置该目录下以便调用。
\n![\"image.png\"](\"https://img.kuizuo.me/2024%2F0930171342-imageundefined1.png\")
至此 next.js 的 api 接口都将由 hono.js 来接管，接下来只需要按照 Hono 的开发形态便可。
\nzod 可以说是 TS 生态下最优的数据验证器，hono 的 @hono/zod-validator 很好用，用起来也十分简单。
import { z } from 'zod'
import { zValidator } from '@hono/zod-validator'
import { Hono } from 'hono'
const paramSchema = z.object({
id: z.string().cuid(),
})
const jsonSchema = z.object({
status: z.boolean(),
})
const app = new Hono().put(
'/users/:id',
zValidator('param', paramSchema),
zValidator('json', jsonSchema),
(c) => {
const { id } = c.req.valid('param')
const { status } = c.req.valid('json')
// 逻辑代码...
return c.json({})
},
)
export default app
支持多种验证目标(param,query,json,header 等)，以及 TS 类型完备，这都不用多说。
\n但此时触发数据验证失败，响应的结果令人不是很满意。下图为访问 /api/todo/xxx 的响应结果（其中 xxx 不为 cuid 格式，因此抛出数据验证异常)
![\"image.png\"](\"https://img.kuizuo.me/2024%2F0930171510-imageundefined2.png\")
所返回的响应体是完整的 zodError 内容，并且状态码为 400
\n数据验证失败的状态码通常为 422
因为 zod-validator 默认以 json 格式返回整个 result，代码详见 zod-validator/src/index.ts#L68-L70
\n这就是坑点之一，返回给客户端的错误信息肯定不会是以这种格式。这里我将其更改为全局错误捕获，做法如下
\nserver/api/validator.ts，并将 return 语句更改为 throw 语句。 if (!result.success) {
- return c.json(result, 400)
}
if (!result.success) {
+ throw result.error
}
server/api/error.ts 中，编写 handleError 函数用于统一处理异常。（后文前端请求也需要统一处理异常）import { z } from 'zod'
import type { Context } from 'hono'
import { HTTPException } from 'hono/http-exception'
export function handleError(err: Error, c: Context): Response {
if (err instanceof z.ZodError) {
const firstError = err.errors[0]
return c.json(
{ code: 422, message: `\\`${firstError.path}\\`: ${firstError.message}` },
422,
)
}
// handle other error, e.g. ApiError
return c.json(
{
code: 500,
message: '出了点问题, 请稍后再试。',
},
{ status: 500 },
)
}
server/api/index.ts ，也就是 hono app 对象中绑定错误捕获。const app = new Hono().basePath('/api')
app.onError(handleError)
- import { zValidator } from '@hono/zod-validator'
+ import { zValidator } from '@/server/api/validator'
这样就将错误统一处理，响应体也自定义，且后续自定义业务错误也同样如此。
\n![\"\"](\"https://img.kuizuo.me/2024%2F1003095801-20241003095800.png\")
如果需要让 zod 支持中文错误提示，可以使用 zod-i18n-map
Hono 有个特性我很喜欢也很好用，可以像 TRPC 那样，导出一个 client 供前端直接调用，省去编写前端 api 调用代码以及对应的类型。
\n这里我不想在过多叙述 RPC(可见我之前所写有关 TRPC 的使用)，直接来说说有哪些注意点。
\n还是以 User CRUD 的代码为例，不难发现 .get .post .put 都是以链式调用的写法来写的，一旦拆分后，此时接口还是能够调用，但这将会丢失此时路由对应的类型，导致 client 无法使用获取正常类型，使用链式调用的 app 实例化对象则正常。
![\"image.png\"](\"https://img.kuizuo.me/2024%2F0930171730-imageundefined3.png\")
hono 自带的 fetch 或者说原生的 fetch 非常难用，为了针对业务错误统一处理，因此需要选用请求库来替换，这里我的选择是 ky，因为他的写法相对原生 fetch 更友好一些，并且不会破坏 hono 原有类型推导。
\n在 lib/api-client.ts 编写以下代码
import { AppType } from '@/server/api'
import { hc } from 'hono/client'
import ky from 'ky'
const baseUrl =
process.env.NODE_ENV === 'development'
? 'http://localhost:3000'
: process.env.NEXT_PUBLIC_APP_URL!
export const fetch = ky.extend({
hooks: {
afterResponse: [
async (_, __, response: Response) => {
if (response.ok) {
return response
} else {
throw await response.json()
}
},
],
},
})
export const client = hc<AppType>(baseUrl, {
fetch: fetch,
})
这里我是根据请求状态码来判断本次请求是否为异常，因此使用 response.ok，而响应体正好有 message 字段可直接用作 Error message 提示，这样就完成了前端请求异常处理。
\n至于说请求前自动添加协议头、请求后的数据转换，这就属于老生常谈的东西了，这里就不多赘述，根据实际需求编写即可。
\n配合 react-query 可以更好的获取类型安全。此写法与 tRPC 十分相似，相应代码 → Inferring Types
\n// hooks/users/use-user-create.ts
import { client } from '@/lib/api-client'
import { InferRequestType, InferResponseType } from 'hono/client'
import { useMutation } from '@tanstack/react-query'
import { toast } from 'sonner'
const $post = client.api.users.$post
type BodyType = InferRequestType<typeof $post>['json']
type ResponseType = InferResponseType<typeof $post>['data']
export const useUserCreate = () => {
return useMutation<ResponseType, Error, BodyType>({
mutationKey: ['create-user'],
mutationFn: async (json) => {
const { data } = await (await $post({ json })).json()
return data
},
onSuccess: (data) => {
toast.success('User created successfully')
},
onError: (error) => {
toast.error(error.message)
},
})
}
在 app/users/page.tsx 中的使用
'use client'
import { useUserCreate } from '@/features/users/use-user-create'
export default function UsersPage() {
const { mutate, isPending } = useUserCreate()
const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
e.preventDefault()
const formData = new FormData(e.currentTarget)
const name = formData.get('name') as string
const email = formData.get('email') as string
mutate({ name, email })
}
return (
<form onSubmit={handleSubmit}>
<div>
<label htmlFor='name'>Name:</label>
<input type='text' id='name' name='name' />
</div>
<div>
<label htmlFor='email'>Email:</label>
<input type='email' id='email' name='email' />
</div>
<button type='submit' disabled={isPending}>
Create User
</button>
</form>
)
}
\n\n这部分我已经弃坑了，没找到一个很好的方式为 Hono 写 OpenAPI 文档。不过对于 TS 全栈开发者，似乎也没必要编写 API 文档（接口自给自足），更何况还有 RPC 这样的黑科技，不担心接口的请求参数与响应接口。
\n
如果你真要写，那我说说几个我遇到的坑，也是我弃坑的原因。
\n首先就是写法上，你需要将所有的 Hono 替换成 OpenAPIHono (来自 @hono/zod-openapi， 其中 zod 实例 z 也是)。以下是官方的示例代码，我将其整合到一个文件内
\nimport { createRoute, OpenAPIHono, z } from '@hono/zod-openapi'
import { swaggerUI } from '@hono/swagger-ui'
const app = new OpenAPIHono()
const ParamsSchema = z.object({
id: z
.string()
.min(3)
.openapi({
param: {
name: 'id',
in: 'path',
},
example: '123',
}),
})
const UserSchema = z
.object({
id: z.string().openapi({ example: '123' }),
name: z.string().openapi({ example: 'John Doe' }),
})
.openapi('User')
const route = createRoute({
method: 'get',
path: '/api/users/{id}',
request: {
params: ParamsSchema,
},
responses: {
200: {
content: {
'application/json': {
schema: UserSchema,
},
},
description: 'Retrieve the user',
},
},
})
app.openapi(route, async (c) => {
const { id } = c.req.valid('param')
// 逻辑代码...
const user = {
id,
name: 'Ultra-man',
}
return c.json(user)
})
从上述代码的可读性来看，第一眼你很难看到清晰的看出这个接口到底是什么请求方法、请求路径，并且在写法上需要使用 .openapi 方法，传入一个由 createRoute 所创建的 router 对象。并且写法上不是在原有基础上扩展，已有的代码想要通过代码优先的方式来编写 OpenAPI 文档将要花费不小的工程，这也是我为何不推荐的原因。
定义完接口(路由)之后，只需要通过 app.doc 方法与 swaggerUI 函数，访问 /api/doc 查看 OpenAPI 的 JSON 数据，以及访问 /api/ui 查看 Swagger 界面。
\nimport { swaggerUI } from '@hono/swagger-ui'
app.doc('/api/doc', {
openapi: '3.0.0',
info: {
version: '1.0.0',
title: 'Demo API',
},
})
app.get('/api/ui', swaggerUI({ url: '/api/doc' }))
![\"image.png\"](\"https://img.kuizuo.me/2024%2F0930171730-imageundefined4.png\")
从目前来看，OpenAPI 文档的生成仍面临挑战。我们期待 Hono 未来能推出一个功能，可以根据 app 下的路由自动生成接口文档（相关Issue已存在）。
\n附上本文中示例 demo 仓库链接（这个项目就不搞线上访问了）
\nhttps://github.com/kuizuo/nextjs-with-hono
\n其实我还想写写 Auth、DB 这些服务集成的(这些都在我实际工作中实践并应用了)，或许是太久未写 Blog 导致手生了不少，这篇文章也是断断续续写了好几天。后续我将会出一版完整的我个人的 Nextjs 与 Hono 的最佳实践模版。
\n也说说我为什么会选用 Hono.js 作为后端服务, 其实就是 Next.js 的 API Route 实在是太难用了，加之轻量化，你完全可以将整个 Nextjs + Hono 服务部署在 Vercel 上，并且还能用上 Edge Functions 的特性。(就是有点小贵)
\n但不过从我的 Nest.js 开发经验来看（也可能是习惯了 Spring Boot 那套三层架构开发形态），总觉得 Hono 差了点意思，说不出来的体验，可能这就是所谓的全栈框架的开发感受吧。
", "url": "https://kuizuo.me/blog/nextjs-with-hono", "title": "Next.js 使用 Hono 接管 API", "summary": "这篇文章详细介绍了如何在 Next.js 项目中使用 Hono 框架来接管 API 路由，以解决 Next.js 自带 API Routes 功能的限制。并探讨了集成步骤、数据验证、错误处理、RPC功能等方面，并提供了实用的代码示例和优化建议。", "date_modified": "2024-10-02T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "nextjs", "honojs" ] }, { "id": "https://kuizuo.me/blog/experience-of-an-ai-company", "content_html": "作者已于 9 月 30 日离职，以下内容只发生于入职后的 1 个月，之后就过着如同牛马般的生活，日子又开始没有盼头了😔。
已经在一家 AI 公司入职了一个月，对坐班有些厌恶的我，没想到有一天也会开始通勤打卡。而经历了这一个月的工作，我对坐班的态度有所转变，开始理解这种工作方式对我的意义。是时候分享入职这期间的工作内容与感受。
\n直入正题，先说职位背景。该职位的技术要求大致如下，仅做参考。
\n## 任职要求
1. 本科及以上学历，计算机科学、软件工程等相关专业, 硕士优先；
2. 扎实的 HTML、CSS、JavaScript 基础(vanilla) 功底 ；
3. 熟练使用 React、React Native 和 Next.js 进行前端开发
4. 了解前端性能优化技术，如代码压缩、懒加载等
5. 熟悉前端工程化工具
6. 具备良好的问题解决能力和团队协作精神
7. 熟练阅读英文技术文档
8. 有优异前端项目开发经验者优先
## 加分项：
- 贡献开源社区
- 有 AI 相关项目经验。
- 有前端性能优化和 SEO 优化经验。
- 有良好的产品思维和设计(UI/UX)意识。
- 有同理心思维。
- 具有一定的审美感。
很贴合国外主流的技术栈（至于为何，看后文便知），比较巧的是，我的 Web 全栈学习路线就是偏国外的技术栈。因此在技术栈上，这家公司是我喜欢的，恰巧又是 AI 开发，能让我尝试到一些前沿技术，也正好是想我折腾的。
\n我是 Boss 直聘上找的（这里没给 boss 直聘打广告，我甚至还是第一次使用 boss 直聘），我有想过找人内推，但由于家庭因素被限定在福州这座城市，而内推的所在的城市往往都是那些一线城市，加上我的八股文和算法很不过关（我也很不情愿刷），到时候面试那关估计也不乐观。
\n因此就在 Boss 上碰碰运气，也顺带体验一下新人都是怎么找工作的。
\n从五一的时候开始准备简历和项目，在5号开始投简历，投递简历一关我是直接怼着工作经验1-3年的来投，而不是投应届或实习岗。因为我确实有一些工作经验，只不过不是正常的坐班打卡的形式，这在之前的博客中有说到。
\n在这期间共投了20多家，基本都是已读不回，就更别说投递简历了。后来我才了解到，原来 HR 回复消息是要花钱的，发布一个岗位也是。
\n唯一回复的还是我现在入职的这家，而且我还投了两份过去，一份是给 HR 的（没回），一份是给技术 leader 的（leader 回了）。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-Untitled.png\")
可能是由于当时这个岗位急招的原因，在 boss 直聘上也没多说什么，leader 就约明早 11 点来公司现场初步面试聊天一下。这期间还发生了一个小变故，我到公司了，可联系不上面试官，打了微信电话也无果。待了10来分钟后我就走了，等了约一个小时都没信息，那我大概率是被鸽了，还不提前和我通知一声，然后在boss上留下了这句评价🥲。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-1a520a5a-c3b9-4049-bfcf-825113aa7b2c.png\")
初入职场，初次面试就这种情况，说真的我当时都有点心灰意冷了，我猜想是不是因为有其他合适的人选，于是就不招我了，就连信息也不给我打一个招呼，相当于把我拉黑似得。随后我就到附近的麦当劳花了 10 元的套餐安慰了一下自己，麦！
\n直到到下午一点多的时候，面试官回复我说当时他们在开会，期间不让携带电子设备。早上就当一面过了，问我下午有没有时间，直接二面技术面(code test)过了就直接拿offer。
\n这时我才知道，原来早上也仅仅只是我的猜想，但我还是有点不想去了，心情有点不太愉悦，但想了想也懒得计较了，过去就当聊天罢了。到了下午面试问的就偏前端基础、八股文那些问题，其实我回答的巨烂，确实也没好好刷题，也不喜欢刷题，就面试了。自己写代码是由业务环境下驱动的，并从中寻求最佳实践。但好在我的技术面是比较广的，很多前沿的前端相关的工具库或多或少都使用过，也能侃侃而谈，加上个人 blog 和 github 这两个大加分项。就进入到了一个代码考核测试，不限框架，不限规则，使用公司的电脑打开 codesandbox 写一个todo list，前提是不使用任何 AI 工具。
\n这不正好到了我的强项，之前学某个框架的时候，不知道写什么demo，就写 todo list 来练手😂。恰好这次我就使用 next.js app router + Tailwindcss 的模版并且使用 form 标签的 action 和 use server 来实现新增功能。 能体现出我有在使用 next.js，而且用上了一些新特性，就拿到 offer 了。
\n![\"1000047893.jpg\"](\"https://img.kuizuo.me/2024/0611021351-03100cc0-2b0a-4049-82ed-58cc46ac1717.png\")
听完之后是不是莫名的感觉这个 offer 拿的好像有点莫名其妙的感觉😂，不管怎么样结果是好的就行了。
\n不过拿到 offer 后，我并没有选择马上入职，经历了一次被鸽的经历，对该公司的印象带有一些怀疑。其次就是这是一家初创 AI 公司，规模不大，从应届生找工作的角度，第一份正式的工作的起点很关键，如果能直接进大厂，后续跳槽到其他公司大概率也不成问题。
\n但在当地我投递了 20 多家已读不回的情况下，加上这份已有的 offer 不等人（急招），加上我家里人给我推荐的工作内容我并不是很满意，于是思考了两天，最终还是选择入职了这家公司。
\n比较令我差异的是我与企业签订的直接劳动合同，可能是因为我直接投递 1-3 年的工作经验，但我此时的身份还是应届生，按理来说我应该是签订实习合同后，转正再签劳动合同，难道说我已经提前转正了？。不过也好，这样和学校的三方协议都可以不用签了，直接给劳动合同便可。
试用期 3 个月，薪资打 8 折。薪资在我当地还算 ok，但对于我而言并不理想。可能是会的比较多(全栈？全干！)，加上曾经赚过比这还高上许多的薪资，从内心的角度多少是有些不平衡。不过目前还是试用期，薪资这方面后续也能再谈。
接下来尤为重要的上班体验才是让我觉得没后悔入职这家公司。
\n介绍一下公司部门的办公工具
\n办公管理：企业微信
\n团队协作：Slack
\n任务看板：Trello
\n代码仓库：Github
\n代码托管：Vercel
\n视频会议：Zoom
\n你会发现除了企业微信，其他的应用都是国外的。怎么看都不是一家国内的企业吧，这是因为我部门的 Leader 是海外留学的，这也就不难理解工具是国外应用，技术栈选型是 React 生态了。
\n入职的第一周部门开了个小会，就是简单介绍了一下部门的任务职责，每个成员自我介绍。重点是提供一个优质的学习环境，像是技术书籍，电子设备，UI 模版或是技术会议的门票等费用，只要对部门有利，能提升自己，都可以找他报销。
\n我已经找 Leader 报销了个 magic ui pro，大约 420 块，直接找财务刷卡，付款的感觉是真爽，我是真爱了🥰。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-Untitled%201.png\")
几天后，公司来了一个阿里做 B 端低代码开发的同事，也是负责前端开发，这不，我可以间接和这个老哥那学习大厂相关经验，我还正愁着没大厂相关的经验😄。
\n我询问他来这家公司的原因，他说被裁了，在家接外包一年了，不稳定就准备找工作，恰好这家公司急招，于是就来了。
\n端午节后，这位老哥提离职了，原因的话我就不具体说了，可能是因为年龄大了，不适合坐班了。虽然早有预感，但还是有点不舍。因为现在部门的前端重任都在我这了😭
在我入职的第一周周末 Leader 为整个部门安排团建，由于这个部门成立不到 2 周，来的都是新成员，让我们自己组个局，去外面吃个饭。
\n也是在团建的时候了解到同事的履历一个个都不简单，有 985 的，有海外留学的，有在阿里、网易待过的，还有我这不堪回首的经历 🤡。
\n后面原定在 61 安排整个公司的团建，但由于天气和周末时间去的人少的因素而取消了，这我就不多说了。
\n端午之后的第一个工作日的中午，补过端午节部门聚餐的，这我也不多说了。就是怎么感觉这频率有点不太对，然后实际项目产出也还停留在 Spring 1 的阶段，让我有些不自在。
\n部门每个月都会定一个最佳员工奖，我很荣幸获得部门本月的最佳员工，也感谢部门成员的认可，奖励是 300 元奖金或一日自由假。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-Untitled%202.png\")
甚至还有一张奖状，就是这奖状怎么有点像给小学生似的。（事后我才了解到这奖状还是用打印机打印的😂）
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-0da32f2a-c077-42c9-8a57-fff9f259187e.png\")
目前我已经能感受到最大的福利就是那个 magicui 动效库的模版，当然了，这个是要给公司的官网用上的，我也是蹭公司的福，给自己的站点用上了这个动效库。
\n此外像节日福利，如这次端午节，就是聚餐和发粽子，这也就没什么好说的。
\n公司距离我租房的地方只有 2 公里，每日的通勤总时间大约 40 分钟，早上大约 8 点起床，我通常坐公交车到公司附近的早餐店吃个早饭，吃完差不多 8 点 40分~50 分。中午外卖就不说了。下午下班从公交车和走路做个选择，吃完饭回到家。
\n黑客松(hackathon)，也称编程马拉松比赛。我是第一次听说过这个词，Leader 给定两个选题一个是打造某市地铁智能出行，另一个是给某商场的提供贴心的购物体验，发挥自己近一个月所学的知识，去创造一个供用户使用的 AI 程序，月底交付，奖金 3000 元/小组，抽签分组。我们当时部门有个人提了一嘴，要不我们两小组自己商量一下，把奖金平分得了😂。
\n不过对于这个行为，我个人认为目的是为了激励员工之间协同合作，但同时也免不了技术上的内耗，毕竟这个比赛不是我们的主要工作内容。
\n我想肯定有很多人对 AI 开发的刻板印象是要会大模型开发，会懂得微调，会懂得人工智能算法。这个想法也没错，但从开发 AI 应用的角度，其实蛮需要前端的，尤其是会全栈框架的前端。
\n这里我不得不惊叹 next.js 的生态，很多 AI 相关的例子可以直接从 Vercel 的 AI Template 下学习，预览是否有你需要的功能，Clone 到本地，然后运行项目，对某些部分进行更改。搭建 AI 应用也是异常的快。
\nLeader 下发的一个任务，入职的前两周主要让我熟悉一些怎么使用 next.js 配合 vercel 的 ai sdk 来开发 AI 应用，如怎么调用 openai 的模型，实现一个 ai chatbot。给定了一个任务就是仿造 AI SDK，由于该项目没有开源，自然就只能另辟蹊径。
\n首先就是仿造页面了，这个作为前端开发，实现起来也算容易，更何况这个这个页面的样式使用 Tailwindcss 编写，直接通过审查元素仿造就行了。
\n其次在功能实现上，ai sdk 文档都提供了非常完善的解决方案，照着文档将代码稍微改写一下便可，具体的细节就不演示了。
\n两周后开始正式项目开发了，首当其冲的就是官网页。
\n这里当时 Leader 问我有没有用过 Gatsbyjs，要用这个框架搭建一个官网。我表明我没用过，但我提了一嘴如果要搭建偏内容向的网站，可以考虑 Astro，我愿意折腾一番（我也一直想学 Astro 的）。不过最终在开发时间和成本的商讨下还是选择使用 next.js 来搭建，leader 还顺带给我推荐了一个动效库 magicui，叫我看看里面的案例，看看能不能给官网加点动效。 之后就有了上文提到报销 magicui 的事。
\n篇幅实在有限，有关 RAG 的不做过多解释，它可以让你的 AI 应用更具有权威性，让数据的来源可靠，而非胡乱生成数据。
\nRAG 的基本流程就是：
\n在这个应用开发中，借鉴了 ragbot-starter 这个开源项目，同时向量数据库选用 datastax 公司的Astra DB。
\n恰好在开发这个应用的期间，我也正好在学习 Langchain.js，所以在数据处理这部分有点得心应手，目前应用还只停留在处理本地文件或用户上传的文件，只需要配置各种 File Loader 便可。
\n先看 Gif 效果。
\n![\"demo\"](\"https://img.kuizuo.me/2024/0612203208-demo.gif\")
第一次用 Screen Studio，显示的不是很好，还请见谅，主要就是实现一个流式文本效果。
\n这里简单说下怎么实现的，就用 react-native-reusables 的模版(React native 的 Shadcn/ui) + react-native-gen-ui 实现的，不过后者的功能比较单一，后续估计要改代码了。代码就不贴了，我怕涉嫌代码泄露（其实已经泄露差不多了）。
\n要我说最大的收获不是遇到一个氛围不错的公司，遇到一个好 leader，也不是接触 AI 开发从中学到了什么，更不是增进了我的技术栈。而是让我养成良好的习惯，开始正常一日三餐，开始作息规律，开始将工作与生活分离，身体状态也渐渐好了起来。
\n下图为 5 月的生物作息，基本都保持 0 点前入睡。（不过在我写这篇文章的时候已经两点了🥱）
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0611021351-Untitled%203.png\")
过去几年内我的作息与饮食都非常糟糕，能明显的感觉到状态有所下滑，编写代码的效率和能力也明显不如以前，有些力不从心。今年都快过去一半了，而我仅仅完成了2篇博文的写作，文章的输出效率明显不行😮💨。
\n在半年前我对自己当时的现状做了个分析，幻想着坐班或许能改变我当下的现状。如今经历了这一个月的坐班生活，可能是因为坐班而改变，也可能是公司的氛围，不管是那种，让我跳出我原有舒适区，重新拾起对新颖事物的兴趣，重新点燃学习某个技术的热情，重新找回了自我。
\n在我还没找工作之前，从我几个同届毕业的同学和网友的反馈得知今年的就业环境异常险峻。不仅如此，我还在网络上看到了大量工作者对自身工作的抱怨与不满，这些现象让我在工作前让我对未来的就业前景感到了一些不安。
\n当我亲身入局感受一番，也不禁开始低声叹气。开始思考是什么原因导致了如今大环境不好的现象，人为的制造就业焦虑，还是当下现实本就如此。当我跳出思考，回到现实难道环境好就一定挣钱多，环境差就一定挣钱少吗？社会似乎并不是这么简单的等式。
\n我逐渐意识到，无论大环境如何，每个人的努力和选择仍是至关重要。在面对不确定性和挑战时，保持学习和进步的态度，以及寻找自己的核心竞争力，才是应对困境的关键。
\n真正的职业安全感并不完全来自于外部环境，而是来自于我们自身不断提升的能力和适应变化的灵活性。
", "url": "https://kuizuo.me/blog/experience-of-an-ai-company", "title": "记 · 在 AI 公司入职一个月的体验与感悟", "summary": "这篇文章分享了作者在一家 AI 公司入职一个月的心得和体会，包括工作中的挑战与成长。", "date_modified": "2024-06-10T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "AI", "工作", "记录" ] }, { "id": "https://kuizuo.me/blog/react-native-develop-experience", "content_html": "最近研究了一下 React Native(简称RN)，并用它作为毕设项目（一个仿小红书的校园社交应用）。经过一段时间的折腾，对 RN 生态有了一些了解，是时候可以分享一些心得了。
\n代码仓库： https://github.com/kuizuo/youni
\n很简单，就是技术栈问题。从开发角度而言，尤其还是对于前端开发人员，会 JS 且搞过 React ，那 RN 上手就十分友好，最起码有关 React 社区的逻辑库或状态库是可以使用的。
\n虽说 Flutter 的性能是会比 RN 好上不少，但抛开需求不谈，与其比性能不如比开发速度。很显然开发 RN 的效率比 开发 Flutter 高上不少。况且真在意性能的话，那多半就不会考虑跨平台技术了，而是直接考虑原生开发了。
\n再从需求考量，我所编写的应用更偏向于内容展示的 app，而不是编写一个手机电池监控或者内存监控的app，如果是后者，那这时选择任何跨平台开发都没有意义，像这些系统级别的API在跨平台开发基本不太可能实现的。
\n对于这两个跨平台技术的选择，应该考虑自身需求、开发成本、技术选型，没有最好的只有最适合的。如果有的选择，谁不会选择原生开发是吧。
\n但凭我自己接触 RN 以来，国内的 RN 资源甚少，反倒是 Flutter 资源很多，并且从这些相关资料来看，确实 Flutter 优于 RN，但还是那句话，这里就不再过多赘述了。
\n先说一个结论：RN ≠ 原生，别指望会个 react 就能写出靠谱的原生应用。
\n就从我的开发经历来说，坑是真的多，但好在RN拥有庞大的线上社区，可以找到的几乎所有问题的答案。但国内的社区好像并不是很好，很多问题我都是在国外论坛中解决的。
\n如果你学习它是为了扩展其他平台的开发能力，那么还是可以学习一番的，会有另一番的收获。但如果学 RN 只是为了避免不用学 android 和 iOS 等原生技术就能写 app，那便不建议学习。抱着这心态的话前期开发可能不明显，但到了后面会踩很多坑，而且两眼一黑，因为你不懂 native 开发。
\n我的个人评价是 RN 只能作为 H5 手机页面运行在原生移动设备的一种展示形态。虽然本质不是，但其所展示的效果如同。RN 不仅仅只是 Web，但也止步于 Web。
\n顺带吐槽一番，React-Native 项目发布4年多了，还没有 1.0 版本么(¬_¬)
\n如果你想再继续了解 RN，那么就请往下看。
\nExpo 是基于 React Native 并整合大量常用的 native module(Expo SDK)，像原生的功能如相册，相机，蓝牙等功能，在 expo 都是直接集成的，相当于封装原生的api，暴露给js调用。因此你不用去了解原生开发的许多知识和坑点，上手即用便可。本地配置好应用所需的环境，就直接直接运行 RN 项目，开发十分方便。
\n此外 Expo 还提供了 Expo Go App，只需要在你的移动端设备中安装它，启动开发服务器并生成 QR 码。在浏览器打开 snack.expo.dev ，点击 MyDevice，扫码并在 Expo app 中查看。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0514104918-Untitled.png\")
会自动将该程序实时运行在你的移动端设备，意味着你更改代码也将会同步到Expo go 中。极大程度上提升 RN 的开发体验，尤其是在真机测试阶段。
\nExpo 官方还贴心的提供了云服务 Expo Application Services (EAS)，意为这你可以你可以将你的 RN 项目在托管在云服务上，来执行构建与发布等流程。
\n总之如今开发 RN 请毫不犹豫的使用上 Expo。
\n实际开发中所遇到的坑点远不止下述所说，这里只列举几个相对有代表，坑比较深的点。甚至有很多坑都不是前端方面的知识了。
\n错误提示：Error: Unable to resolve module ./nxode_modules/expo/AppEntry
\n解决方案：在项目根目录创建 .npmrc ，内容如下
shamefully-hoist=true
node-linker=hoisted
删除 node_modules 与 .expo 文件夹，重新安装依赖即可。
\n相关链接：https://github.com/expo/expo/issues/9591#issuecomment-1485871356
\n在样式方面与传统的 Web 开发存在一定的区别。在 RN 中有两个主要组件，View 与 Text，可以理解为 Web 的 div 与 span。基本所有的 View 都是 flex 布局，想要让 View 组件占满通常不会使用 width: ’100%’ 或 height: ‘100%’，而是使用 flex: 1，例如一般都会带上这么一个样式。
\n<View style={{ felx: 1 }}>
如果样式问题就只是这样就好了，同一套样式在不同平台上所展示的效果都可能不大一样，尤其使用原生 Web 的样式，哪怕你用 style 编写，在 Web 网页也能成功显示效果，但是在 IOS 与 Android 中绝大多数情况下是不显示的。这会在后面介绍 Tailwindcss 相关库的时候会额外在提到一点。
\n如果不怎么做的话，会报错，如果只是这样倒还没什么。重点是错误提示并没有堆栈信息！就如下图所示
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0514104918-Untitled%201.png\")
这点对于开发体验而言并不友好。
\n由于一开始是在 Web 端进行调试开发的，所以没留意到这个问题，直到切换到安卓模拟器之后发现模拟器无法请求本地后端服务，在IOS 端暂无这问题。因此需要做如下配置：
\n1、首先将模拟器内网切换到本地。
\n假设后端 api 地址为 [http://localhost:6001](http://localhost:6001)，正常情况下，开发环境下的调试主机可以通过如下方式获取
import Constants from 'expo-constants'
const debuggerHost = Constants.expoConfig?.hostUri
// 192.168.123.233:8081
接着所要做的就是将 192.168.123.233:8081 替换成我们的目标端口 192.168.123.233:6001
\n这里以 axios 为例， 先为环境变量添加 EXPO_PUBLIC_API_URL=http://localhost:6001，具体替换的代码如下所示
export const client = axios.create({
baseURL: getApiUrl(),
timeout: 5000,
})
export function getApiUrl() {
const apiUrl = process.env.EXPO_PUBLIC_API_URL
return replaceLocalhost(apiUrl)
}
export function getLocalhost() {
if (localhost !== undefined) return localhost
const debuggerHost = Constants.expoConfig?.hostUri
// 192.168.123.233:8081
localhost = debuggerHost?.split(':')[0] ?? 'localhost'
return localhost
}
export function replaceLocalhost(address: string) {
const PROTOCOL = 'http:'
const localhostRegex = new RegExp(`${PROTOCOL}\\/\\/localhost:`, 'g')
return address.replace(localhostRegex, () => `${PROTOCOL}//${getLocalhost()}:`)
}
2、端口转发
\n此外还需要执行以下命令转发端口。
\nadb reverse tcp:6001 tcp:6001
此时安卓模拟器便可正常请求本地后端服务的资源，IOS 端并未有该问题。
\n如今在 UI 的选择上，我是毫不犹豫选择 Tailwindcss，在 RN 使用 Tailwindcss 有两个库可以作为选择 nativewind 和 twrnc。
\nnativewind 采用 Web 的 className 属性，其用法如同 Web 开发使用 Tailwindcss 的写法，这里便不过多展示了。
\ntwrnc 的写法则有些不同，需要通过 tw 包装，然后填写到 style 中，就如下图所示
\nimport { View, Text } from 'react-native'
import tw from 'twrnc'
const MyComponent = () => (
<View style={tw`p-4 android:pt-2 bg-white dark:bg-black`}>
<Text style={tw`text-md text-black dark:text-white`}>Hello World</Text>
</View>
)
但要值得注意的是，由于 RN 的组件样式中并不是完全兼容 Web 端，就比如说你想实现毛玻璃效果，通过 backdrop-blur 原子类就可以轻松实现，但是在原生移动端并不能生效，其原因就是原生组件的 View 并没有毛玻璃效果，想要实现则需要使用 expo-blur 这个库。
事实上有很多 Web 端支持的类，在移动端并不能生效，通常来说只适合用 Tailwindcss 来编写基本的宽高，内外边距等样式。
\n从 Web 开发使用的角度，nativewind 会更好用一些， npm 实际使用量也确实比 twrnc 来的多，但要在一些情况下，比如给第三方组件更改 props 的样式情况下就会没有 twrnc 那么直观了，例如一些第三方组件有 xxxStyle 属性，例如 contentContainerStyle，这时 twrnc 就方便很多。
\n<FlatList style={tw`flex-1`} contentContainerStyle={tw`p-4`} />
而 nativewind 则繁琐许多，下图例子。
\n// This component has two 'style' props
function ThirdPartyComponent({ style, contentContainerStyle, ...props }) {
return <FlatList style={style} contentContainerStyle={contentContainerStyle} {...props} />
}
// Call this once at the entry point of your app
remapProps(ThirdPartyComponent, {
className: 'style',
contentContainerClassName: 'contentContainerStyle',
})
// Now you can use the component with NativeWind
<ThirdPartyComponent className=\"p-5\" contentContainerClassName=\"p-2\" />
再者，twrnc 可以使用动态变量，例如在 RN 中经常需要处理安全区域，如下写法在 twrnc 就支持，但 nativewind 则不生效。
\nconst { top } = useSafeAreaInsets();
<View style={tw`pt-[${top}]`}> // twrnc 支持
<View className={`pt-[${top}]`}> // nativewind 不支持
我便提一下 tamagui 这个组件库。tamagui 看似很炫酷，但是实际配置的过程异常的繁琐，用起来也没有特别舒服，可以看以下示例代码。
\n<XStack flex={1} justifyContent=\"center\" alignItems=\"center\" gap=\"$2\">
<Button size=\"$3\" theme=\"active\">
Active
</Button>
<Button size=\"$3\" variant=\"outlined\">
Outlined
</Button>
</XStack>
其效果就是一个容器内包含两个按钮，样式编写上则通过 prop 属性来实现，用过 unocss 的 Attributify Mode 应该会有些许熟悉，但还不那么一样。
\n并且他的主题系统使用极其的怪，采用 $number 的形式来定义尺寸(官方称 token)，重点是宽高和边距采用相同的 token 效果还不一样，贴个图。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0514104918-Untitled%202.png\")
但他的颜色更是一言难尽了，从 color0 到 color11 的效果就如下图
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0514104918-Untitled%203.png\")
可能是因为我用惯了 Tailwindcss 那套颜色系统，所以很不能理解这套颜色系统，并且在我实际编写组件的过程也是异常的奇怪。
\n但最让我想吐槽的是官方还为此提供了一个主题系统配置的生成器网站，但只有 tamagui 的赞助者才能够使用，如果想要自己定义一个主题，就需要配置特别多的文件，总之就是很难用就对了。
\n顺带在贴一张 Provider 嵌套
\n![\"provider\"](\"https://img.kuizuo.me/2024/0514171536-0514092451-202405140924689.png\")
这里我就不得不提到我为啥一开始选用 tamagui 了(现已迁移到 gluestack-ui)，说实话我是有点后悔的，在一开始选定 UI 库的时候，我是选择 NativeWind 的，但后面无意刷到了 T4-stack (算是被他坑了)，而它所用的便是 tamagui，并且一套代码跑 expo 与 next.js。于是便采用相同的项目结构以及 UI 库了。但事实上在我编写的过程中，想要一套代码就能实现跨三端(web,android,ios) 效果并不佳了，这在下一章便会说到。
\n首先它与 tamagui 相似，也采用 token 的方式来定义尺寸样式，但该库所对标的 token 设计就是Tailwindcss。此外该 UI 提供 NativeWind 的定制方案，意味着你的项目中可以集成了 NativeWind 用 Tailwindcss 的方式编写组件(类似 shadcn/ui)，并且还在 X 上表示 gluestack-ui + NativeWind 组合就是 React Native 的 shadcn/ui。
\n因此我个人是比较看好的，不过目前该库目前还处于 Alpha 阶段，可以持续观望中。这个也是我目前最值得推荐的组件库。
\n如果你想要在 React Native 和 Next.js 应用程序共享代码(UI，逻辑)，你可以考虑使用 solito。该库的写法上会更偏向于 next 的写法，举个例子。
\n比如说 Image 组件在 RN 写法如下
\nimport { Image } from 'react-native'
<Image
style={styles.xxx}
source={{
uri: 'https://beatgig.com/image.png',
}}
/>
next.js 的写法
\nimport Image from 'next/image'
<Image src=\"https://beatgig.com/image.png\" width={100} height={100} />
solito 的写法
\nimport { SolitoImage } from 'solito/image'
<SolitoImage src=\"https://beatgig.com/image.png\" height={100} width={100} />
这样 SolitoImage 会判断当前的仓库是 next.js 项目还是 RN 项目对不同的平台进行渲染，以做到同一个组件跨平台的开发，像 Link、useRouter 都是类似用法。
不过当你想要共享代码时，此时就必须得上 monorepo 了，通常目录结构如下图所示，你也可以到这个仓库中查看。
\n├── apps
│ ├── expo
│ └── next
├── packages
│ └── app
│ ├── features
│ ├── index.ts
│ ├── layouts
│ ├── package.json
│ ├── provider
│ └── screens
├── turbo.json
└── package.json
packages/app 存放主要的公共业务代码，在 next 和 expo 中则直接通过 @xxx/app 子包来导入，具体可看代码，这里就不做过多介绍了。
不同平台之间必然会存在一定的开发差异，expo 也提供了相应的解决方案，可以通过给文件添加不同的后缀扩展(.web .android .ios) 以在对应平台执行对应文件，官方文档 Platform specific extensions
\n这里只会介绍这个库的用途，至于为什么选择这个而不是其他的，不想做过多的篇幅来解释。如果你用过比这更好的库，也可相互交流。
\n底部窗口，效果如图
\n![\"https://raw.githubusercontent.com/gorhom/react-native-bottom-sheet/HEAD/preview.gif\"](\"https://raw.githubusercontent.com/gorhom/react-native-bottom-sheet/HEAD/preview.gif\")
一个高性能的列表，可替代 RN 的 FlatList，其中它还支持如下图布局。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0514104918-Untitled%204.png\")
toast 消息组件，轻量简单易用。
\n![\"https://github.com/calintamas/react-native-toast-message/raw/main/docs/toast.gif\"](\"https://github.com/calintamas/react-native-toast-message/raw/main/docs/toast.gif\")
如果你觉得所编写的 RN 应用没有触摸反馈效果，那么可能需要尝试使用 这个库。例如，你可以使用 RectButton 来包装子元素来实现点击按钮波纹反馈效果。如下图所示
\n![\"https://docs.swmansion.com/react-native-gesture-handler/gifs/samplebutton.gif\"](\"https://docs.swmansion.com/react-native-gesture-handler/gifs/samplebutton.gif\")
此外像拖动组件、滑动删除、放大缩小图片等常见的手势操作，总之这个库都可以实现。
\n\nRN 动画库，没啥好说的。
\n以上组件库可以说基本必装，能为 RN 应用使用体验提升一个档次。
\n分享一些我在编写 RN 中的一些案例。该说不说，RN 的生态是真的可以，很多原生的解决办法几乎都有。
\n在这个库你可以实现几乎所有的原生布局，如底部 tabs，左侧抽屉等，expo 是在此基础上进行包装的。
\n![\"https://docs.expo.dev/static/images/expo-router/tabs.png\"](\"https://docs.expo.dev/static/images/expo-router/tabs.png\")
Expo 自带案例，实现效果也简单，这里不在赘述了。
\nhttps://reactnavigation.org/assets/navigators/drawer/drawer.mp4
\nexpo 官方所提供的左侧抽屉是带导航的，也就是说你无法同时使用底部选项和左侧抽屉两个布局效果。因此想要同时使用这两种布局，就要使用 Drawer Layout，这里分享我个人的实现过程。
\n首先，编写 DrawerContainer 组件，代码如下
\nimport { Drawer } from 'react-native-drawer-layout'
import { useDrawerOpen } from '@/atoms/drawer'
import CustomDrawerContent from './CustomDrawerContent'
export function DrawerContainer({ children }: { children: React.ReactNode }) {
const [open, setOpen] = useDrawerOpen()
return (
<Drawer
open={open}
onOpen={() => setOpen(true)}
onClose={() => setOpen(false)}
swipeEnabled={false}
renderDrawerContent={() => <CustomDrawerContent></CustomDrawerContent>}
>
{children}
</Drawer>
)
}
如果想要定制化左侧菜单就必须使用 CustomDrawerContent，这里贴相关代码
\nimport { DrawerContentScrollView, DrawerItem } from '@react-navigation/drawer'
export default function CustomDrawerContent() {
return (
<DrawerContentScrollView
scrollEnabled={false}
contentContainerStyle={{
flexGrow: 1,
}}
>
{/* <DrawerItemList {...props} /> */}
<View className=\"flex-1 mx-2\">
<DrawerItem
label=\"子项 1\"
onPress={() => { }}
/>
<DrawerItem
label=\"子项 2\"
onPress={() => { }}
/>
{/* ... */}
</VStack>
</DrawerContentScrollView>
)
}
最后在 app/_layout.tsx 中用 DrawerContainer 包装一下 Stack，如下代码。
\nimport { Stack } from 'expo-router'
import { Provider } from '@/provider'
import { DrawerContainer } from '@/components/DrawerContainer'
export default function RootLayout() {
return (
<Provider>
<DrawerContainer>
<Stack
screenOptions={{
headerShown: false,
}}
></Stack>
</DrawerContainer>
</Provider>
)
}
此时就可以用 useDrawerOpen（这里状态库选用 jotai）来控制左侧菜单的展开了。
\n![\"https://reactnavigation.org/assets/libraries/tab-view.gif\"](\"https://reactnavigation.org/assets/libraries/tab-view.gif\")
同样的，这个效果在 React Navigation 也是有提供的。但在 expo 中有 react-native-pager-view作为平替，并且更兼容原生，但是 react-native-pager-view 是不支持 Web 端的，因此如何选择就看具体需求了。
\n先看一张图，很多 app 都有这种类似的效果。
\n这种效果可以使用监听 ScrollY 配合 react-native-reanimated 动画来实现，如果你不想自己实现也可以看看 @codeherence/react-native-header，上图便来自此库。
\n此外我还留意到 TabbedHeaderPager 这个库（很坑，别用），别看官方 gif 图效果很炫酷，然而实际效果并不达预期，并且十分难用，比如想要更改 tab 样式得像下方这样传递 props 编写。
\n![\"\"](\"https://img.kuizuo.me/2024/0514171652-Untitled.mp4\")
<TabbedHeaderPager
tabTextStyle={{
color: theme.color?.get(),
padding: 0,
}}
tabTextActiveStyle={{
backgroundColor: 'transparent',
}}
tabTextContainerStyle={{
padding: 0,
}}
tabTextContainerActiveStyle={{
backgroundColor: 'transparent',
}}
tabWrapperStyle={{
paddingVertical: 0,
}}
tabUnderlineColor={primaryColor}
tabsContainerStyle={{
backgroundColor: bgColor,
flex: 1,
maxWidth: Platform.select({
web: 200,
}),
margin: Platform.select({
web: 'auto',
}),
}}
tabsContainerHorizontalPadding={Platform.select({
default: 120,
web: 0,
})}
contentContainerStyle={{
flex: 1,
}}
/>
在这段的 RN 开发经历，我还有很多 API 还未尝试，有很多开发上的细节没编写到。篇幅有限，未来如果还有机会编写 RN 项目，再做一些分享(我觉得应该不会有了)。
\n我曾与安卓开发打过两次交道:
\n一段是在学习安卓逆向的时候，免不了学习一些基础的原生安卓开发的知识。
\n另一段是在接触自动化开发的时候，看到了 Auto.js 这个库， 可以使用 JavaScript 和 Node.js 实现小型的安卓应用（不支持 IOS），更多是使用这个库来编写一些脚本类相关的应用。现在回看该库的文档，不由得开始莫名的感叹。
\n\n\nAuto.js Pro 移除了自动化测试、图片处理、消息通知等模块，如果你需要实现的是自动化、工作流工具，则不适合 Auto.js Pro。
\n
在如今内卷的环境下，技术框架变化飞快，文档示例不断完善，服务商们也提供快速搭建应用的模版，又赶上了 AI 热潮，学习一件新东西对于初学者过于容易。随之而来的是开发人员变多，市场需求不足难以满足如此庞大的开发人员，貌似技术对开发人员本身也不是那么的重要？
\n对于技术人员要如何破局，或许是每位程序员的最值得思考的问题。
", "url": "https://kuizuo.me/blog/react-native-develop-experience", "title": "React Native 开发心得分享", "summary": "最近研究了一下 React Native(简称RN)，并用它作为毕设项目（一个仿小红书的校园社交应用）。经过一段时间的折腾，对 RN 生态有了一些了解，是时候可以分享一些心得了。", "date_modified": "2024-05-14T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "react native", "原生", "心得分享" ] }, { "id": "https://kuizuo.me/blog/with-prisma-dont-use-typeorm", "content_html": "要说 2024 年 Node.js 的 ORM 框架应该选择哪个？毫无疑问选 Prisma。至于为何，请听我细细道来。
\n本文面向的对象是饱受 TypeORM 折磨的资深用户(说的便是我自己)。只对这两个 ORM 框架从开发体验上进行对比，你也可以到 这里 查看 Prisma 官方对这两个 ORM 框架的对比。
\nTypeORM 距离上次更新已经过去半年之久了（下图截取自 24 年 1 月 1 日，没想到年初竟然还复活了）
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165614-Untitled.png\")
从下载量以及 star 数来看，如今 Prisma 已经超过 TypeORM，这很大一部分的功劳归功于像 Next.js、Nuxt.js 这样的全栈框架。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165632-Untitled%201.png\")
上图来源 https://npmtrends.com/prisma-vs-typeorm
\n而在 Nest.js 的 Discord 社区 讨论之中，Prisma 也成为诸多 Nest.js 开发者首选的 ORM 框架，因为它有着更好的开发体验。
\n在大势所趋之下相信你内心已经有一份属于自己的答案。
\n从文档的细致程度上 Prisma 比 TypeORM 要清晰详尽。在 Get started 花个数十分钟了解 Prisma 基本使用，到 playground.prisma.io 中在线尝试，到 learn 查看官方所提供的免费教程。
\n此外 Prisma 不仅支持 js/ts 生态，还支持其他语言。丰富的生态下，加之 Prisma 开发团队的背后是由商业公司维护，无需担心需求得不到解决。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%202.png\")
在从开发体验上对比之前，我想先说说 TypeORM 都有哪些坑(不足)。
\n首先 TypeORM 有个天坑，你可以在 这个 Issue 中查看详情或查看 这篇文章 是如何破解使用 TypeORM 的 Node.js 应用。
\n当你使用 userRepository.findOne({ where: { id: null } }) 时，从开发者的预期来看所返回的结果应该为 null 才对，但结果却是大跌眼镜，结果所返回的是 user 表中的第一个数据记录！
你可能会说，这不是 bug 吗？为何官方还不修。事实上确实是 bug，而事实上官方到目前也还没修复该 bug。再结合上文提到的更新频率，哦，那没事了。
\n目前解决方法则是用 createQueryBuilder().where({ id }).getOne() 平替上一条语句或者确保查询参数不为 undefined。从这也可以看的出，TypeORM 在现今或许并不是一个很好的选择。
synchronize 表示数据库的结构是否和代码保持同步，官方提及到请不要在生产环境中使用，但在开发阶段这也并不是一个很好的做法。举个例子，有这么一个实体
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number
@Column()
name: string
}
当开启了 synchronize: true，并且将 name 更改为 title 时，一旦运行 nest 服务后就会发现原有 name 下的数据全都丢失了！如图所示
![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%203.png\")
因为 TypeORM 针对上述操作的 sql 语句是这样的
\nALTER TABLE `user` CHANGE `name` `title` varchar(255) NOT NULL
ALTER TABLE `user` DROP COLUMN `title`
ALTER TABLE `user` ADD `title` varchar(255) NOT NULL
也就是说，当你在开发环境中，修改某个字段（包括名字，属性）时，该字段原有的数据便会清空。
\n因此针对数据库更新的操作最正确的做法是使用迁移(migrate)。
\n在 Nest 项目中，Prisma 的接入成本远比 TypeORM 来的容易许多。
\n相信你一定有在 xxx.module.ts 中在 imports 中导入 TypeOrmModule.forFeature([xxxEntity]) 的经历。就像下面代码这样：
@Module({
imports: [TypeOrmModule.forFeature([UserEntity])],
controllers: [UserController],
providers: [UserService],
exports: [TypeOrmModule, UserService],
})
export class UserModule {}
对于初学者而言，很大程度上会忘记导入 xxxEntity，就会出现这样的报错
Potential solutions:
- Is UserModule a valid NestJS module?
- If \"UserEntityRepository\" is a provider, is it part of the current UserModule?
- If \"UserEntityRepository\" is exported from a separate @Module, is that module imported within UserModule?
@Module({
imports: [ /* the Module containing \"UserEntityRepository\" */ ]
})
Error: Nest can't resolve dependencies of the userService (?). Please make sure that the argument \"UserEntityRepository\" at index [0] is available in the UserModule context.
此外这还不是最繁琐的，你还需要再各个 service 中，通过下面的代码来注入 userRepository。
\n@InjectRepository(UserEntity)
private readonly userRepository: Repository<UserEntity>
一旦实体一多，要注入的 Repository 也就更多，无疑不是对开发者心智负担的加深。
\n再来看看 Prisma 是怎么导入的，你可以使用 nestjs-prisma 或者按照官方文档中创建 PrismaService。
\n然后在 service 上，注入 PrismaService 后，就可以通过 this.prisma[model] 来调用模型(实体) ，就像这样
import { Injectable } from '@nestjs/common'
import { PrismaService } from 'nestjs-prisma'
@Injectable()
export class AppService {
constructor(private prisma: PrismaService) {}
users() {
return this.prisma.user.findMany()
}
user(userId: string) {
return this.prisma.user.findUnique({
where: { id: userId },
})
}
}
哪怕创建其他新的实体，只需要重新生成 PrismaClient，都无需再导入额外服务，this.prisma 便能操作所有与数据库相关的 api。
\nPrisma 的贡献者中有 ts-toolbelt 的作者，正因此 Prisma 的类型推导十分强大，能够自动生成几乎所有的类型。
\n而反观 TypeORM 虽说使用 Typescript 所编写，但它的类型推导真是一言难尽。我举几个例子：
\n在 TypeORM 中，你需要 select 选择某个实体的几个字段，你可以这么写
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%204.png\")
你会发现 post 对象的类型提示依旧还是 postEntity，没有任何变化。但从开发者的体验角度而言，既然我选择查询 id 和 title 两个字段，那么你所返回的 post 类型应该也只有 id 与 title 才更符合预期而后续代码中由于允许 post 有 body 属性提示，那么 post.body 为 null 这样不必要的结果。
\n再来看看 Prisma，你就会发现 post 对象的类型提示信息才符合开发者的预期。像这样的细节在 Prisma 有非常多。
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%205.png\")
这还不是最关键的，TypeORM 通常需要使用 createQueryBuilder 方法来构造 sql 语句来满足开发者所要查询的预期。而当你使用了该方法，你就会发现你所编写的代码与 js 无疑，我贴几张图给大伙看看。
![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%206.png\")
![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%207.png\")
![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%208.png\")
这无疑会诱发一些潜在 bug，我就多次因为要 select 某表中的某个字段，却因拼写错误导致查询失败。
\n在 TypeORM 中，假设你要新增一条 User 记录，你通常需要这么做
\nconst newUser = new User()
newUser.name = 'kuizuo'
newUser.email = 'hi@kuizuo.me'
const user = userRepository.save(newUser)
当然你可以对 User 实体中做点手脚，像下面这样加一个构造函数
\n@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number
@Column({ unique: true })
username: string
@Column()
email: string
constructor(partial?: Partial<UserEntity>) {
Object.assign(this, partial)
}
}
const newUser = new User({
name: 'kuizuo',
email: 'hi@kuizuo.me',
})
const user = userRepository.save(newUser)
于是你就可以传递一个 js 对象到 User 实体，而不是 newUser.xxx = xxx 像 Java 版的写法。
\n而要是涉及到多个关联的数据，往往需要先查询到关联数据，然后再像上面这样赋值+保存。这里就不展开了，使用过 TypeORM 的应该深有体会。
\n而在 Prisma 中，绝大多数的操作你都只需要一条代码语句外加一个对象结构，像上述 TypeORM 的操作对应 Prisma 的代码语句如下
\nconst user = await prisma.user.create({
data: {
name: 'kuizuo',
email: 'hi@kuizuo.me',
},
})
在数据库中操作经常需要判断数据库中是否有某条记录，以此来决定是更改该记录还是创建新的一条记录，而在 Prisma 中，完全可以使用 upsert，就像下面这样
\nconst user = await prisma.user.upsert({
where: { id: 1 },
update: { email: 'example@prisma.io' },
create: { email: 'example@prisma.io' },
})
在 TypeORM 中，假设你需要使用聚合函数来查询的话，通常会这么写
\nconst raw = await this.userRepository
.createQueryBuilder('user')
.select('SUM(user.id)', 'sum')
.getRawOne()
const sum = raw.sum
如果只是像上面这样，单纯查询 sum，那么 raw 的值是 { sum: 1 } , 但最要命的就是 select 配合 getRawOne 还要额外查询 user 实体的属性，所得到的结果就像这样
const raw = await this.userRepository
.createQueryBuilder('user')
.select('SUM(user.id)', 'sum')
.addSelect('user')
.where('user.id = :id', { id: 1 })
.getRawOne()
{
\tuser_id: 1,
\tuser_name: 'kuizuo',
\tuser_email： 'hi@kuizuo.me',
\tsum: '1'
}
所有 user 的属性都会带有 user_ 前缀，这看上去有点不是那么合理，但如果考虑要联表查询的情况下，就会存在相同名称的字段，通过添加表名(别名)前缀就可以避免这种情况，这样来看貌似又有点合理了。
但还是回到熟悉的类型安全，这里的所返回的 raw 对象是个 any 类型，一样不会有任何提示。
\n而在 Prisma 中，提供了 专门用于聚合的方法 aggregate，可以特别轻松的实现聚合函数查询。
\nconst minMaxAge = await prisma.user.aggregate({
_count: {
_all: true,
},
_max: {
profileViews: true,
},
_min: {
profileViews: true,
},
})
{
_count: { _all: 29 },
_max: { profileViews: 90 },
_min: { profileViews: 0 }
}
看到这里，你若是长期使用 TypeORM 的用户必定会感同身受如此糟糕的体验。那种开发体验真的是无法用言语来形容的。
\n在 Prisma 你要实现分页，只需要在 prismaClient 继承 prisma-extension-pagination 这个库。就可像下面这样，便可在 model 中使用paginate方法来实现分页，如下代码。
\nimport { PrismaClient } from '@prisma/client'
import { pagination } from 'prisma-extension-pagination'
const prisma = new PrismaClient().$extends(pagination())
const [users, meta] = prisma.user
.paginate()
.withPages({
limit: 10,
page: 2,
includePageCount: true,
});
// meta contains the following
{
currentPage: 2,
isFirstPage: false,
isLastPage: false,
previousPage: 1,
nextPage: 3,
pageCount: 10, // the number of pages is calculated
totalCount: 100, // the total number of results is calculated
}
支持页数(page)或光标(cursor)。
\n按页查询: 用于传统分页，例如翻页
光标查询: 根据游标进行查询，例如无限滚动
而在 TypeORM 你通常需要自己封装一个 paginate方法，就如下面代码所示（以下写法借用 nestjs-typeorm-paginate）
\nasync function paginate<T>(
queryBuilder: SelectQueryBuilder<T>,
options: IPaginationOptions,
): Promise<Pagination<T>> {
const { page, limit } = options
queryBuilder.take(limit).skip((page - 1) * limit)
const [items, total] = await queryBuilder.getManyAndCount()
return createPaginationObject<T>({
items,
totalItems: total,
currentPage: page,
limit,
})
}
// example
const queryBuilder = userRepository.createQueryBuilder('user')
const { items, meta } = paginate(queryBuilder, { page, limit })
当然也可以自定义userRepository，为其添加 paginate 方法，支持链式调用。但这无疑增添了开发成本。
\n得益于 Prisma 强大的数据建模 dsl，通过 generators 生成我们所需要的内容（文档，类型），比如可以使用 zod-prisma-types 根据 Schema 生成 zod 验证器**。**
\n举个例子，可以为 schema.prisma 添加一条 generator，长下面这样
\ngenerator client {
provider = \"prisma-client-js\"
output = \"./client\"
}
generator zod {
provider = \"zod-prisma-types\"
output = \"./zod\"
createModelTypes = true
\t// ...rest of config
}
datasource db {
provider = \"postgresql\"
url = env(\"DATABASE_URL\")
}
model User {
id String @id @default(uuid())
email String @unique
name String?
}
执行构建命令后，这将会自动生成 zod/index.ts 文件，将包含 UserSchema 信息，其中片段代码如下
\nexport const UserSchema = z.object({
id: z.string().uuid(),
email: z.string(),
name: z.string().nullable(),
})
export type User = z.infer<typeof UserSchema>
再通过 createZodDto，将 zod 验证器转化为 dto 类，就像下面这样
\n![\"Untitled\"](\"https://img.kuizuo.me/2024/0113165658-Untitled%209.png\")
当然你可能并不想在 nestjs 项目中使用 zod，而是希望使用传统的 class-validator 来编写 dto。可以使用社区提供的 prisma-class-generator 根据已有 model 生成 dto。
\n合理来说，Prisma 并不是一个传统的 ORM，它的工作原理并不是将表映射到编程语言中的模型类，为处理关系数据库提供了一种面向对象的方式。而是在 Prisma Schema 中定义模型。在应用程序代码中，您可以使用 Prisma Client 以类型安全的方式读取和写入数据库中的数据，而无需管理复杂模型实例的开销。
\n![\"\"](\"https://img.kuizuo.me/2024/0113171541-202401131715135.png\")
总而言之，你若想要更好的类型，简洁的实体声明语法，况且带有可视化桌面端应用，以及更好的生态完备，那么你就应该选 Prisma。
\n在写这篇文章时，我也是彻底的将 Nestjs 项目中由 TypeORM 迁移到 Prisma ，这期间给我最大的变化就是在极少的代码量却又能实现强大的功能。许多涉及多表的 CRUD操作可以通过一条简洁的表达式来完成，而在使用 TypeORM 时，常常需要编写繁琐臃肿的 queryBuilder。
\nTypeORM 有种被 nestjs 深度绑定的模样，一提到 TypeORM，想必第一印象就是 Nestjs 中所用到的 ORM 框架。然而，Prisma 却不同，是一个全能通用的选择，可以在任何的 js/ts 框架中使用。
\n从开发体验的角度不接受任何选择 TypeORM 的反驳，有了更优优秀的选择，便不愿意也不可能在回去了。如果你还未尝试过 Prisma，我强烈建议你亲身体验一番。
", "url": "https://kuizuo.me/blog/with-prisma-dont-use-typeorm", "title": "有了 Prisma 就别用 TypeORM 了", "summary": "要说 2024 年 Node.js 的 ORM 框架应该选择哪个？毫无疑问选 Prisma。至于为何，请听我细细道来。", "date_modified": "2024-01-13T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "orm", "prisma", "typeorm" ] }, { "id": "https://kuizuo.me/blog/2023-year-end-summary", "content_html": "又到了年底写年终总结的时候了，说实话今年感觉没什么内容可写。上半年发生了比较多的事不方便叙述，而下半年我忙于学校课程 + 课程重修，过得其实还有点浑浑噩噩。
\n不过如今都大四了，也确实是要考虑实习的事了。我想结合我自身情况，谈谈我是怎么看待工作或者往远点说职业规划方面的想法。
\n我目前一共有 3 段工作经历
\n事实上，对我而言也仅有休学的那一段才能算是工作，而其他两者从年限与工作性质来看不能算是一份真正的工作。但也不能说不是，至少也替别人做过事、签过合同、领过工资的。
\n不过我想稍微提提我是怎么找到这三个工作的，或者说这三份工作是怎么找到我的 -> 全靠分享
\n我不止说过一次分享的重要性，我的第一份工作就是在网络分享了一个大学生自动完成视频、作业的程序，恰好被我当地一个工作室的同事看到，寻求我能否改进功能一同合作，于是一拍即可，便开始休学。
\n剩余的两个工作同样也是，一个契机是我当时正好在研究 Strapi 编写了一篇文章，这家公司恰好用到这门技术；而 3R教室则是因为创始人所用的与我博客相同的网站生成器 Docusaurus 在这个机缘下认识的，后来创始人创业开了3R教室，我也就利用业余时间在其中扮演助教身份，赚个零花钱。（其实我很热心肠的，哪怕我不当助教，只要时间允许的情况下，你有问题问我也会尽数回答）
\n同样的，分享也能很大程度上提升你接单的资本。
\n我并非想要炫耀什么，而是分享实实在在给我带来了很多好处，我希望你能够分享一些内容，一些见解心得，哪怕是一些笔记、对他人问题的回复，都可能给你带来一些意想不到的好处。
\n我就有一个同学将自己的笔记、课设以及每次专业课期末考试的文档放到 CSDN 上（没错就是那个 IT 界的毒瘤），现在这不到期末了嘛，他的私信就有一堆人找他写课设啥的。
\n回归到正题，我接过单不多也不少，绝大多数是那种对我而言挺简单的问题，但对于一些人而言就比较困难。例如前几天一个例子，我编写过 js-deobfuscator 一个 js 混淆还原的工具，正好有人需要将一份混淆代码还原出来，于是寻求我的帮助，发了个红包给我。有时哪怕只是回答别人一个问题，甚至都可能会收到来自他人的红包。想想看，你在技术群里是不是有过这个现象。
\n还有一个网站的单子我印象很深，是一个用于销售流量、虚拟会员等商品的网站，不同与普通的商城系统，充值是通过卡密，使用卡密到特定的网站上使用。当时一个网站全套 5000，客户也算熟人了，还帮我推荐几个人购买，相当于这一套网站(模版)，帮我赚了几 w，还省去我很多开发成本，后续我都无偿给他提供技术服务。
\n事实上至少现在为止我并不是很喜欢接单，也很少主动接单。小的单（也可叫零活）通常以一顿夜宵作为回报或是看在人情的份上；而大的单（通常为外包单），通常要求交付时间快，很多时候只为了更快的完成功能，而不考虑代码质量。并且通常没有维护性可言，就更别说写测试和重构了。写久了，代码虽然写的是快了，但堆屎山的速度都堪比屎壳郎了。代码能力的提升反而不是很大。
\n在我看来当因某种目的收了他的钱财时，往往就要花费时间精力去完成这个目的，而从我内心上很难平衡这点。所以只要我不收钱，我就可以不做事了（bushi
\n我赚的第一桶金其实还不是我工作，在上大学前我已经赚过对我两桶金了，还全都是依靠网络上的资源，而非现实打工。一次是初三当时向别人学习如何刷钻以及购买钻卡来接单帮别人刷钻，另一个是作为线报群群主（现如今更多的称之为羊毛群，但我更愿称撸界），发布一些活动和教程通过拉人头引流赚钱。而也是再次契机之下，学会了开发(定制)软件。
\n这并非本文重点，因此我并不想过多介绍，但或许这会作为后面的铺垫。
\n不过我还是想说：赚钱不易。我现在回看我过去的一些经历，只能说运气成分很大，而又恰好在风口之中。在如今的互联网环境下，想要复刻曾经的路, 无疑是死路一条。
\n背景介绍完了，那就来说说实习的事情，为何我都大四了，还不找实习？
\n不是不找，而是很难找到满意的。我在今年暑期的时候有尝试找过，投过几家大厂，无一例外，了无音讯。这对我当时而言，打击还蛮大的。因为三流学校出身，确实很难过（双关），加之没人内推，海投基本上是没希望的。
\n如今前端的职位卷之又卷，僧多粥少，在厦门一些中小公司所提供的前端实习待遇（薪资大约在 3k~4k），况且对自身的提升并不是特别大，在我不是一笔性价比划得来的买卖。
\n反观学校的情况那可就更头疼了，你敢相信在大四上最该实习的时候，极为不合理的教案却还要给学生安排课程，还是专业课的那种，以下我的课表。
\n![\"\"](\"https://img.kuizuo.me/2023/1231064437.png\")
此外，我还需要重修当初因休学而没去考试的几门课程（还挺多的，重修费还交了我不少😢），导致我最后一场考试时间是在 12月中旬。还是强调那一点，我不希望工作与学业这两者同时进行。关于这学校的诸多不满，待我毕业后我一定要说说，感受什么叫中国的私立大学。
\n此外还有一点，也是我不想提及的一点，这段期间我是处于“监视”状态，内心总悬着一个不知何时爆炸的炸弹，生怕突然爆炸将会打乱我的行程。
\n好在如今期限已到，心里悬着的一块石头终于放下来了，如释重负。
\n于是在上述的因素下，今年下半年我就不想找实习了。
\n最主要的一点就是以我目前学生(应届生)的身份，是可以有机会争取到一份好的实习的，乃至是大厂的实习。
\n其次是我并没有一个很好的项目演进经历，看完我的一些工作经历不难发现我所待的公司/工作室的体量都不大，甚至我到现在都没真正体验过打卡上班（当然我也希望不要有）。而这就是小厂或者初创公司的同病，各个流程所要负责的任务很模糊。我当时休学和他人创业工作，基本上都是我一人负责项目开发；第二个远程实习也是我当时主动退出的，因为工作形式与接单无疑；第三个就不用多说了。
\n尤其是在技术层面的团队协作之中，还缺乏相当多的实践经验。所以在自我分析下，为了学习某些只在公司才能学到的东西，就非常有必要到大公司去一趟。
\n我大概率以后是不太可能再考虑坐班，所以这或许是我仅有为数不多的上班经历了。不过我想既便真正要开始打卡上班，要开始适应国内 996，未来我铁定会后悔有过这段历程。
\n![\"1703021156782.png\"](\"https://img.kuizuo.me/202312250547469.png\")
那么在如今就业形势如此严峻的时代，我又该如何找工作？
\n关于这点我其实并没有什么很好的经验分享，这也算是我首次主动找工作。不过我可以肯定的一点是，只单靠海投与某些招聘软件，想要拿到一份心意的 offer 很难。若是能通过一些关系，牵一条线（走内推），才是最佳选择，所以多积攒人脉交际圈是很有必要的。
\n这一部分我想待我后续找到工作后，再来做个心得分享也不为迟。（不说了，我去准备项目与简历去了）
\n\n电鸭的sologen：只工作，不上班。很好表明远程工作的意图。
\n远程工作（remote work）是我当下认为最具性价比的工作形式，你可以过着四五线城市的生活水平而不用考虑一线城市的房租与消费，却赚取一线城市的薪资。往大点说就是挣美元花人民币。
\n但是远程工作并非多数人想的那么轻松的，很多人对远程工作有个误区，就是可以自由决定上班时间，很自由。其实不是的，不用上下班通勤，那就把通勤的时间拿来工作。没有额外房补开销，那就拿来压低工资。而该开的会还是得开，说白了就是换个地方上班，懒床是睡不了一点的，好一点的是冬天起来不用遭受寒风的洗礼罢了。
\n有的远程工作还会要求你记录每个时间段(细到每小时)你都做了哪些工作，我暑期的就有一份我老师推荐的远程工作(实习)就是这样，我就没干了。要论自由，接单/自由职业是最自由的，项目进度、时间都由你自己把握。
\n此外还有一点就是技术栈的因素。我并没有跟随国内的主流的 Web 开发技术栈去学习什么 Java，也庆幸还好当初认为 Java 这门语言繁琐的要死，让我转变使用 JS/TS 来进行 Web 全栈的开发，而如今的重心也是在 JS/TS。
\n而这套技术栈在国外的远程工作的岗位占比很大，一些初创公司也会采用这套技术栈。而我本身学的就是 JS/TS，自身优势反而更能体现出来。但反观在国内绝大多数公司我也就是老老实实做前端的那种。况且如果只想靠国内的主流传统的技术栈而去争取一个远程岗位，我认为当下还是很难实现的。就国内的职场环境下，如今工作都难找了，就别说本身岗位就少的远程工作了。
\n退而其次，那就正常上下班通勤，而这又有的抉择了。就以我自身举例把，我老家福建宁德且我在厦门某三流大学读书，意味着我只要在福建本地找工作，就可以过的相对来说舒服，人脉资源、衣食住行都不用过多考虑。但倘若选择在外打拼，意味着可能要适应陌生的城市生活，建立起新的人际网络，面对未知的困难和挑战。而这其中所能利用的、所要遭受的，都得由自个儿来承担。
\n今年冬至的时候我与家里人商讨过这个问题，家里人的意见更多偏向于留在本省，只求我稳稳当当，脚踏实地。因为我从小到大独立性很差，加上我确实有那么亿点宅，到外面恐怕是吃不消。所以在他们眼里哪怕在本省薪资不是令我那么满意，但至少可以过一种相对舒适的生活。而我自己则认为有必要去外面见见世面，有时候很多苦只有自己吃过才知道有苦。
\n不过最终如何选择，还得取决于我自己。这对于多数人也是值得花时间思考的。
\n最终如果选择重归故里，那么一开始就身在其中是否会更好？又何必在外漂泊，独自承受着一切。
\n我经常拿我高考结束的那个暑假来做例子，我的一些高中同学去当外卖骑手、餐厅服务员，将他们的假期时间拿来打工赚钱，而我却埋头苦干的学习编程(易语言)，以兴趣驱使我学习一门技术。
\n或许是因为有过几段赚钱经历，加上家境和个人意愿，所以至今为止我都不可能会去从事这种回报率不高，或者说没有“未来”的工作。与其打工/上班，尤其是耗费大量时间与体力劳动的，不如将时间拿来提升自己综合能力。（个人观点，或许有些极端）
\n可能是由于受自由的影响加上年轻有精力折腾，同时自己又是那么不走”寻常路“、不遵循“规则”的人。所以像那种安稳平淡，重复劳动的工作，如体制/编制内的职业就不太那么感冒。
\n但从现实是没人想打工/上班，却依旧有人从事这些工作。绝大多数打工人别无选择，因生活所迫，只得忍受和抱怨打工/上班的痛苦，却又寄人篱下。
\n要说不工作是不可能的（但打工是不可能的），或许是因为这几年的一些工作经历有关，导致我有点习惯了远程，加上网间传闻 996 的压力下，我现在对坐班甚至还有些厌恶。对我最理想的工作环境就是能够自我在决定在某个时间点是否工作，例如在工作日放假，在节假日上班。
\n接单虽说也是，那这毕竟不是一份正经的工作，更多意义上来说是份兼职。更多是作为一时之需，接单又不可能接一辈子（搞得工作能工作一辈子似得）。
\n而我想说的是做个自由职业者，在细一点也就是独立开发者。但是现在来看这并非易事，不仅需要一定的技术能力和营销水平，最关键的想法就已经让绝大多数人对这份职业扼杀在摇篮中。
\n首先我对自己的生活方式定义是：偏向于自发的能量爆发，而不是有条理的持续努力。
\n今年我的 github contributions 出现过了几次长时间的空缺，那段期间我基本上没有在写代码，而是将心思用在其他事情上。例如只打游戏（好在游戏如今也是戒了）、只想摆烂（好在是摆的有点多了）、只想复习（好在该考的试都已经考了）。这就导致很多时候我会将全部精力专注在某件事情上，而抛弃其他与之无关的事情。
\n这也就导致了我很难养成一个良好的习惯，我的生物钟也因此而发生巨变。贴一张极为离谱的作息
\n![\"Untitled\"](\"https://img.kuizuo.me/202312250547470.png\")
总之持之以恒在我这还不存在过，多数的开始是因一腔热血，而最后结束时却草草了事。
\n我想是是过度的自由造就了这般现状，想要解决这个问题，坐班可能还真可以。
\n或许是因为比同龄人提前踏入过社会，有过几段工作经验，所以在就业形势严峻的时代，其实我反倒不是那么慌张。
\n何况目前经济状态也还算正常，哪怕不找工作也足够养活我自己好一整子。至少相比同龄人下，我已经挺富裕了。也没必要搞个打赏在自己的网站或项目上放置收款二维码等无关项目信息。对我而言，编写这些的目的不是为了接某个单，赚个打赏费，更多是一时兴起，分享给有需要的人，希望让其更为纯粹一些，仅此而已。
\n我对赚钱的态度也很简单，悦己便可（做点让自己愉悦的事情），数额能够维持自身生存便足够了。不过现在我还没开始到还贷的境地，或许只有压迫感来临时，才会让我激起对金钱的渴望，改变对金钱的态度。
\n取悦自己，生活最好的心态。
\n接触 web 开发算下整整两年半的时间，在这期间我并没有很好地扩张自己的技术面。在折腾方面确实不如以往，学习主动性也欠缺许多。不同于一开始所学习那样，喜欢瞎捣鼓，看到某个东西就会想尝试安装。
\n明年也就 24 岁了，面对即将到来的本命年，下一个阶段的走向其实很迷茫，面对我的是留学还是工作，我到现在都没有定数…
\n虽说我现在大四还在读，但其实我已经比同龄人晚毕业 1-2 年了（此时怀着感慨的泪水不禁流下）。心智上还保留着校园少年的青雉 ，同时也多了份成熟的稳重。
\n有过这些经历让我收获了更为珍贵的经验和独特的成长路径，我想未来的日子必定是丰富多彩的。
\n关于 restful api 想必不用多说，已经有很多文章都阐述过它的设计原则，但遵循这个原则可以让你的 API 接口更加规范吗？以下是我对 restful api 风格的一些思考🤔。
\n此时不妨思考一个问题，现在以下几个接口，你会怎么去设计 url 路径？
\n前 5 个接口想必不难设计，这边就给出标准答案。
\nGET /articlesGET /articles/:idPOST /articles/PUT /articles/:idDELETE /articles/:id当然，我相信肯定也有GET /article—list POST /add-article 这样的答案，不过这些不在 restful api 风格的范畴，就不考虑了。
而这时 查看我的文章 或许就需要稍加思考，或许你会有以下几种方式
\nGET /my-articles 从资源角度来看肯定不好，因为此时在 url 不能很直观地体现请求资源，同时在控制器文件(controller) 就与 article 分离了，并且还占用了 / 下路径。GET /articles/mine 则又不那么遵循 restful api 风格，挺违和的。那么这时不妨遵循 资源从属关系，在这里 文章所属的对象就用户，因此查看他人的文章可以这么设计GET /users/:userId/articles 获取特定用户（userId）的文章列表。
而 查看我的文章 同样也可用此 URL，只需将 userId 更改为自己的便可。从 api 的 URL 来看是很舒服了，但是从代码开发的角度上问题又有了问题了。。。
\n对于 user 资源，是不是也有查询，创建，更新，删除等接口，即 查询用户 GET /users，创建用户POST /users/ 等等。。
我是不是就需要在 user 这么重要的资源控制器上去添加一些其他方法，所对应的代码就如下所示
\n@Controller('users')
export class UserController {
constructor(private userService: UserService, private articleService: ArticleService) {}
@Get()
async list(@Query() dto: UserQueryDto) {
return this.userService.findAll(dto)
}
@Get(':id')
async info(@Param('id') id: number) {
return this.userService.findOne(id)
}
@Post()
async create(@Body() dto: UserCreateDto) {
await this.userService.create(dto)
}
// 省略有关 User 部分接口，以下是其他 user 下的资源接口
@Get(':userId/articles')
async articles(@Param('userId') userId: number) {
return this.userService.findAll(userId, articlesId)
}
@Get(':userId/articles/:articlesId')
async articles(@Param('userId') userId: number, @Param('articlesId') articlesId: number) {
return this.articleService.find(userId, articlesId)
}
}
换做是我，肯定不会希望将用户的代码与文章的代码混杂在一起。解决办法也是有的，可以额外创建一个新的 UserController 文件，专门用于获取用户下的资源（这里指 article），这样可以 即与原有针对 user 资源进行解耦，有可以有比较清晰接口分类。
\n不过针对这种情况我可能的解决办法是下会额外 起一个别名，例如 author，将 /users/:id/articles转为 /authors/:id/articles，不过在这里指向的是用户 id，而不是新建一个 author 实体（资源）。
这里的 id 会根据情况而定，假设业务中需要创建 author 实体的情况下，对 author（作者）这一身份有一些操作，如普通用户变成一个作者，获取所有作者，那么这么做就再适合不过了。
在比如说一个更鲜明的例子 商店(store) 与 商品(product)。
业务再稍微复杂一下，现在要为业务增加以下几个功能，你又会如何设计
\n答案应该会有两种，即 POST /articles/:articleId/collections 与 POST /collections
而这就令我特别头疼，因为这两个都符合 restful api 风格，也确实都能很好的满足业务功能。于是在我尝试抓包拥有相关的网站后，我发现几乎都是后者的 url。后来一想，前者更像是获取某种资源，而不是用于创建资源。后者确实更能胜任多数场景，比如说现在我需要收藏某个专栏，那么我用 POST /collections 足以胜任，只需要传递 条目id与条目类型，后端根据这两个条件找到对应条目数据便可。假设后续业务多一个资源需要收藏也不成问题。但换做前者的话，就得再多写一个重复性接口。
restful 更多是针对实际存储的资源，核心是名词，对于增删改查的业务可以说非常适合，但现实情况下不只有增删改查，就例如上述的收藏功能。
\n对于一些个别接口需要另外表达，如 登录 POST /login、获取个人信息 GET /profile
对于一些非增删改查的操作，还是使用 RPC 式的 API 更为实在，即 POST /命名空间/资源类型/动作，至少不用再为某个操作决定 PATCH/PUT 还是 POST/DELETE。
问题还没结束，不妨碍继续使用上述文章的例子，针对 文章 这一实体，又要怎么定义（区分）用户与作者或管理员路径呢？
\n管理员所看到的数据肯定远比用户来的多，如果使用同一个接口（如 /articles），那么业务代码必然会十分复杂。
使用不同的端点(end point) 是个解决方法，例如管理员在请求前添加 manage 或 admin，如 /manage/articles 或 /articles/manage 这样只需要多一步判断请求用户是否拥有管理的权限。
但对我个人而言，我一般都会以在一个命名空间下（这里指 /articles）编写，像前面的 /manage/articles 我是直接 pass 的。
在设计接口的原则就优先以拥有者的身份来设计，在去设计其他用户获取这个资源的接口。就比如说上述 article 为例， 针对增删改查而言，都是用于这个资源的拥有者可操作的，那么所获取到的数据就是尽可能符合拥有者需求的。而这时如果要将资源给其他角色请求，就会根据情况设计，如
GET /articles 获取我的文章列表（针对拥有者）GET /articles/query 查询文章（针对所有用户）在 restful 中有两个概念：resources 与 action，因此只需要定义好权限标识码便可，还是以文章举例，如 article:read article:create article:update article:delete ，这里的 resources 对应的就是 article ，action 则是 read，create 等。将这些权限码分配给不同的控制器方法，在某个请求的时候判断用户是否拥有这个权限码便可。
但是复杂的实际业务中，仅仅单靠 restful API，往往需要发送多条请求，例如获取某篇文章数据与作者数据
\nGET /articles/1
GET /articles/1/author
要么两条请求获取相应数据，要么为调用方“定制”一个接口，如GET /getArticleInfo，这样只需一条请求便可得到想要的数据。但这个就破坏了 restful API 接口风格，并且在复杂的业务中，比如说还要获取博文的评论等等，后端就要额外提供一个接口，可以说是非常繁琐了。相比之下 GraphQL 就更为灵活了。
在我写这篇文章之前，我尝试抓包看过很多网站的请求 url，见识到各式各样的 url 路径，基本上很难找到遵循 restful api 风格的网站，绝大多数的操作除了获取外用 GET，其余全用 POST 。对于复杂的业务，restful api 风格实在过于难以胜任。
\n如果说变量命名是编程最大的痛苦，那么写接口最大的痛苦我想就是定义 url 路径了。
\nRESTful API 对于同一实体，如何定义管理员和用户的路径？
\n\n", "url": "https://kuizuo.me/blog/restful-api-url-definition", "title": "关于 restful api 路径定义的思考", "summary": "关于 restful api 想必不用多说，已经有很多文章都阐述过它的设计原则，但遵循这个原则可以让你的 API 接口更加规范吗？以下是我对 restful api 风格的一些思考🤔。", "date_modified": "2023-11-30T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "杂谈", "restful" ] }, { "id": "https://kuizuo.me/blog/discoveries-of-an-algorithm-neophyte", "content_html": "正如标题所言，在我四年的编程经历中就没刷过一道算法题，这可能与我所编写的应用有关，算法对我而言提升不是特别大。加上我几乎都是在需求中学习，而非系统性的学习。所以像算法这种基础知识我自然就不是很熟悉。
\n我在今年暑假期间有一个面试，当时面试官想考察下我的算法能力，而我直接明摆了说我不行（指算法上的不行），但面试官还是想继续考察，于是就出了道斐波那契数列作为考题。
\n但我毕竟也接触了 4 年的代码，虽说不刷算法，但起码也看过许多文章和代码，斐波那契数列使用递归实现的代码也有印象，于是很快我就写出了下面的代码作为我的答案。
\nfunction fib(n) {
if (n <= 1) return n
return fib(n - 1) + fib(n - 2)
}
面试官问我还有没有更好的答案，我便摇了摇头表示这 5 行不到的代码难道不是最优解？
\n\n\n事实上这份代码看起来很简洁，实际却是耗时最慢的解法
\n
毫无疑问，在算法这关我肯定是挂了的，不过好在项目经验及后续的项目实践考核较为顺利，不然结局就是回去等通知了。最后面试接近尾声时，面试官友情提醒我加强基础知识（算法），强调各种应用框架不断更新迭代，但计算机的底层基础知识是不变的。于是在面试官的建议下，便有了本文。
\n好吧，我承认我是为了面试才去学算法的。
\n在介绍我是从何处学习算法以及从中学到了什么，不妨先来看看上题的最优答案是什么。
\n对于有接触过算法的同学而言，不难看出时间复杂度为 O(n²)，而指数阶属于爆炸式增长，当 n 非常大时执行效果缓慢，且可能会出现函数调用堆栈溢出。
\n如果仔细观察一下，会发现这其中进行了非常多的重复计算，我们不妨将设置一个 res 变量来输出一下结果
\nfunction fib(n) {
if (n <= 1) {
return n
}
const res = fib(n - 1) + fib(n - 2)
console.log(res)
return res
}
当 n=7 时，所输出的结果如下
\n![\"Untitled\"](\"https://img.kuizuo.me/202309162220346.png\")
这还只是在 n=7 的情况下，便有这么多输出结果。而在算法中要避免的就是重复计算，这能够高效的节省执行时间，因此不妨定义一个缓存变量，在递归时将缓存变量也传递进去，如果缓存变量中存在则说明已计算过，直接返回计算结果即可。
\nfunction fib(n, mem = []) {
if (n <= 1) {
return n
}
if (mem[n]) {
return mem[n]
}
const res = fib(n - 1, mem) + fib(n - 2, mem)
console.log(res)
mem[n] = res
return res
}
此时所输出的结果可以很明显的发现没有过多的重复计算，执行时间也有显著降低。
\n![\"Untitled\"](\"https://img.kuizuo.me/202309162220348.png\")
这便是记忆化搜索，时间复杂度被优化至 O(n)。
\n可这还是免不了递归调用出现堆栈溢出的情况（如 n=10000 时）。
\n![\"Untitled\"](\"https://img.kuizuo.me/202309162220349.png\")
从上面的解法来看，都是从”从顶至底”，比方说 n=7，会先求得 n=6 的结果, 而 n=6 又要求得 n=5 的结果，依次类推直至得到底层 n=1 的结果。
\n事实上我们可以换一种思路，先求得 n=1，n=2 的结果，然后依次类推上去，最终得到 n=6，n=7 的结果，也就是“从底至顶”，而这就是动态规划的方法。
\n从代码上来分析，因此我们可以初始化一个 dp 数组，用于存放数据状态。
\nfunction fib(n) {
const dp = [0, 1]
for (let i = 2; i <= n; i++) {
dp[i] = dp[i - 1] + dp[i - 2]
}
return dp[n]
}
最终 dp 数组的最后一个成员便是原问题的解。此时输出 dp 数组结果。
\n![\"Untitled\"](\"https://img.kuizuo.me/202309162220350.png\")
且由于不存在递归调用，因此你当 n=10000 时也不在会出现堆栈溢出的情况（只不过最终的结果必定超出了 JS 数值可表示范围，所以只会输出 Infinity）
\n对于上述代码而言，在空间复杂度上能够从 O(n) 优化到 O(1)，至于实现可以参考 空间优化，这里便不再赘述。
\n我想至少从这里你就能看出算法的魅力所在，这里我强烈推荐 hello-algo 这本数据结构与算法入门书，我的算法之旅的起点便是从这本书开始，同时激发起我对算法的兴趣。
\n于是在看完了这本算法书后，我便打开了大名鼎鼎的刷题网站 LeetCode，同时打开了究极经典题目的两数之和。
\n\n\n有人相爱，有人夜里开车看海，有人 leetcode 第一题都做不出来。
\n
题干：
\n\n\n给定一个整数数组
\nnums和一个整数目标值target，请你在该数组中找出和为目标值target的那 两个 整数，并返回它们的数组下标。你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。
\n你可以按任意顺序返回答案。
\n
以下代码将会采用 JavaScript 代码作为演示。
\n我初次接触该题也只会暴力解法，遇事不决，暴力解决。也很验证了那句话：不论多久过去，我首先还是想到两个 for。
\nvar twoSum = function (nums, target) {
const n = nums.length
for (let i = 0; i < n; i++) {
for (let j = 0; j < n; j++) {
if (nums[i] + nums[j] === target && i !== j) {
return [i, j]
}
}
}
}
当然针对上述 for 循环优化部分，比如说让 j = i + 1 ，这样就可以有效避免重复数字的循环以及 i ≠ j 的判断。由于用到了两次循环，很显然时间复杂度为 O(n²)，并不高效。
我们不妨将每个数字通过 hash 表缓存起来，将值 nums[i] 作为 key，将 i 作为 value。由于题目的条件则是 x + y = target，也就是 target - x = y，这样判断的条件就可以由 nums[i]+ nums[j] === target 变为 map.has(target - nums[i]) 。如果 map 表中有 y 索引，那么显然 target - nums[i] = y，取出 y 的索引以及当前 i 索引就能够得到答案。代码如下
var twoSum = function (nums, target) {
const map = new Map()
for (let i = 0; i < nums.length; i++) {
if (map.has(target - nums[i])) {
return [map.get(target - nums[i]), i]
}
map.set(nums[i], i)
}
}
而这样由于只有一次循环，时间复杂度为 O(N)。
\n假如理想情况下，题目所给定的 nums 是有序的情况，那么就可以考虑使用双指针解法。先说原理，假设给定的 nums 为 [2,3,5,6,8]，而目标的解为 9。在上面的做法中都是从索引 0 开始枚举，也就是 2,3,5…依次类推，如果没找到与 2 相加的元素则从 3 开始 3,5,6…依次类推。
此时我们不妨从最小的数和最大的数开始，在这个例子中也就是 2 和 8，很显然 2 + 8 > 9，说明什么？说明 8 和中间所有数都大于 9 即 3+8 ，5+8 肯定都大于 9，所以 8 的下标必然不是最终结果，那么我们就可以把 8 排除，从 [2,3,5,6] 中找出结果，同样的从最小和最大的数开始，2 + 6 < 9 ，这又说明什么？说明 2 和中间这些数相加肯定都下雨 9 即 2+3，2+5 肯定都小于 9，因此 2 也应该排除，然后从 [3,5,6] 中找出结果。就这样依次类推，直到找到最终两个数 3 + 6 = 9，返回 3 与 6 的下标即可。
由于此解法相当于有两个坐标(指针)不断地向中间移动，因此这种解法也叫双指针算法。当然，要使用该方式的前提是输入的数组有序，否则无法使用。
\n用代码的方式来实现：
\nnums[left] + nums[right] 与 target 的大小关系，如果相等则说明找到目标(答案)，如果大于则 右指针减 1 right—-，小于则左指针加 1 left++。function twoSum(nums, target) {
let left = 0
let right = nums.length - 1
while (left < right) {
const sum = nums[left] + nums[right]
if (sum === target) {
return [left, right]
}
if (sum > target) {
right--
} else if (sum < target) {
left++
}
}
}
针对上述两道算法题浅浅的做个分享，毕竟我还只是一名初入算法的小白。对我而言，我的算法刷题之旅还有很长的一段时间。且看样子这条路可能不会太平坦。
\n在我刷算法之前，我在网上看到鼓吹算法无用论的人，也能看到学算法却不知如何应用的人。
\n这也不禁让我思考 🤔，算法对我所开发的应用是否真的有用呢？
\n在我的开发过程中，往往面临着各种功能需求，而通常情况下我会以尽可能快的速度去实现该功能，至于说这个功能耗时 1ms，还是 100 ms，并不在乎。因为对我来说，这种微小的速度变化并不会被感知到，或者说绝大多数情况下，处理的数据规模都处在 n = 1 的情况下，此时我们还会在意 n² 大还是 2ⁿ 大吗？
\n但如果说到了用户感知到卡顿的情况下，那么此时才会关注性能优化，否则，过度的优化可能会成为一种徒劳的努力。
\n或许正是因为我都没有用到算法解决实际问题的经历，所以很难说服自己算法对我的工作有多大帮助。但不可否认的是，算法对我当前而言是一种思维上的拓宽。让我意识到一道（实际）问题的解法通常不只有一种，如何规划设计出一个高效的解决方案才是值得我们思考的地方。
\n借 MIT 教授 Erik Demaine 的一句话
\n\n\nIf you want to become a good programmer, you can spend 10 years programming, or spend 2 years programming and learning algorithms.
\n
如果你想成为一名优秀的程序员，你可以花 10 年时间编程，或者花 2 年时间编程和学习算法。
\n这或许就是学习算法的真正意义。
\n我曾经写过一个项目 ddddocr_server，使用 fastapi 提供 http 接口，以此来调用 ddddocr 库。
\n其他语言想要调用的话，则是通过 http 协议的方式来调用。然而 http 协议的开销不小，而 Websocket 调用又不灵活，此时针对这种应用场景的最佳选择就是 rpc（Remote Procedure Call 远程过程调用），而这次所要用的技术便是 grpc。
\n早闻 gRPC 大名，所以这次将使用 nest 通过 grpc 的方式来调用 python 的 ddddocr 库来识别验证码。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823586.png\")
本文源码 nest-ocr
\n由于我们的调用方是 nest，因此就很有必要熟悉一下 nest 要如何创建
\n官方提供了一个 样例，本文便在此基础上进行更改。
\n首先，在 nest 中 grpc 是以微服务的方式启动的，从代码上也就 3 行便可实现。
\nconst app = await NestFactory.create(AppModule)
app.connectMicroservice <
MicroserviceOptions >
{
transport: Transport.GRPC,
options: {
package: 'hero',
protoPath: join(__dirname, './hero/hero.proto'),
},
}
await app.startAllMicroservices()
既然服务有了，那么要如何调用呢？或者说有没有像 http 接口调试工具能够调用 grpc 服务，有很多种 grpc 客户端工具，但这里选择 Postman。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823587.png\")
不过这里先别急着调用，为了后续调试，建议先到工作区的 APIs 中添加一个 API，然后将样例中的 hero.proto 中导入进来
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823588.png\")
导入完毕后将显示如下页面
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823589.png\")
点击工作区旁边的 New 按钮（不是 + 按钮），选择 gRPC
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823590.png\")
在 Enter URL 输入框填写 localhost:5000 (nest grpc 默认地址)，这里你也可以选择第一个官方的 gRPC 测试服务，用于看看效果。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823591.png\")
填写完毕后，你会发现在右侧 Select a method 中并没有看到所定义的两个方法：FindOne，FindMang，这时候我们需要将 hero.proto 文件导入进来，如果你完成了 创建 API 那一步骤，你在右侧便能看到那两个方法
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823592.png\")
此时不妨选择一下 FindOne，然后点击下方 Use Example Message，将 id 填为 1，点击 Invoke，得到的效果图如下。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823593.png\")
到这里我们就已经搞定了如何调用 grpc 服务，接下来就要自己去实现标题的需求。
\n在 grpc 中，数据传输部分通过 Protobuf（Protocol Buffers）定义
\n因为从上面服务调用来看，貌似与 http 协议调用不相上下。
\n其实不然，protobuf 不同于 JSON、XML 数据，是以二进制数据流传输，数据在经 protobuf 序列化后的消息体积很小（传输内容少，传输相对就快）。同时在加上 HTTP/2 协议的加持（底层传输协议，可替换为其他协议），使得 gRPC 的传输性能要优于传统 Restful。
\nprotobuf 对于数据传输的优点有很多，如 支持流式传输，不过这就不是本文所述的内容了。总之你只要知道 grpc 性能高的原因就是因为 protobuf。
\nsyntax = \"proto3\";
package hero;
service HeroService {
rpc FindOne (HeroById) returns (Hero);
rpc FindMany (stream HeroById) returns (stream Hero);
}
message HeroById {
int32 id = 1;
}
message Hero {
int32 id = 1;
string name = 2;
}
不难看出，package 定义包名，service 定义服务，而 message 则是定义数据传输的类型。
\n客户端与服务端将根据 protobuf 来生成双方交互方式，其中包名决定了双方传输的作用域，service 下的函数就是双方之间的预先定义好要以什么样的数据发送，又以什么样的数据返回。
\n我个人是觉得没什么特别重点的部分，根据自己的需求然后修改基本数据结构便可。
\n首先，要明确谁是客户端，谁是服务端。
\n从 标题 上来看，不难看出是 js(client) ⇒ python(server)，也就是 nest 调用 ddddocr 这个库，那么 nest 就应该作为客户端，而 python 作为服务端。
\n先将整个流程先捋一遍，如图下图示意。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823594.png\")
用户想要调用 ddddocr 库，最理想的肯定是让用户直接和 python 打交道，但应用（这里指 Web）通常不会使用 python 进行编写，而其他语言(js)想要跨语言调用，这时 rpc 就再适合不过了。
\n可能会有人说这么操作多此一举，我只能说根据性能和业务为主。相比将 nest 后端服务迁移到 python 上，和在 nest 与 python 之间多层 grpc，在两者的工作量之下我肯定毫不疑问的选择后者。
\nsyntax = \"proto3\";
package ocr;
service OCR {
rpc Character (CharacterBody) returns (CharacterReply) {}
// TODO: Add other type, e.g. select, slide, etc.
}
message CharacterBody {
bytes image = 1;
}
message CharacterReply {
string result = 1;
int32 consumedTime = 2;
}
这部分没什么特别好说的，就图片数据以字节数组的方式传递。
\n由于 nest 作为客户端，事实上示例部分的很多代码都无关了，就比如 main.ts 中用于启动 gRPC 服务的代码，都可以注释掉，因为在这里我们并不打算将 nest 作为服务端。
\n// app.connectMicroservice<MicroserviceOptions>(grpcClientOptions);
// await app.startAllMicroservices();
最核心的代码，就是定义 client, 如下
\n@Client({
transport: Transport.GRPC,
options: {
package: ['ocr'],
protoPath: join(__dirname, './ocr.proto'),
url: 'localhost:50051', // 这里所定义的是 grpc 服务端地址
},
})
client: ClientGrpc
\n\n这一部分也可以通过构造函数的方式注入，因人而异。
\nconstructor(@Inject('OCR_PACKAGE') private readonly client: ClientGrpc) {}
有了这个 client 就能够获取 ocrService 了，完整 ocr.controller.ts 代码如下
\nimport { Body, Controller, OnModuleInit, Post } from '@nestjs/common'
import { Client, ClientGrpc } from '@nestjs/microservices'
import { Observable } from 'rxjs'
import { Character } from './interfaces/character.interface'
import { Reply } from './interfaces/reply.interface'
import { grpcClientOptions } from 'src/grpc-client.options'
import { CharacterDto } from './dtos/character.dto'
interface OCRService {
Character(image: Character): Observable<Reply>
// TODO: Add other type, e.g. select, slide, etc.
}
@Controller('ocr')
export class OcrController implements OnModuleInit {
private ocrService: OCRService
@Client(grpcClientOptions)
client: ClientGrpc
onModuleInit() {
this.ocrService = this.client.getService('OCR')
}
@Post('character')
character(@Body() dto: CharacterDto): Observable<Reply> {
// 这里多一步 Base64 将文本解码成图片的操作
// 主要是根据接口易用性而定，最佳的做法肯定是类似上传文件，直接得到图片二进制数据，省去数据操作步骤
const buffer = Buffer.from(dto.image, 'base64')
return this.ocrService.Character({ image: buffer })
}
// TODO: Add other type, e.g. select, slide, etc.
}
而在之前 http 的方式实现的话，这里 this.ocrService.Character({ image: dto.image }); 所对应的就是例如 fetch(’http://localhost:3002/ocr/character’) ，这里 3002 端口对应的是 python 的 http 服务。
服务端部分其实还稍微有些复杂，可能是因为我太久没写 python 的缘故。
\n在之前是通过 python 来启动一个 http 服务来供其他语言调用，现在有了 gRPC 就完全没必要启动 http 服务。
\n可以在 这里 下载官方的 python 示例。
\n先安装 grpc_tools
\npython3 -m pip install grpcio-tools
接着执行下方指令
\npython3 -m grpc_tools.protoc -I . --python_out=. --grpc_python_out=. ocr.proto
它将会在下方根据 ocr.proto 生成 ocr_pb2.py 与 ocr_pb2_grpc.py 两个文件，事实上这两个文件都无需改动，你只需要每次修改 .proto 文件后再重新执行上方代码将新的内容复写到文件上便可。
不过要搞清流程，还要是在意这些文件便可。其中在 ocr_pb2_grpc.py 文件中，你会找到 OCRServicer 类的接口定义。
class OCRServicer(object):
\"\"\"Missing associated documentation comment in .proto file.\"\"\"
def Character(self, request, context):
\"\"\"Missing associated documentation comment in .proto file.\"\"\"
context.set_code(grpc.StatusCode.UNIMPLEMENTED)
context.set_details('Method not implemented!')
raise NotImplementedError('Method not implemented!')
很显然这是一个接口类，因此我们需要实现它。
\n而 ocr_pb2.py 内容就不必细看，但后续也需要用到，主要通过 ocr_pb2.CharacterReply 将数据封装返回给客户端。
最终完整的 server.py 内容如下
\nfrom concurrent import futures
import time
import grpc
import ocr_pb2
import ocr_pb2_grpc
import ddddocr
ocr = ddddocr.DdddOcr(beta=True)
class OCRServicer(ocr_pb2_grpc.OCRServicer):
# 这里实现 英数验证码 识别
def Character(self, request, context):
t = time.perf_counter()
result = ocr.classification(request.image)
consumed_time = int((time.perf_counter() - t)*1000)
print({'result': result, 'consumedTime': consumed_time})
# 根据 ocr.proto 的 message CharacterReply 生成的类
response = ocr_pb2.CharacterReply(
result=result, consumedTime=consumed_time)
return response
def serve():
port = '50051'
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
ocr_pb2_grpc.add_OCRServicer_to_server(OCRServicer(), server)
server.add_insecure_port('[::]:' + port)
server.start()
print(\"Server started, listening on \" + port)
server.wait_for_termination()
if __name__ == '__main__':
serve()
此时整个代码的核心流程就已经搞通了，你可以到 nest-ocr 查看源码，先看看用 postman grpc 方式调用，这里 image 为 字节数组（图片的二进制数据）
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823596.png\")
用户以 http 方式访问的效果。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307290823595.png\")
时间因素，因此本文最终代码都仅实现 英数字符识别，ddddocr 还支持点选、滑块，如有时间再补充相关代码。
\n从 http 方式转到 gRPC 无非就是围绕 protobuf 展开，预先定义好 protobuf，然后在此基础上去编写 grpc 客户端(调用方)与服务端(提供方) 的代码。虽然引入了一丝复杂性，但可以有效提高性能。
\n有时候，为了优化性能，又不想增加硬件开销，我们不得不在代码层面做出一些改进，更换高性能框架便是其中之一。然而事实上，提高性能最快捷的方式就是升级硬件。并发数不足，增加服务器数量是最直接有效的办法。
\n为了偏薄的性能提升，开发者总能想出诸多的解决方案。
", "url": "https://kuizuo.me/blog/nest-grpc-ocr", "title": "Nest grpc 实践之调用 python ddddocr 库", "summary": "本文将使用 nest 通过 grpc 的方式来调用 python 的 ddddocr 库来识别验证码。", "date_modified": "2023-07-29T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "nest", "grpc", "python", "ddddocr" ] }, { "id": "https://kuizuo.me/blog/nest-swagger-response-data", "content_html": "通常情况下，在 nest.js 的 swagger 页面文档中的响应数据文档默认如下
\n![\"\"](\"https://img.kuizuo.me/202307180105813.png\")
此时要为这个控制器添加响应数据文档的话，只需要先声明 数据的类型，然后通过@ApiResponse 装饰器添加到该控制器上即可，举例说明
\n@Entity('todo')
export class TodoEntity {
@Column()
@ApiProperty({ description: 'todo' })
value: string
@ApiProperty({ description: 'todo' })
@Column({ default: false })
status: boolean
}
@Get()
@ApiOperation({ summary: '获取Todo详情' })
@ApiResponse({ type: [TodoEntity] })
async list(): Promise<TodoEntity[]> {
return this.todoService.list();
}
@Get(':id')
@ApiOperation({ summary: '获取Todo详情' })
@ApiResponse({ type: TodoEntity })
async info(@IdParam() id: number): Promise<TodoEntity> {
return this.todoService.detail(id);
}
此时对应的文档数据如下显示
\n![\"image-20230718012234692\"](\"https://img.kuizuo.me/202307180122728.png\")
如果你想要自定义返回的数据，而不是用 entity 对象的话，可以按照如下定义
\nexport class Todo {
@ApiProperty({ description: 'todo' })
value: string
@ApiProperty({ description: 'todo' })
status: boolean
}
然后将 @ApiResponse({ type: TodoEntity }) 中的 TodoEntity 替换 Todo 即可。
然而通常情况下，都会对返回数据进行一层包装，如
\n{
\"data\": [
{
\"name\": \"string\"
}
],
\"code\": 200,
\"message\": \"success\"
}
其中 data 数据就是原始数据。要实现这种数据结构字段，首先定义一个自定义类用于包装，如
\nexport class ResOp<T = any> {
@ApiProperty({ type: 'object' })
data?: T
@ApiProperty({ type: 'number', default: 200 })
code: number
@ApiProperty({ type: 'string', default: 'success' })
message: string
constructor(code: number, data: T, message = 'success') {
this.code = code
this.data = data
this.message = message
}
}
接着在定义一个拦截器，将 data 数据用 ResOp 包装，如下拦截器代码如下
\nexport class TransformInterceptor implements NestInterceptor {
constructor(private readonly reflector: Reflector) {}
intercept(context: ExecutionContext, next: CallHandler<any>): Observable<any> {
return next.handle().pipe(
map(data => {
const response = context.switchToHttp().getResponse<FastifyReply>()
response.header('Content-Type', 'application/json; charset=utf-8')
return new ResOp(HttpStatus.OK, data ?? null)
}),
)
}
}
此时返回的数据都会转换为 { \"data\": { }, \"code\": 200, \"message\": \"success\" } 的形式，这部分不为就本文重点，就不赘述了。
回到 Swagger 文档中，只需将 @ApiResponse({ type: TodoEntity }) 改写成 @ApiResponse({ type: ResOp<TodoEntity> })，就可以实现下图需求。
![\"image-20230718012618710\"](\"https://img.kuizuo.me/202307180126751.png\")
然而对于庞大的业务而言，使用 @ApiResponse({ type: ResOp<TodoEntity> })的写法，肯定不如 @ApiResponse({ type: TodoEntity })来的高效，有没有什么办法能够用后者的写法，却能达到前者的效果，答案是肯定有的。
这里需要先自定义一个装饰器，命名为 ApiResult，完整代码如下
import { Type, applyDecorators, HttpStatus } from '@nestjs/common'
import { ApiExtraModels, ApiResponse, getSchemaPath } from '@nestjs/swagger'
import { ResOp } from '@/common/model/response.model'
const baseTypeNames = ['String', 'Number', 'Boolean']
/**
* @description: 生成返回结果装饰器
*/
export const ApiResult = <TModel extends Type<any>>({
type,
isPage,
status,
}: {
type?: TModel | TModel[]
isPage?: boolean
status?: HttpStatus
}) => {
let prop = null
if (Array.isArray(type)) {
if (isPage) {
prop = {
type: 'object',
properties: {
items: {
type: 'array',
items: { $ref: getSchemaPath(type[0]) },
},
meta: {
type: 'object',
properties: {
itemCount: { type: 'number', default: 0 },
totalItems: { type: 'number', default: 0 },
itemsPerPage: { type: 'number', default: 0 },
totalPages: { type: 'number', default: 0 },
currentPage: { type: 'number', default: 0 },
},
},
},
}
} else {
prop = {
type: 'array',
items: { $ref: getSchemaPath(type[0]) },
}
}
} else if (type) {
if (type && baseTypeNames.includes(type.name)) {
prop = { type: type.name.toLocaleLowerCase() }
} else {
prop = { $ref: getSchemaPath(type) }
}
} else {
prop = { type: 'null', default: null }
}
const model = Array.isArray(type) ? type[0] : type
return applyDecorators(
ApiExtraModels(model),
ApiResponse({
status,
schema: {
allOf: [
{ $ref: getSchemaPath(ResOp) },
{
properties: {
data: prop,
},
},
],
},
}),
)
}
其核心代码就是在 @ApiResponse 上进行扩展，这一部分代码在官方文档: advanced-generic-apiresponse 中提供相关示例，这里我简单说明下：
{ $ref: getSchemaPath(ResOp) } 表示原始数据，要被“塞”到那个类下，而第二个参数 properties: { data: prop } 则表示 ResOp 的 data 属性要如何替换，替换的部分则由 prop 变量决定，只需要根据实际需求构造相应的字段结构。
由于有些类没有被任何控制器直接引用， SwaggerModule SwaggerModule 还无法生成相应的模型定义，所以需要 @ApiExtraModels(model) 将其额外导入。
此时只需要将 @ApiResponse({ type: TodoEntity }) 改写为 @ApiResult({ type: TodoEntity })，就可达到最终目的。
不过我还对其进行扩展，使其能够返回分页数据格式，具体根据实际数据而定，演示效果如下图：
\n![\"image-20230718023729609\"](\"https://img.kuizuo.me/202307180237658.png\")
通过上述的操作后，此时记下项目的 swagger-ui 地址，例如 http://127.0.0.1:5001/api-docs, 此时再后面添加-json，即 http://127.0.0.1:5001/api-docs-json 所得到的数据便可导入到第三方的接口管理工具，就能够很好的第三方的接口协同，接口测试等功能。
![\"image-20230718022612215\"](\"https://img.kuizuo.me/202307180226265.png\")
![\"image-20230718022446188\"](\"https://img.kuizuo.me/202307180224284.png\")
我一般很少做年中总结，但是这上半年发生在我事情比较多，加上毕业季，万千感慨涌上心头。
\n过得很快，本该在这个时间段毕业的我，因一意孤行申请休学一年，导致我比原同一届的人晚毕业一年。也正是这个决定改变了我的人生轨迹，让我成长了许多。
\n如今的我作为一名准大四的大学生 👨🎓，且经历过转专业和休学的大学生，来叙述自己的经历。
\n如果你有注意到我的 github contributions，你会发现我有整整一段时间（约 2 个月）没怎么编写代码和记录博客了。在这期间整个人的状态很差，十分消沉，迟迟到现在为止。
\n在这期间我被公安传唤了。说难听点，我当时的身份是犯罪嫌疑人。当然现在应该也算，处于取保候审状态，除了不能出国外，目前还算自由。
\n至于案情我不方便细说，总之与互联网（技术）相关且在我休学期间出的事情。一开始关于这个话题我并不想提及，毕竟说出来肯定对自身有所不好，因此本文便迟迟都处于草稿状态。但结合自身经历，我认为非常有必要把这些内容记录下来，避免重蹈覆辙。
\n我想大学内有这两项经历的人应该是在少数，我会把缘由交代明细。
\n我大一时的专业是 《信息与科学计算》，所属数学系，这个并不是计算机专业（虽然涉及到一些计算机相关的课程，但本质还是理学，不是工学），所以我转专业的原因很简单，就是要科班出身。当时就我看来科班出身能为我以后工作带来很大的帮助（当时的想法很天真，没有考虑转专业后所要付出的代价），但在这些年的经历以及行内的各个大神的能力告诉我，实际上并不会带来多大的优势。
\n我转专业并不难，因为我暑假就已经接触编程，并且在大一的时候，每天不是在写代码，就是在看代码，那段时间可谓是我人生编程学习最快乐的时光。所以转专业的考试对我来说特别轻松加上我数学天赋还不错，原专业的成绩也 OK，屁颠屁颠地将转专业填报单提交了上去，下学期便分配到新的班级中修学新专业——软件工程。
\n然而就在我转完专业，我便开始后悔转专业了。我发现学校老师所教的是什么牛马？真的就是会念 PPT 就便会教课，而且所教的多数内容，所发放的题材都是相对过时甚至被淘汰的东西。难怪说学生会对编程失去兴趣，要是我一开始跟着老师这么学，现在那有愧怍二字。
\n课程教学质量差也就算了，课程设计的要求还与学生课堂的内容还不同，我很难想象这学期只教 Web 前端（ES5 时代），却要求课程设计实现一个带后端接口服务以及数据库服务的程序。要不是我当时的基础还算好，恐怕连项目买来都不知道怎么跑起来。
\n不过这也是国内绝大多数高校现状，课程内容老旧，教案设计不合理，在越垃圾的大学中，这种情况反而更明显，恰好我就读于垃圾中的垃圾。与其抱怨教学质量，不如自己潜心学习，也正是因如此，自我学习能力才能有所大提升。
\n也不能说转专业对我没有一点帮助，毕竟自身有了一定的编程基础知识，在专业课上回答问题上我还是能说上一点的。并且每次课程设计与考试的时候总有人会找我来报个大腿，老师也见识到我的专业能力，我这一小组成员都能轻松通过课设答辩。（主要还是归功于我吹牛逼的能力）
\n关于转专业，还有一点就是补修。比如我大一是数学系的，当时的课是叫数学分析，而在软件工程专业就是传统的高等数学，运气还算好，这两门类别相同，可以做学分替换。但往往没那么幸运，就需要额外花时间去修之前的软件工程大一的课程，在跨度较大的转专业中甚至还会更多。
\n最后我想告诫一些有想转专业的同学，如果你能接受转专业的麻烦，并且真的认为转专业对你带来帮助，那可以转。但如果只是为了换个班级换个室友什么的，转后的代价或许比你与同学间不友好相处四年还要负重。总之，转与不转，最终目的是以最快捷轻松的方式拿毕业证为主。
然后在我大二上的时候发生了一个契机，我当时编写过一个易语言软件能够自动完成大学生网课视频、作业的程序，并将其发布在网络上免费使用。
\n挺巧的是不久后，厦门当地（距离我学校也就 5 公里）的一个工作室（算我有 4 个人）恰好看到了这个软件，问我能否在此基础上实现的一些功能，也说明了他们的目的，想要一同合作，我主要负责技术，他们负责销售推广。我思考了下可行性，于是结合转专业的懊悔之下，我义无反顾地办理休学手续，开始了我的休学之旅，准备大干一场！
\n\n现在回想当时我的做法太过于任性，当时是 12 月份的时候，也就是临近考试周时，我便不在宿舍复习，甚至考试我都是直接没去的，而是直接到工作室里开始改写我的程序。以下是我当时学期的成绩单（有点惨不忍睹）
\n![\"Untitled\"](\"https://img.kuizuo.me/202307110122716.png\")
我当时的想法特别天真，认为只要技术在身，天下我有。甚至当时都考虑花点时间学习渗透技术来入侵教务系统来改分（好在目前为止我都没真正接触过渗透技术，不然就真的是太刑啦）
还有就是我本想的是休学带辍学，也就是休学一年期间 搞的好就辍学，搞不好就复学，当然前者是比较多的，不然也不至于连考试都没去考。（现在回想太亏了，因为这些课程缺课就相当于挂科，我还要办理重修，但没办法，当时的我可不想着以后的事情）
\n至于说为何有辍学的想法，甚至对本科证都抱着一脸嫌弃。一部分来源于技术成就的膨胀，还有一部分来自校园生活。反观学校和身边的同学，基本处于无所事事的状态（混日子），不是打游戏就是刷短视频，虽说很听规矩，要上课去上课，要开会就开会，无一缺席，日复一日，年复一年，可没点规划，就想着如何不劳而获。说真的，就这种 B 状态，谁毕业不失业？谁毕业不打工？
\n什么样的环境造就什么样的人。一个地方的土壤会决定植物生长的是枝繁叶茂还是弱不禁风。至少现在我知道为何那些大厂都会优先面向 985 和 211 的学生。
\n因此我要办理休学的决心非常强烈，我父母与我姐不断给我劝告，告诉我要赚钱，要工作什么时候都来的级的以后都来得及，然而这并不是赚钱和工作的原因，而是受身边人的因素。如果要我与其同那些大学的同学这样混四年，那我不如出来实打实的干一年。（这话说的会难听，但当时我就是这么想的）父母犟不过我，我也和父母表明我肯定会拿毕业证。既然孩子有想法，那就让孩子试试。
\n在确定好正式合作之后，我便到工作室布置好自己工位，以下是我曾经的一张正在跑项目的图
\n![\"101688581490_.pic.jpg\"](\"https://img.kuizuo.me/202307110122808.jpg\")
现在回想，当时动不动就加班到半夜，但是我对此没有怨言，甚至很享受这段时间。做自己愿意做的事情，我认为这就足够有意义了。不过这段时间持续不长，主要开发阶段也就是上半年的事情，而下半年由于本地疫情原因加上我身处老家，迟迟未能回到工位。而平常更多的任务是维护，兴致也没有一开始从 0 到 1 的热情。要知道维护是件非常枯燥且重复的事情，运营人员一有问题，就反馈到我这边，而当时写的项目又是协议项目，基本上每隔一阵子，我就要重新抓包，重新分析参数，重新部署。加上当时易语言的项目又没有 CI/CD，于是我维护完之后，就又要将易语言的项目丢到这些服务器上，我当时非常想写一个脚本，奈何我们的做单服务器基本上隔一段时间换一批，而这些服务器又是物理机（一台真实的远程机子），而非腾讯云、阿里云这种服务器，更没有批量备份，系统镜像这一功能。因此在安装环境和部署上可以说花费了我很多没必要的时间。（也可以说因此契机我彻彻底底的放弃了易语言，对于一个大型应用而言，它有数不清的缺点）
\n不过最终我还是复学了，因为在这个项目上，我只看到不断重复的日子，且项目并不是一个长久项目，在未来的某个时刻必定会被制裁（只是我没想到会这么快），最终随着一年的休学期限到来，在做了项目移交后，我便退出了该团队。在此期间自然挣了点小钱（不多，也就相当于阿里 P6 级别薪酬），足够我快活潇洒好些年了。
\n可好景不长，往往一个人在巅峰后的一段时间，必然要经历一次落差。
\n办理休学手续非常容易，只需要家长知情并和学校说一下，学生提交材料，学校会给你保留学籍等待复学（期限为休学期间）。但办理复学手续可就不那么容易了，首先当时处于疫情下，学校是没那么容易进出了，需要通过学校的某个软件来申请，可由于我休学了，学院那边并没有将我的信息录入进去，导致软件压根无法证明我的身份。门口的保安可不管你进出校门做的事情，没证明就别指望进出学校。无奈，我只好联系我当时的辅导员，可保安也不认老师(真实情况就是这样)，就这样耗了 10 来分钟，保安看不下我母亲与我姐在旁边等候，才肯让我进去处理完手续。说真的，假设当天没有我家属陪同，复学恐怕就变成了辍学了。
\n进出大门的事情解决了，复学找老师签字可又没那么顺利了，具体细节我就不细说了，总之就是各种找老师签字，而有的老师今天在，有的不在，来来回回折腾了 3、4 天才把整个手续处理完，最终学是复了，书是也可继续读了，此刻的心还处在小孩子不愿上学的时代。
\n但仅仅只是一年，却正好让我赶上了学费和教案的变化。
\n休学是保留你当前的学籍，在你复学的时候，给你降级处理，将你插入到新的班级里，我原本是 2019 级的，我复学后变成了 2020 级。比较不幸的是，2020 级比 2019 级的学费还贵上 1000，我认了，毕竟这学校还有啥事情做不出来，涨点学费算什么（又不得不吐槽现在 2023 级的新生学费竟然还更贵！也确实，现在多数大学学费都上涨了）。这还不算啥，最主要是我们系的教授正好换人了，人换了也就算了，教案也跟着换，这就导致也就是我要比 19 级的学生还要多上几门课，并且有些课我还需要重新补修。妈的，什么坏事都让我遇上是吧。唉，谁叫我要休学呢。
\n而复学后学校发生的一些变数也是在我休学前未曾考虑到的，变相的让我毕业的难度增加。
\n你可能会比较好奇，为何不边上学边工作，而是要休学。我当时有两种想法，一种前面也说了，就是抱着辍学的心态，这里也就不在赘述。另一种就和我个人做事比较有关了，我做任何一件事情的前提就是不希望有其他事物来打扰，尤其是学校的因素，我学校是比较极端，规定的特别死，你想要实习只能在大四这个阶段(并且大四上还得上半个学期的课)，需要将课程修完才可。因此就有了休学。
如果仅仅是转专业+休学的话，其实就没什么好看的了，不过需要这些的铺垫才有后面一言难尽的故事。
在复学的第一个学期，在 2022 年 5 月 x 号的 22 点时，我工作室负责其他业务的同事突然打电话告诉我（语气还略带急促，我猜测是因为项目与他无关就放了），说我原先待的工作室的人都被抓了，说和我之前写的项目有关，叫我把相关代码全都删除了，这段时间不要联系他们。挂断电话后，我二话不说直接把我台式电脑搬到了其他宿舍，然后把我的另一台备用笔记本电脑放在桌上，我生怕 👮♂️ 第二天直接来我寝室来拿电脑。就这样提心吊胆几天，我内心暗自窃喜以为没事，毕竟我已经金盆洗手不做了，应该不会再追究吧，果不其然，越担心的事越会发生。就在几天后的周六中午突然来了一通电话，我一看 0xxxxx110 显示 xxx 公安局，完了看来是逃不掉了，但我还是抱着侥幸的心理，我选择了拒接就当我睡觉没看见（我当时确实因为这个电话而醒）。打了两通后没回应，又过了一段时间后，突然我姐给我打了电话，说我学校当地的派出所打电话给她，说联系不上我，然后叫我姐联系我看能不能联系上，顺便问我发生了什么事，我并没有告诉他，然而我心里很清楚，就是和我原本工作室的同伴有关。（至于说为什么 👮♂️ 有我姐的联系方式，我只能说我傻逼，每次学校填写什么表格的时候，有个家长联系人，我都是填写我姐的电话。也就是从这一阶段开始，所有要我填报的信息都是虚的）
\n然后我就回了公安局一个电话，和我确认完身份后，叫我带上 🆔 和 📱 叫我到学校门口，有 🚓 接送。我一上车后，就直接夺走了我的 📱（真），在车上就问我：”知道我们找你来是干什么的吗？“ 我默不作声，一直到了公安局后，接下来的安排懂的都懂，从中午做 📝 一直到晚上 8 点，从醒来到回校的期间别说吃东西了，连 💧 都 tm 没得喝。这一整个阶段就是要我交代当时写这个项目的负责了什么、盈利了多少、收款方式有什么，然后打开我手机的支付宝，微信，银行卡查我账户里的 💰，总之先把我号里的 💰 转到他们的卡里先，我当时和他们说微信里的 💰 我父母给我的生活费，也是我平常主要的消费方式，我也把相关的账单记录给他们看，确信后才没有将我微信的 💰 转过去。（这么一说似乎还挺良心）
然后 📝 做完之后，👮♂️ 说他们局长本来应该把我带到他们当地公安局一趟，可由于疫情的因素，就为我进行取保候审，（当然，这句话肯定是有吓唬成分），接着身份信息采集，打印账单记录，签字就不在话下了。至此在这个案件没结束之前，我都将作为一个嫌疑人处理。整个过程弄完之后叫我过几天再来一趟，主要就是二次笔录，在进一步确认哪些是“非法所得”。恰好我回去的时候还下起来大雨，还得用身体去遮挡着 👮♂️ 给我的那几份回执单，通知书。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307110122809.jpeg\")
你可能会好奇 👮♂️ 为何没有没收我的”作案工具“，首先我很明确的一点是我已经半年没碰这个项目了，其次我的“同伙”已经做好了相关笔录，也把大致的流程交代完毕，那么 👮♂️ 大概是已经掌握我做的部分了，再者我不像我的”同伙“第一时间被“逮捕”，距离第一时间已经过去了几天，我该处理的数据也都处理的差不多了，这时候再没收的意义也不大，得不到实质信息。
这也是我第一次体验到被任人处置的感觉，很不是滋味，这与学生时代被老师批评罚站或者被家长训斥不同，讲不清楚的感觉。在这期间，到目前现在印象还非常深刻的一句话：不如实交代的话，让你连书都读不了！
\n不过现在回想都是吓唬话，一种侦查的手段，只为了不择目的的获取更多的信息。因为 👮♂️ 从头到尾都没有直接通知我校，而是直接联系我本人，假设人家真的想让我读不了，直接联系学校，说明这个学生的行为，那么我必定会被开除（用开除学籍来保留学校的声誉）。不过最终学校还是知道了这件事，放到后面再说。
\n回到宿舍我便将台式搬回到原本的宿舍，坐在椅子上沉思了许久，殊不知我已经一天没吃饭了，然而此时的我毫无饿意，复杂的心绪让我发了条朋友圈：
\n![\"Untitled\"](\"https://img.kuizuo.me/202307110122810.png\")
至此，事实告诉我白白浪费了一整年的时间，并且此后还将给我带来了诸多麻烦。
\n但如今我回想这个事件，我都已经退出这个团伙近半年了，已经金盆洗手了，却依旧有所关联。👮♂️ 可不管你的解释，只要你参与了，获利了，势必要追究下来。如果我当时能够劝阻他们不做，或许如今就没有这么多麻烦事，可这仅存在于如果。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307110122812.png\")
回到这个项目而言，本质上确实不是很正规很传统，但也不至于黑产那种，更多的称呼是灰色产业。👮♂️ 给定性为 “提供侵入、非法控制计算机信息系统程序、工具罪”，但事实上这个程序并没有非法侵入服务器，我只是将用户的正常操作转变为电脑程序操作，将正常的数据包给模拟出来，可以省去人为操作的一个过程，而不是入侵对方的服务器，通过数据库的方式直接修改。在笔录期间，我还特意举例了游戏外挂和游戏脚本的区别，前者是实实在在的篡改数据，后者则是程序来模拟人为的情况，而我所做的部分就是游戏脚本的部分，根本不能算作非法控制。但 👮♂️ 不会按照我的理解，更别说检察院了，他们都只会认为这是在”破坏公平性“，那么就归属同一“恶劣”性质，就可以归属这个罪。总之我说的再多，说的再好，也都不及别人的一句反对。
\n这件事情过去快一年后，也就是取保时间要到之际（前段时间），👮♂️ 传唤几个当事人去他们当地的派出所一趟。对我而言，这段期间正好在读书阶段，此次之行大概率短时间内是回不来的，无奈之举，只能把自身的情况和辅导员说明清楚后，便踏上了不知用何形容词修饰的路。
\n在外地待了整整两周，住了整个两周的酒店。至于说过程也没啥特别的，一切都以流程为主，再次用 📝 核实了一下情况，从公安阶段移交到检察院阶段（此时一般就没 👮♂️ 的事情了），将材料都归递到检察院，等待公安这边解除取保状态(钱保)，再到检察院这边开具监视居住书，然后告诉我们可以回去等通知了。
\n所以情况就是这么个情况，抛开公安这边，回到学校的第一时间我就与辅导员汇报了情况，此时就不得不向学院解释我的情况了。
\n事实上学校是知道我这个事情的，因为当时当地的公安局的一位 👮♂️ 在与外地的 👮♂️ 配合，而这个当地的 👮♂️ 正好和我校学安处的老师比较熟，没过多久就找我谈了话喝 🍵（真），我将情况和他们汇报，但当时认为还没审判阶段，还只是嫌疑状态，所以就暂时不做处理。
\n直到了这次传唤之后，等我再次回到学校后，没过几天就被辅导员叫去和院长谈话了，在这谈话期间，我都一五一十的交代清楚，但听完我的叙述后，院长给我的态度其实并不友好。因为在他眼里可能也认为我编写的程序也不至于被公安传唤，再到检察院的阶段，便觉得我没有如实交代，说话的语气都带有警告之意，总之各种吓唬的口吻，院长也和 👮♂️ 说了几乎同样的话：“如果被我们查到事实和你所说的不符，那么我们这边会直接开除你”。最搞笑的是他还提了一下，如果被开除的话，也不要想不开什么的。就让我很无语，到底是安慰呢，还是警告。
\n![\"441703600436_.pic\"](\"https://img.kuizuo.me/202312262235233.png\")
至于为何要这么说，我想有很大原因是因为学生的负面因素会影响学校的名誉（挣钱），我想读过大学的人应该很清楚。但在谈话的期间，我表明了我是在休学期间做的事情，只是在校读书期间被叫去了（在校期间都没接触这项目），并且 👮♂️ 是没有直接通过校方来找我（我想是 👮♂️ 也不想麻烦学校），可以这么说，如果当地的 👮♂️ 与我校老师没有交识，校方可能都不知道我这个情况。但无论我如何解释，校方还是会以你是这个学校的学生身份来对你进行处理。
\n![\"Untitled\"](\"https://img.kuizuo.me/202307110122813.png\")
当然，我可以比较肯定的是，辅导员也不希望我出事，毕竟现在大学生如果出事，辅导员也是要背点锅的，但院长的话我就不清楚了，但从与他的谈话中，总感觉他不见得我好的样子。
\n不过要说学生身份是否对我有利的话，那答案是肯定有的。比如说开具学生在校证明，酌情处理等等。但不是说大学生就是免死金牌，这要是换成未成年人，那还说不准真是。
\n我想大致的剧情就交代了差不多，至于这一年期间找律师询问，找关系，操作什么的，我就不细说了，篇幅来的太长，且谈话内容很复杂，现实很残酷。我不想将这些负面，非正能量的东西传递下去，我本还是相信会社会会变得越来越善良的。但惟有一点我明白的是，没有办不成的事，只有到不到位是事。自我领悟这段话的意思。
\n回到这件事情，在来说说我的看法（补充）。
\n因为当时这个项目的收益都不是以公司的名义，而是通过多个下级使用私下转账到某个总账号（个人号），如果金额不是很大，那大概率也没什么事情，但金额一旦大，又没有缴税，这种做法无法就是非法经营。只不过项目涉及网络因素，且又有点灰产的性质，所以嘛。。。
\n从一开始这个收入形式就已经决定了 💰 的合法性，再加之利益摆在那，自然而然就被盯上。假设这个项目都没产生任何利益，没有破坏他人的利益，哪怕只是个灰产项目（开源），我认为 👮♂️ 不会折腾到去找你的麻烦。可以说没有利益与负面影响，就不会这么多麻烦事祸降到头上。
\n在笔录阶段，👮♂️ 的手段都会比较极端，希望当事人能够积极配合，透露出更多的信息，还告诉你能够酌情处理。但很多情况下，交代的越多反而不是什么好处，尤其在诱导性提问会让你偏向本不是你本意的回答。举个例子（算是真实例子，我听别人说的）：
\n某人 A 入职一个普通公司，就当 A 做了半年员工时，突然有一天警察突击这个公司，叫所有人双手抱头蹲下，A 不知道发送了什么，到了做笔录的时候，👮♂️ 告诉 A ，这家公司是一家诈骗公司，这时 A 开始思考，在一开始入职的时候确实不知道是诈骗公司，但 A 做了有半年的事情，慢慢也意识到自己做的就是诈骗相关的，但待遇不错，他也不当回事，也没有离职退出什么的。接着 👮♂️ 问他，你知不知道你做的是诈骗，这里假设 A 有几种说法：
\n假设你是 👮♂️ 你会抓谁，毫无疑问，1、2 是肯定要抓的，因为从回答和行为上都已经承认了是诈骗，哪怕只是一点都算。即便 A 想要翻供，可警察却说以第一次笔录上说准，说 A 当时已经都回答了，可 A 不知要如何反驳，甚至无法反驳。
\n但 3 的情况也许就不一定了，因为从 A 的笔录证词上，确实表明 A 主观不认为是诈骗，且是员工身份，雇佣关系，即便事实发生，只要诈骗的 💰A 没拿多少，而是工资形式，除非 👮♂️ 真的有 A 的诈骗实质性证据，那么 A 大概率是无事发生。
\n例子可能不是很好懂，但我想要表达的是：不要被 👮♂️ 的话语所带入，一切回答都要以不是、不知道为主，且不要模棱两可、含糊不清，这种回答在 👮♂️ 认为就是”肯定“，意味着是知法犯法。一定把自己装的什么都不懂，哪怕自己内心什么都知道，也要装成哑巴一般。
\n这就不禁让我想说出但不记得是从哪里看到的一句话: 坦白从宽，牢底坐穿；抗拒从严，回家过年。
\n试想一下，在上面的案例中，这个诈骗公司的技术人员与客服人员对比，你认为那么最后的结局会比较惨。再比如某技术人员不小心写错了代码，并且将其部署到线上环境，导致公司损失重大，你说责任在谁？
\n这样例子有太多了，很多情况下出了事情，技术人员要占据非常大的责任。但伴随这份责任的风险，也伴随着巨大的收益，风浪越大，鱼越贵。
\n如果说没有这些变故，那我毫无疑问是无悔的，因为挣到了本不属于我这年龄段所拥有的资本。
\n论事实，这些资本化为乌有，同时耗费了一年的时间的情况下呢？那必然是会后悔一部分，我后悔的是没有听从我父母的劝导，在合适的时间做合适的事情，给家里人带来了许多的麻烦；而不后悔的是这段经历，让我成长了太多，让我如此膨胀的内心收敛的甚许，也让我在做任何事情都要三思而后虑，而不再一意孤行，固执己见。
\n提前发现自身的错误，及时纠正，以免重蹈覆辙。有很多道理也是在我经历之后才深刻明白的，只不过这次学习的“学费”比较贵重。
\n年轻难免犯错，但也正是从错误中成长。
\n故事的经历就告一段落，未来的路还很长，要考虑的事还有很多，有机会在慢慢叙述。
\n我想听完上面的叙述应该能解释的通这近两个月的状态情况。
\n我本以为奖励自己搞台 MacBook 能够将状态调整回来，然而不到 1 周的时间变又开始萎靡不振，对一切新鲜事物失去了好奇感。已没有当初纯粹的兴趣，留有的是对生活的无奈。找寻不到花费一晚上解决一个 bug 的成就感，留有的只剩错中复杂的需求与枯燥乏味的工单。
\n我开始思考问题的所在，如何长期保持某种状态。最关键的因素莫过于情绪，曾经的我能够保持不断学习的状态正是因为内心无忧无虑。可时至今日，伴随我的是焦虑、压力、不安、迷茫，总觉得心里悬着什么东西放不下，可至今我也没能找到很好的解决方案，也许等案子结束，一切都将会从容自如。
\n我曾收到一本书，名为《谁的青春不迷茫》，到现在为止我也没看过，为什么呢？就书名而言，在我收到这本书时，我不认为我有何迷茫的地方。可现在我又想重新拾起这本书，却不知这本书被我放置何处。
\n在对这个社会没有认知的前提下（即休学前），我自认为能力是完全能够胜过一本的证书。外界都说没有本科不好找工作，现如今怕是本科都不好找工作咯。就我事实而说，我的几份工作都不是本科给我的，而是我的项目经验，所以也因此我更加坚信我自己对本科证的蔑视看法。
\n但有两段经历(谈话)，改变了我对此的看法。
\n在我与一位 40 岁的技术人询问过一些问题，其中一个问题是问国内读研还有必要吗，人家没有直接否定，而是直接告诉我，很多公司现在阅读简历会更偏重于看第一学历(本科的学历)，也就是看你本科学校好不好再看你其他学历，至于为何想必不用多说，高考考进清华和研究生考进清华的难度便知。
\n而另一个问题就是问他本科有没有必要，而就举了他曾经项目投资的例子，说如果投资人发现要投资的项目的负责人没有本科学历，人家可能就不会投资了，大致意思是这样。
\n一位国外华人的 hr，看到我写的一个作品，并且他公司正好急招一名相关的开发者（远程开发），便于我交谈了起来，然而他没想到的是我竟还未毕业，而他们招聘的最低要求便是本科生。然后又进行了一番简单交谈下，得出的结论是：以我目前的身份只能开实习生或高中学历的薪资（薪资差距在 4 倍左右，国外的待遇我不说具体的薪资你大概也能猜出有多少），hr 给的建议是对我来说就是拿着点薪资就有点浪费时间，于是便错过了这个 offer。
\n我觉得没有什么能比收益更具有说服力，因此也确确实实改变了我的看法，至少在中国是这样的。
\n就单从社会展示的数据上也可以知道，自考成人本科的人是越来越多，很多公司招聘都是本科起步。没经历只看数据对我而言是意识不到其重要性的。
\n本科固然重要，可反观现在中国的大学还是用来学知识培养人才的吗？我更倾向于说是用金钱消耗时光最终换来一本证书，至于这笔交易值不值这个价，我想多数大学生的内心已经有了答案。
\n如果要说大学对我来说最大的作用的一件事，无非就是白嫖各种大学生认证优惠（如苹果的教育优惠，github 学生认证，学生票等等），确实给我省下了不少的钱。除此之外，我很难再说出第二个实质性的作用，对我而言是更多的负面作用，例如高学费、断电断网以及学校一些系列蛮不讲理的行为，这种作风会在私立大学之间不断扩大。
\n在之前我是比较浮躁的，总想着如何一步登天，并且我与很多平常人不同，我是不走”寻常路“，不遵循“规则”的人。绝大多数人愿安安稳稳，但我可不，我宁可去冒险一番，却又不曾思考过失败的后果。
\n我很讨厌被安排，被安排的人生，活着有什么意义？ 没有自己的主见想法，不断被灌输他人的思想，这便失去了我对生活的意义。不能做自己想做的事情，那真的是一件极其可悲的事！
\n但现在让我重新做一个选择我肯定和我原先的同学一样是安安稳稳（混日子）拿个毕业证，求稳已经变为了我当下一个很重要的标识，只要主观上有风险的事，哪怕利润再高，我也不会尝试一番，我经不起风险，至少在我没有绝对”保险”的前提下。
\n可如今的现状又怎么走的了宽敞，平坦的道路。也许生来就不应该平淡度过，最终要身处何处才能对的自己颠沛流离的一生。
\n人总是不愿听闻他人的建议，尤其这个建议还是长辈给予的。可多数人总会认为自己就是最正确的，自己的做法就是最优解，过度的自信很难看清自己几斤几两。长辈的建议是用他的人生阅历换来的，而你的想法是凭空而造，不切实际。（说的便是我自己）
\n很多建议仅仅只是传达给他人，他人即便意识到有道理，但也通常不会有所改变。只有自己亲身经历过后，回想起他人的建议是多么的宝贵。所以我也渐渐不怎么再给别人安利，反而是一种浪费口舌的行为。
\n曾经我是一个特别念旧的人，时常会怀念过去的巅峰、美好。因为在落魄之时，也能想起曾经所拥有的，让我重拾信心。能让自己不断前行的事物只有自己所经历的过去，而记录便成了我仅有回忆方式。
\n可现实却是不断打击我曾有的美好，好像上天就巴不得我好的样子。可没有什么上帝，任何事物所发展的结果都将有始有终，自己做的事情没有人比自己清楚，我曾怪罪自己运气不好，现在我意识到是努力不足。没有不幸之人，只有懒惰之徒。在绝对的实力面前，运气再差的非酋都能化身变为欧皇。
\n曾经有个人告诉我，凡事都要往前看，只迷恋于过去只会让自己活得越加困难。可当时的我怎么可能懂得这个道理，活在过去的美好之中，忘却了当下的目标。
\n不知道自己当下要做什么，是因为不知道未来要干什么，没有目标的未来，犹如没有罗盘的航行，在茫茫大海之中无处漂泊。
\n借阿甘正传的一句名言：
\n\n\nYou got to put the past behind before you can move on.(你得把过去抛在脑后才能向前看。)
\n
const timeline = ['易语言', '逆向', 'JavaScript/TypeScript', 'Web 全栈']
timeline.forEach(time => console.log(time))
回到技术角度，随着我的 4 年编程经历就这么过去了，和曾所预期的技术要求还差之甚远，没能给自己一个很好的技术交代，没能在这四年结束之际进行编码，没能给这段经历一个完美的句号。
\n倘若没有编程，我甚至都不知道自己应当从事何种职业，可以说编程是我的再生父母，没有 4 年前那场偶遇，便没有如今的我。
\n道阻且长，行则将至；行而不辍，未来可期。
", "url": "https://kuizuo.me/blog/narrate-a-college-student", "title": "叙一名转专业+休学的大学生经历", "summary": "我一般很少做年中总结，但是这上半年发生在我事情比较多，加上毕业季，万千感慨涌上心头。", "date_modified": "2023-07-11T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "年终总结", "人生感悟" ] }, { "id": "https://kuizuo.me/blog/macbook-experience", "content_html": "首先我不是 iphone 用户，甚至是果黑（苹果的小黑子，合理来说是苹果手机的小黑子），所以我一向从内心就很摈弃苹果的产品。因此我从来没体验过 MacOS 系统，用了近 4 年 window，不过由于我的那台 window 本 （21 年小新 pro14） 给我的体验非常差，虽然说续航勉勉强强足够支撑我一个下午的开发，但 intel 的 i5 cpu 我就没打算将其作为主力机开发（根本做不了），更多是使用向日葵远程桌面软件来远程连接到我的台式电脑，远程操控来进行开发。然而由于屏幕分辨率不同以及网络延迟，这样的体验长期下去必然会崩溃。因此更换自己的移动办公设备已经成了我当下的刚需。
\n见识到诸多程序员大神都将 mac 作为主力开发机器，同时又被安利过很多次 MacBook，但我一直对 macOS 保持观察的态度，自己从未亲自体验过，最多也就看别人用用，在 window 上这些同样也能实现，何必要多此一举再去了解一个新的系统，新的操作逻辑。但直到我真正接触并体验过 macOS 后，我便爱不释手。
\n在写这篇文章时，我已经用了近一周的 macbook，因此想分享个人的购买流程、选购建议、使用感悟，或许对于某些想要尝试 MacOS 但又保有迟疑态度的用户有所帮助，也算是给曾经的我对苹果的偏见的转变。
\n\n\n拖更了近两个月的博文了，摆了一整子，说来也确实有些许惭愧。不过目前生产力工具已就绪，也要开始步入正轨。
\n
我是在线下 apple 授权店买的，五一假期的前一天晚上逛商场的时候正好经过，于是进去与店员交谈了一整子，又思考了一晚上，最终决定第二天直接现货 购买了丐版（标准版）的 macbook m2 pro 14 寸 16g + 512g。
\n至于选择 14 寸还是 16 寸，就因人（钱）而异，去线下给我最大的感受就是 16 寸是真的大，且厚重（14 寸也挺重的有 1.6kg），通常我在室内我就会拓展外接显示器加上偶尔有床上办公的需求所以在看到第一眼后便毫不犹豫的选择 14 寸作为我的目标尺寸。
\n至于说选择 m2 pro 还是 m2 max，这条链接与下图能告诉你答案。
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428893.png\")
其次就是选配方面，在之前我是打算购买 32g + 1t 的。但在如今一堆 electron 应用（一个就要吃至少 100m 的内存），加上我本身的会有多开几个 vscode 以及多个浏览器标签， 16g 内存在 window 下对于开发从事者而言已经不够使用了，在 mac 上 从我的事实也证明 16g 内存 在两个正在运行中的 node 与 的 10 来个浏览器标签，加上一些常用软件（微信、QQ、飞书、）是有些不够用了，以下对应的活动监视图（window 中的任务管理器）
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050429190.png\")
虽说有 swap，表面上的 16g 物理内存实际上运行内存可能会更多，但最主要还是看内存压力。不过即使是这样，系统也没有出现过任何的卡顿，这要是换 windows，恐怕已经蓝屏了。等哪天内存压力变红时或者出现卡顿现象，再来汇报相关进程。（新买的机子，不舍得压力测试折腾她）
\n而 m2 pro 的 512g 相比 1t 读写速度减少一半（看下图你便懂了，单通道的速度和两个 512g 组双通道相比），事实上在之前的丐版都存在这种问题，可以说苹果是巴不得你加购硬盘容量，不然硬盘速度缩半。
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428895.png\")
而 1t 及以上容量自然是无该问题，何况不加配的 mac 能叫 mac 吗。我其实是很想加配的，但无奈无现货，并且官网定制这个配置（m2 pro 32g + 1t）的还需要等待 2 个星期，据店员说“这只是预计，实际可能会更久“，不过这里不排除店员这么说诱导我在购买丐版现货。
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428896.jpeg\")
不过最终能让我购买的很大原因是在五一期间我实在不想用那破 window 本，因此第二天再次联系店员决定直接付款拿丐版现货。因为考虑两年后大概率也会更换电子设备（距离我上次更换电子设备也过去两年），所以综合考虑当前的配置在这两年应该是足以使用（这句话也许说的有点早）。
\n实体店与线上购买没有本质的区别，价格上都是一致的，也是有教育优惠的。只是人家会帮你激活设备，在你的眼皮子底下看看有无问题，确认无误后，交钱走人便可。此外可能还会赠送一些额外的一些配件，如键盘膜，屏幕膜，清洁套装，拓展坞（没有手提包），不过这些对我来说都非刚需，只要 MacBook Pro 没问题即可。
\n不过这里想要提一下，人家是挺极力推荐我购买 apple care 的（顺带有个配件券），据我了解，貌似是有一个 apple care 的指标，需要达到多少这样。不过我个人不喜欢买保险，因此便没有购买。
\n不要贴膜，不要贴膜，不要贴膜!
\n我本是不想贴膜，喜欢裸机的感觉，但由于附送一个屏幕膜，我便勉为其难的贴一下，然而当我贴完后我随即将辛辛苦苦贴好的膜又给撕了下来了，并不是因为我贴的不好，而是贴膜简直就是负提升，前后对比是肉眼可见明显，这里我用相机拍不出肉眼那种效果，如果说喝枸杞是养生，那看 macbook 屏幕说是养眼可一点不为过。毕竟维修一个 Macbook 屏幕就需要 5000 左右，让我萌生一丝购买 apple care 的想法。
\n其次就是网上都有流传 macbook 的 B 面(屏幕)与 C 面(键盘)之间的间隔特别薄，贴屏幕膜或键盘膜可能都会让这层素质极高的屏幕受到一些损害。还有贴屏幕膜后，在下一次更换屏幕膜的时候，可能会导致屏幕涂层脱落，而贴键盘膜的话，时间久了会导致合盖的时候键盘膜印在屏幕上。总之，基本都是建议裸机。
\n这里我推荐自己我自己看过的几个 mac 相关指南，能够帮助小白速度上手 mac。
\n\n【看完秒懂】Mac 苹果电脑超详细上手入门指南！建议做笔记！up 良心制作，用一集视频包你熟练上手 Mac_哔哩哔哩_bilibili
\n下面这个会比较针对与程序开发
\n2022 我用 MacBook Pro 整一年 【感想 与 踩坑指南】 - 掘金 (juejin.cn)
\n由于我使用时间较短，因此软件方面我不好做出评价与推荐，这里我只附上一张我已安装应用截图
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428897.png\")
如果要说使用的这段期间对笔记本电脑的体验变化无意有两点，一是颠覆我对笔记本触控板难用的想法，二是应用全屏（配合台前调度）却能够有如此高效的体验。
\n这一部分我认为不必过多吹捧，亲自到线下实体店感受才最为真实，相信我，你会爱上触摸板了。
\n以下内容为使用 8 个月后的补充。
\n由于内存的不足加上重度开发，现今我的电池容量已达到 93% 了，说实话是有点小心痛的😭。
\n![\"\"](\"https://img.kuizuo.me/2024/0114155525-202401141555937.png\")
这与我一些不好的使用习惯还是有关的，我通常会打开好几个标签页，好几个 应用而不关闭，这就导致内存时常处于高负载状态下，不断的从硬盘中拿内存，这样不仅伤硬盘同时也伤电池。此外我通常会用 Type-c 一线连接外接显示器（既可以充电又可以显示），加上我没有拔电以及关机的习惯(可能要过好几周才会重关一次)，这就导致 8 个月的时间内电池最大容量缩减。
\n现在来看或许当初买个 apple care 还能免费换个电池似乎还划得来。
\n现在可以毫不犹豫的说，我会选择 macOS，下一台笔电也会选择 macOS 系统。但并不是说什么场景，macOS 都是最优选，就比如说游戏需求，我想没人会买台 mac 来作为自己的游戏机。mac 上几乎玩不到什么 3A 大作，甚至在 m2 芯片上，你可能都无法下载 wegame 来玩上一把英雄联盟。
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428898.png\")
如果你有桌面游戏的需求，建议拉黑 mac。此外还有一些 window 的专业软件，你在 mac 上可能找不到与之对应或平替的软件，尤其是在大学课程中，老师几乎不可能给学生发个 dmg 文件，如果你在大学期间买 mac，又要兼顾学校的课程软件需求，又不得不安装 window 虚拟机，与其如此折腾不如一开始就选用相对便宜的 win 本，还能减少一些经济压力。不过我觉得大学老师上课所说的一些软件都没必要安装，反而占用一些不必要的空间，（vc++、eclipse 等等），如果你们老师提到了 Vscode 那当我没说。
\n但出色的系统、高素质的屏幕，注定能让 MacBook 能够成为某部分群体的生产力工具，挣钱的机器。选用 macbook 的用户想必都希望在它任职期间产生数十倍的价值，当然排除我这个买来尝鲜的。
\n目前手头的三台电脑设备对应的 CPU（性能从高到低）M2 Pro > AMD 5900x > i5-11300H
\n![\"Untitled\"](\"https://img.kuizuo.me/202305050428899.png\")
![\"Untitled\"](\"https://img.kuizuo.me/202305050428900.png\")
这里我没找到比较好的前端 benchmark 项目，但就从我个人直观的体验与在这三台机器启动同一个前端项目启动打包来看，在冷启动上，m2 pro 耗费 1.7s, 5900x 耗费 2.8s，i5-11300H 我都不想拉项目，去年的暑假靠这台 win 本进行开发，别提体验有多差，每次都需要干巴巴的干等项目完全启动就需要等个 2、3 分钟（不夸张），有时候可能因为某些特殊原因需要重启服务，好的，又浪费个 2、3 分钟。影响你效率的可能不只是环境，还有你的机器。
\n冷启动都能有近 1s 的优势，就别提热加载和打包速度上，这里直接给出我打包一个 Nuxt 项目的打包时间输出耗时，m2 pro 耗时 27s、5900x 耗时 116s（数据真实有效），快的让我有点感觉我是不是少写了某部分代码，还是说多注释了些代码。
\n性能优势可能不是最大的优势，但编程环境上 Mac 绝对比 Window 来的好，一个 Homebrew 就已经能解决百分之 90 的编程语言环境，而这换到 Window 上则有诸多的安装方式。至少你不必像 Window 那样还需要打开设置面板配置环境变量。而 MacOS 与 Linux 又非常相似，都可以在命令行中运行 Unix、bash/zsh、以及其他 shell 命令. 所以至少从 代码 开发方面, Mac 绝对比 Window 来的好，这也是多数开发人员选择 Mac 的原因。
相对遗憾的是购买的还是相对匆忙，就是没有加配 32g，虽说目前来说 16g 勉强能够应付绝大部分场景，但免不了后续爆内存，又无能为力的情况。但想到自己仿佛挖到了一个新世界的宝藏，这种担忧就显得不足为惧。
\n在写完这篇稿子时，回头用起 win 时，都习惯性的按下 Alt + C 键位，殊不知 Ctrl + C 才是 win 的复制。适应也许只需要几天的时间，但回去也许可能大半辈子都不再回去。
从被别人安利到用 mac，再到自己安利别人用 mac，这种对 macOS 系统相见恨晚的感受，也许只有使用过 macOS 的人才能理解。很多东西只有自己用过才知道，只有尝试过，才知道适不适合自己。不尝试并不会丢失什么，但尝试过后往往能够收获意想不到的东西。
\n如果你还没有尝试过 macOS 系统，那么你或许真的错过了很多。
", "url": "https://kuizuo.me/blog/macbook-experience", "title": "MacBook 体验有感", "summary": "作者是一位从来没用过苹果产品的程序员，但在使用了一周的 MacBook Pro 14 寸后，便爱不释手。", "date_modified": "2023-05-05T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "macOS", "MacBook", "记录", "使用体验" ] }, { "id": "https://kuizuo.me/blog/why-i-dont-write-notes", "content_html": "当我起这个标题时，其实我已经很久没更新（翻看）过笔记了，甚至我都不记得我的博客还有笔记这个东西。
\n当我翻阅 git 记录，寻找上一次在笔记文件夹的 commit 提交记录，还是在去年的 10 月 1 号。
\n![\"image_U0EDw0PkAf1\"](\"https://img.kuizuo.me/U0EDw0PkAf1.png\")
然而并不是我的技术栈没更新，而是我实实在在没去为这些技术栈编写过笔记。仅有的只是博文来记录自己所用的过程。
\n因此我想思考下我为何不记录笔记。
\n首先不妨回答一下我所认为的笔记意义。
\n当我需要回忆我曾经学习过的某个知识点时，笔记可以说是最直接有效的办法。与其再次使用搜索引擎搜寻答案，不妨直接从答案中找答案。
\n\n\n正如我笔记简介所述：做到即查即用，能复制粘贴解决的，就绝不百度。
\n
相比绝大多数笔记内容都是初学者去记录自己所学，在这个阶段，你对知识的掌握程度是比较浅显的，而笔记无非能加快你的理解，同时也是是成本最低的，翻看自己的内容远比理解他人的内容来的简单。
\n很多初学者除了通过视频教程来学习，当然不乏有些人是通过别人的学习经验（即笔记）来进行学习，包括我一开始也是通过刷别人的笔记来学习某个知识。
\n不过相对于视频而言，视频通常很啰嗦且时长感人（动辄可能数天的时长）。很多人不喜欢铺垫，不喜欢废话，就想知道某个知识点怎么用，结果如何。同时视频没有搜索功能，如果视频创作者没有对视频进行分集，当你需要回看的时候时，你往往需要从数十分钟的视频中不断的拖动，甚至到最后才发现原来我看的不是这个视频。
\n而文档则不会，那你可以通过 Ctrl + F 搜索你想要的关键字，相比视频而言，检索的效率将会大大提升。
\n这也是我为何从视频学习转成文档学习很重要的原因。我也很推荐如今的学习者从文档学习，而不是视频学习。
\n笔记无疑是耗时的，你可能会花费数个小时的时间，去总结一个可能你职业生涯中都用不到几次的知识。
\n为什么这么说，因为我发现我有很多笔记就是这种情况，你也可以回想一下你所记录的笔记，有多少是经常使用到的。
\n尤其是当你使用的足够多的情况下，你甚至都无需翻阅笔记。脑海中自然就会复现出你需要的东西，此时为何还需要看笔记。为了验证脑海中的正确性吗？
\n想想看你会为怎样的知识点大费周章的记录，是一个自己都不怎么用的知识点，还是用到滚瓜烂熟的知识点？
\n当我们经常使用某些知识点时，自然而然就会记住它们，这时笔记就没有太大的意义了；而对于使用频率较低的知识点，记录下来的意义也不是很大。
\n究其原因，还是因为我翻看笔记的频率变少了许多。如今的搜索引擎很智能，只要你用的不是百度，就能很快速的搜寻到答案，为何还需要记录一下，换成自己熟悉的口吻，到最后就变成上面所说的那样。而在 ChatGPT ，new bing 的诞生下，更加剧了我这一行为。
\n当搜索大于记录时，笔记就显得弱不禁风。
\n说实话，当你看到别人的笔记的时候，你会认真的从头到尾看一遍吗？我想不会，更多情况我们只利用搜索功能去获取我们想要的知识点。
\n但如果此时有两份文档，一份是官方的技术文档，一份是他人的学习笔记文档。你会选择哪一份？是我肯定毫不犹豫的选择前者，他人的学习笔记并不会及时更新，但官方文档只要还在维护，那么必定处于常更新的状态。假设我照着他人的学习笔记学习，此时正好有个函数的使用方法更新了，那么我必定会踩坑，导致不必要的 bug。而官方文档则不会，官方一旦有破坏性更新，通常会有显眼的提示，和 changelog 可供我参考，这就能及时有效的帮我排除不必要的坑。
\n这也是我为什么会宁愿去看官方文档，哪怕是英文的，也绝不愿去看第三方中文翻译后的文档，我有太多的坑就是因为更新不及时，存在信息差导致的。所以无论如何，能获取一手的信息，就别用二手的，甚至你也不知道人家会加工成什么样子。
\n综上，我想我已经把我为何不写笔记的原因讲述的比较清楚了。
\n当然我并不是说笔记就一无是处，因为每个人，每个阶段的学习方式不同。曾经我也是笔记学习的追崇者，但如今的我能够不借助视频教程，不借助笔记来进行独立学习，所以为何不选择一个对我而言更高效的方式。
", "url": "https://kuizuo.me/blog/why-i-dont-write-notes", "title": "距离我上篇笔记还是在?", "summary": "当我起这个标题时，其实我已经很久没更新（翻看）过笔记了，甚至我都不记得我的博客还有笔记这个东西。", "date_modified": "2023-03-13T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "杂谈" ] }, { "id": "https://kuizuo.me/blog/typescript-full-stack-technology-trpc", "content_html": "如果你想成为一个 Typescript 全栈工程师，那么你可能需要关注一下 tRPC 框架。
\n本文总共会接触到以下主要技术栈。
\n\n不是介绍 tRPC 吗，怎么突然出现这么多技术栈。好吧，主要这些技术栈都与 typescript 相关，并且在 trpc 的示例应用中都或多或少使用到，因此也是有必要了解一下。
\n在线体验地址：TRPC demo
\n在介绍相关技术前，不妨思考一个问题。
\n\n\n当进行网络请求和 API 调用时，你是否知道本次请求的参数类型以及返回的响应数据类型？知道了请求的数据类型与响应的数据类型，会为得到的 json 数据定义 type/interface，使其有更好的类型提示？还是会在 any 类型下获取属性，但由于没有类型提示，导致写错个单词，最终提示 Cannot read properties of undefined (reading 'xxx')？
\n
对于大部分前端应用而言，类型往往常被忽略的，这就导致不知道这个请求的提交参数、响应结果有什么数据字段。举个 axios 发送 post 请求的例子
\n![\"image-20230308142331808\"](\"https://img.kuizuo.me/20230308142331808.png\")
这是一个 post 请求用于实现登录的，但是这个响应数据 data 没有任何具体提示（这里的提示是 vscode 记录用户最近输入的提示），这时候如果一旦对象属性拼写错误，就会导致某个数据没拿到，从而诱发 bug。同理提交的请求体 body 不做约束，万一这个请求还有验证码 code 参数，但是我没写上，那请求就会失败，这是就需要通过调试输出，甚至需要抓包比对原始数据包，其过程可想而知。
\n最主要的是没有类型约束的情况下，非常容易出现访问某个对象属性不存在，js 开发者肯定经常遇到如下错误提示。
\nCannot read properties of undefined (reading 'xxx')
有太多时候就是因为没有类型，无形间诱发 bug，这也是很多做 api 接口都常常忽视的一点。
\n\n\n因此我个人所认为的未来 Web 框架形态是要满足的前提就是前后端类型统一，即可以将后端的类型无缝的给前端使用，反之同理。而像 Next、Nuxt 这样的全栈框架便是趋势所向。
\n
当然 axios 是可以通过泛型的方式拿到 data 的数据类型提示，就如下图所示。
\n![\"image-20230308142452678\"](\"https://img.kuizuo.me/20230308142452678.png\")
但这样为了更好的类型提示，无形之间又增加了工作量，我需要定义每个接口的 Response 与 Body 类型，就极易造成开发疲惫，不愿维护代码。而本次所要介绍的技术栈 tRPC 就能够帮你省去重复的类型定义的一个 web 全栈框架。
\ntRPC 是一个基于 TypeScript 的远程过程调用框架，旨在简化客户端与服务端之间的通信过程，并提供高效的类型安全。它允许您使用类似本地函数调用的方式来调用远程函数，同时自动处理序列化和反序列化、错误处理和通信协议等底层细节。
\n借官方 Feature
\n这个问题非常好，因为我在了解到 tRPC，并参阅了一些基本示例与实践一段时间后发现 trpc 和 http 的应用场景可以说非常相似，完全可以使用 trpc 来替代 http，只不过写法上从 发送 http 请求 ⇒ 调用本地函数（这在后面会演示到）。
\n而 trpc 又以类型安全与高效著称，如果你的 Web 应用的程序是基于 typescript，并且需要有高效的性能，那么 tRPC 就是一个很好的选择。
\ntRPC 可以作为 REST/GraphQL 的替代品，如果前端与后端共享代码的 TypeScript monorepo，trpc 则可以无需任何类型转换，也不太会有心智负担。
\n请记住，tRPC 只有当您在诸如 Next、Nuxt、SvelteKit、SolidStart 等全栈项目中使用 TypeScript 时，tRPC 才会发挥其优势。
\n一图胜千言，你可以点击 这里 在线体验一下 tRPC，并且查看其目录结构，以及调用方式。下面我一步步讲解如何进行接口调用。
\n这里以 Next.js 的目录结构而定。创建 server/trpc.ts，如下代码。分别导出 router, middleware, procedure
import { initTRPC } from '@trpc/server'
const t = initTRPC.create()
export const router = t.router
export const middleware = t.middleware
export const publicProcedure = t.procedure
创建项目(根)路由文件 pages/api/trpc/[trpc].ts
import * as trpc from '@trpc/server'
import { publicProcedure, router } from './trpc'
const appRouter = router({
greeting: publicProcedure.query(() => 'hello tRPC!'),
})
export type AppRouter = typeof appRouter
此时已经定义好了一个路由地址 api/trpc/[trpc].ts（这里 endpoint(端点)会在客户端中使用到），以及 greeting 函数，服务端的工作就暂且完毕。
创建 utils/trpc.ts 文件，代码如下
import { httpBatchLink } from '@trpc/client'
import { createTRPCNext } from '@trpc/next'
import type { AppRouter } from '../pages/api/trpc/[trpc]'
function getBaseUrl() {
if (typeof window !== 'undefined') {
// In the browser, we return a relative URL
return ''
}
// When rendering on the server, we return an absolute URL
// reference for vercel.com
if (process.env.VERCEL_URL) {
return `https://${process.env.VERCEL_URL}`
}
// assume localhost
return `http://localhost:${process.env.PORT ?? 3000}`
}
export const trpc = createTRPCNext<AppRouter>({
config() {
return {
links: [
httpBatchLink({
url: getBaseUrl() + '/api/trpc',
}),
],
}
},
})
在 _app.tsx 包装一下
import type { AppType } from 'next/app'
import { trpc } from '../utils/trpc'
const MyApp: AppType = ({ Component, pageProps }) => {
return <Component {...pageProps} />
}
export default trpc.withTRPC(MyApp)
有了这个对象后，我们就可以开始尽情调用服务端所定义好了函数了。
\n当你导入 trpc 并输入 trpc. 时，将会提示出服务端定义好的 greeting 函数，如下图所示。
![\"\"](\"https://img.kuizuo.me/YDKc7TixQA.png\")
此时通过 const result = trpc.greeting.useQuery() 便可调用 greeting 函数，其中 result.data 便可拿到 'hello tRPC!' 信息。
\n\n\n
不妨此时打开控制台面板，看看请求
\n![\"\"](\"https://img.kuizuo.me/WfW8ehqUKz.png\")
![\"\"](\"https://img.kuizuo.me/qicvoGjshx.png\")
不难看出，调用 greeting 函数本质是向 /api/trpc/greeting 发送了 http 请求，并且携带参数 batch 和 input，虽然我们暂时还没有传。默认 input 为 。
要支持传递参数，首先需要在服务端定义传递参数的类型（会有 Zod 对参数效验），这样客户端才有对应的类型提示。然后调用 greeting 函数时，通过通过函数参数的形式来传递请求参数。
\n举例说明，比如说我们将 appRouter 改写成这样，通过 input 参数指定了 useQuery 需要传递一个 name 为字符串且不为空的对象。
import z from 'zod'
const appRouter = router({
greeting: publicProcedure
.input(
z.object({
name: z.string().nullish(),
}),
)
.query(({ input }) => {
return {
text: `hello ${input?.name ?? 'world'}`,
}
}),
})
调用 trpc.greeting.useQuery({ name: 'kuizuo' }) 发送的请求的 query 参数则变为
![\"\"](\"https://img.kuizuo.me/20230307214659.png\")
不仅于此，你如果同时调用了多次 greeting 函数，如
\nconst result1 = trpc.greeting.useQuery({ name: 'kuizuo1' })
const result2 = trpc.greeting.useQuery({ name: 'kuizuo2' })
const result3 = trpc.greeting.useQuery({ name: 'kuizuo3' })
tRPC 会将这三次函数调用合并成一次 http 请求，并且得到的响应本文也是以多条数据的形式返回
\n![\"\"](\"https://img.kuizuo.me/ufrhaugaIj.png\")
![\"\"](\"https://img.kuizuo.me/cvlDJjhwPl.png\")
分别输出三者 result 也没有任何问题。
\n![\"\"](\"https://img.kuizuo.me/hbL8So_RzB.png\")
这是 tRPC 的一个特性：请求批处理，将同时发出的请求（调用）可以自动组合成一个请求。
\ntRPC 同样也支持 post 请求，例如
\n服务端代码
\nconst appRouter = router({
createUser: publicProcedure.input(z.object({ name: z.string() })).mutation(req => {
const user: User = {
name: req.input.name,
}
return user
}),
})
客户端代码
\nexport default function IndexPage() {
const mutation = trpc.createUser.useMutation()
// ERROR!
// mutation.mutate({ name: 'kuizuo' });
const handleCreate = () => {
mutation.mutate({ name: 'kuizuo' })
}
return (
<div>
<button onClick={handleCreate} disabled={mutation.isLoading}>
Create
</button>
{mutation.error && <p>Something went wrong! {mutation.error.message}</p>}
</div>
)
}
这里需要注意 mutate 方法无法在外层直接调用，否则将会提示
Unhandled Runtime Error
Error: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
主要防止这个组件被其他组件调用，此时自动调用 mutate 函数，导致不可控且循环调用的情况，因此需要通过一个事件（比如点击事件）来触发。
此时请求变为 post 请求，并且携带的参数也以 body 形式传递。
\n![\"\"](\"https://img.kuizuo.me/-qEI8jR1uM.png\")
![\"\"](\"https://img.kuizuo.me/RTdWJn_55p.png\")
通过 useQuery 和 useMutation 就能够用 tRPC 实现最基本的 CRUD。此外还有 useInfiniteQuery 可以用作类似无限下拉查询，类似 SWR 无限加载。useQueries 批量查询，使用 Subscriptions 进行订阅 WebSocket 等等。
\ntRPC 针对 react 项目的查询主要依赖于 @tanstack/react-query，你也可以到 tRPC React Query documentation 查看相关 hook。
\n从上述例子中你就会发现，tRPC 将 http 请求给我们包装成了函数形式调用，即上文所说的，调用服务端接口的形式由 发送 http 请求 ⇒ 调用本地函数。
\n不过也并非没有缺点（个人认为）。
\n首先不如传统的 RESTFUL 来的直观，假设我现在在服务端定义了一个服务，那么我只能通过@trpc/client 创建客户端进行调用。虽然也能用 http 的形式，但调用的很不优雅。
在我印象中，RPC 框架通常是可以跨语言进行调用的，比如 gRPC 框架，然而tRPC 目前只能在 Typescript 项目中进行调用，我倒是希望能向 gRPC 那个方向发展，不过不同语言间的类型安全又是个大麻烦。
\n学习成本与项目成本偏高，tRPC 对整个全栈项目的技术要求比较高，并且限定于 typescript，如果你想将你的项目从传统的 Restful 迁移到 tRPC 上，无疑是个工程量大，且不讨好的事。
这里选用 Create T3 App 用于创建应用（也可以选择 trpc/examples-next-prisma-starter），Create T3 App 集成了诸多有关 TypeScript full-stack 相关的技术栈，其中就包括了本文所要介绍的几个技术栈。
\n![\"\"](\"https://img.kuizuo.me/8BUcBPK8In.png\")
pnpm create t3-app@latest
安装过程如下
\n![\"\"](\"https://img.kuizuo.me/ERGzEt2Tq8.png\")
此时安装完先别急着 pnpm run dev 启动项目，首先执行
\nnpx prisma db push
运行结果如下
\nEnvironment variables loaded from .env
Prisma schema loaded from prisma schema.prisma
Datasource \"db\": SQLite database \"db.sqlite\" at \"file:./db.sqlite\"
SQLite database db.sqlite created at file:./db.sqlite
Your database is now in sync with your Prisma schema. Done in 81ms
这会将数据库与 prisma 的 schema 同步，说人话就是将数据库的表与 schema.prisma 文件中的 model 对应。
generator client {
provider = \"prisma-client-js\"
}
datasource db {
provider = \"sqlite\"
url = env(\"DATABASE_URL\")
}
model Example {
id String @id @default(cuid())
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
// Necessary for Next auth
model Account {
id String @id @default(cuid())
userId String
type String
provider String
providerAccountId String
refresh_token String? // @db.Text
access_token String? // @db.Text
expires_at Int?
token_type String?
scope String?
id_token String? // @db.Text
session_state String?
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
@@unique([provider, providerAccountId])
}
model Session {
id String @id @default(cuid())
sessionToken String @unique
userId String
expires DateTime
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
}
model User {
id String @id @default(cuid())
name String?
email String? @unique
emailVerified DateTime?
image String?
accounts Account[]
sessions Session[]
}
model VerificationToken {
identifier String
token String @unique
expires DateTime
@@unique([identifier, token])
}
create-t3-app 默认使用的 sqlite 数据库，优点就是你无需安装任何数据库的环境，将会在 prisma 目录下创建 db.sqlite 文件来存放数据。但是缺点很明显，性能与部署方面是远不如主流服务级别的数据库。尤其是部署，这在后面会说。
将会创建 Account Example Session User Verification Token 表，这里需要教你一个命令
npx prisma studio
此时访问 localhost:5555 将会得到一个 prisma 面板，即项目的所有 model 。
\n![\"\"](\"https://img.kuizuo.me/QBXnHdoewh.png\")
关于 prisma 更多命令请参考 Prisma CLI Command Reference
\nprisma 在线体验：Prisma Playground | Learn the Prisma ORM in your browser
\n由于 create-t3-app 已经封装好了数据库的操作，并且导出 prisma 对象，所以你只需要配置好环境变量便可。
\n主要代码如下
\nimport { PrismaClient } from '@prisma/client'
export const prisma = new PrismaClient()
在上面所定义的 model，都会被 prisma client 创建对应的 typescript 类型（在node_modules/.prisma/index.d.ts），你就可以直接通过 prisma.modelName 来操作 model，例如 Example（这里就不做注释了）
import { prisma } from '~/server/db'
prisma.post.findUnique({ where: { id: 1 } })
prisma.post.create({ data: {} })
prisma.post.update(id, { data: {} })
prisma.post.delete(id)
prisma.post.count()
我之前如果做数据库备份的话，我通常会在数据库管理软件（Navicat）将整个数据库转储为 SQL 文件，然后要用的时候在运行该 SQL 文件。而这样做呢虽然方便，但是数据都比较死，而且版本多了 sql 文件也多，导入繁琐。
\n此时就可以使用 Migrate，通过命令的方式自动为我们生成当前版本下的 sql 文件，而需要用到的也通过命令的形式运行 sql 文件。
\n你可以编写一个 seed 脚本，用于插种（生成）自定义数据。
\nprisma 不是本文重点，篇幅略少，但是作为 Typeorm 的长期使用者而言，我认为 prisma 会比 typeorm 友善一些，至少从文档上来说 prisma 大胜一筹，而且很多 node 的 web 框架都优先 prisma 作为 orm 框架（除了 nest.js），但不过这两个仓库的 issues 数量有点惨不忍睹。。。
\n我想先简单介绍一下 next-auth（背后由Auth.js 提供）。
\n从名字来看也不难猜出，这是一个 next.js 的 auth 库。该库提供了多种身份验证策略，如基于密码的身份验证，OAuth 等等。并且你只需要简单的几行代码，提供好相关信息便可启用身份验证和授权功能。
\n你可以到这个网站 NextAuth.js Example体验一番。下面是一些代码演示
\n由于 create-t3-app 默认是 Discord OAuth，因此我这边替换成使用者更多的 Github。（至于如何创建 Github OAuth Apps，在我之前的文章以及外面诸多文章中都有介绍到，这里不在演示了，附上配置图）
\n![\"\"](\"https://img.kuizuo.me/_B1RYeiFze.png\")
首先在
\nserver/auth.ts 中 导入
\nimport CredentialsProvider from 'next-auth/providers/credentials'
import GithubProvider from 'next-auth/providers/github'
并在 options 中设置好 providers，如下
\nexport const authOptions: NextAuthOptions = {
callbacks: {
session({ session, user }) {
if (session.user) {
session.user.id = user.id
// session.user.role = user.role; <-- put other properties on the session here
}
return session
},
},
adapter: PrismaAdapter(prisma),
providers: [
CredentialsProvider({
name: 'Credentials',
credentials: {
username: { label: 'Username', type: 'text', placeholder: 'kuizuo' },
password: { label: 'Password', type: 'password' },
},
async authorize(credentials, req) {
// Add logic here to look up the user from the credentials supplied
const user = { id: '1', name: 'kuizuo', email: 'hi@kuizuo.me' }
if (user) {
return user
} else {
return null
}
},
}),
GithubProvider({
clientId: env.GITHUB_CLIENT_ID,
clientSecret: env.GITHUB_CLIENT_SECRET,
}),
],
}
不过此时会提示 env 对象没有 GITHUB_CLIENT_ID 属性，需要在 env.mjs 定义好 GITHUB_CLIENT_ID 与 GITHUB_CLIENT_SECRET。类型安全嘛，你可不想 GITHUB 不小心输成 GAYHUB 导致找不到这个值把。
当上述在设置完毕后，点击 Sign in 按钮便可跳转到 next-auth 所提供的简单登录表单。
\n![\"\"](\"https://img.kuizuo.me/9eowvvnwU2.png\")
如果你想自定义修改登录页面，可以参考该视频Create your own next-auth Login Pages - YouTube
\n通常来说 tRPC 会配合全栈框架使用，因此可以非常轻松的部署在 Vercel，Netlify 上。如今 Vercel 应该也已经家喻户晓了，因此这里就不演示如何部署，可到 Vercel • Create T3 App 中查看相关步骤。
\n至于说自行部署的话，create t3 app 提供了 docker 相关镜像，你可以直接使用 docker 部署，具体步骤可参考 Docker • Create T3 App。
\n这里我提供了一个简单的示例，你可以 点我 访问体验一下（项目部署在 Vercel，而数据库服务在腾讯云，登录服务又依赖 Github，所以项目会稍微有那么慢）。整个项目结构大致如下
\n![\"\"](\"https://img.kuizuo.me/z_YaR-RnSu.png\")
你可以在 Example Apps | tRPC 查看 trpc 的示例应用。
\n如果你是用 Next，Nuxt 等这样的全栈框架，并且你的后端服务使用 Typescript 编写，不妨试试 trpc，你会惊喜地发现，它颠覆了传统的 API 交互，使你的 typescript 全栈应用程序的开发变得更加高效和流畅。
\n从 JavaScript 到 TypeScript 的演变，全栈应用的端到端类型安全，TypeScript 目前正在逐渐成为前端开发中不可或缺的一部分，也许未来的某一天当人们说起前端三件套时，不再是 HTML，CSS，JavaScript，而是 HTML，CSS，TypeScript。
\n再说到我为何会去尝试 tRPC，有很大的原因是因为厌倦了传统后端开发，厌倦了 nest.js 开发。然而现实生活中，你所厌倦的，往往是能为你提供收入的。人们总是做着自己不愿做的事，但生活所迫，谁又愿意呢。
", "url": "https://kuizuo.me/blog/typescript-full-stack-technology-trpc", "title": "Typescript 全栈最值得学习的技术栈 TRPC", "summary": "本文介绍了 tRPC 技术以及它与传统 RESTful API 的区别。同时 tRPC 可以帮助人们更快地开发全栈 TypeScript 应用程序，同时无需传统的 API 层，并保证应用程序在快速迭代时的稳定性。", "date_modified": "2023-03-07T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "trpc", "next", "prisma", "zod", "auth.js" ] }, { "id": "https://kuizuo.me/blog/use-supabase-as-backend-service", "content_html": "对于想快速实现一个产品而言，如果使用传统开发，又要兼顾前端开发，同时又要花费时间构建后端服务。然而有这么一个平台（Baas Backend as a service）后端即服务，能够让开发人员可以专注于前端开发，而无需花费大量时间和精力来构建和维护后端基础设施。
\n对于只会前端的人来说，这是一个非常好的选择。后端即服务的平台使得开发人员能够快速构建应用程序，更快地将其推向市场。当然了，你可以将你的后端应用接入 Baas，这样你就无需配置数据库，编写复杂的身份效验。
\n如果你想了解 Baas，我想这篇文章或许对你有所帮助。
\n在摘要部分也介绍到名词 BaaS (Backend as a Service) ，意思为后端即服务。这个概念是在我接触 Serverless 的时候了解到的，更准确来说是腾讯云开发。当时在编写小程序的时候，只需要专注与应用业务逻辑，而不用编写数据存储，身份验证，文件存储等后端服务，这些统统由 BaaS 平台所提供。 通常会配合 Serverless 函数使用，通常也叫 FaaS（Function as a Service）。通常来说，FaaS 会依赖于 BaaS 平台。
\n而 Supabase 便是 BaaS 的平台之一。Supabase 是一个开源的 Firebase 替代品。使用 Postgres 数据库、身份验证、即时 API、边缘函数、实时订阅和存储启动项目。
\n你也许听过 Firebase，由 Google 提供的私有云服务，但开发者无法修改和扩展其底层代码。而 Supabase 是开源的，提供了类似 Firebase 的功能，且定价灵活，并且官方自称为 Firebase的替代品。
\nBaaS 通常只专注于应用的后端服务，而 CMS 则是专注与内容管理。不过 BaaS 比较依赖云服务，而 CMS 通常只依赖于 web 后端技术。如果你想搭建一个内容站点（视频，音频，文章），并且作为网站管理员，那么 CMS 就是一个很好的选择，并且有相当多的主题模板。反之，不想搭建后端服务，减少运营程序，那么毫不犹豫的选择 BaaS。
\n进入 supabase 登录界面 选择 Continue With Github
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_2yiQ9NHv21.png\")
输入 Github 账号密码进入主页面，新建一个项目
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_0eoOyP8DM2.png\")
为该项目起名，设置数据库密码，以及分配地区。
\n创建 supabase 项目对密码要求非常严格，像 a123456 这种根本无法通过，像 ●●●●●●●●●● 密码就可以。
地区方面优先就近原则，而最近的也就是日本与韩国，很无奈 supabase 在大陆和港澳台并未设立服务器。
![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_N5CQnx8cnU.png\")
等待片刻，你将拥有一个免费的后端服务！
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Z33n9aUOC7.png\")
supabase 会提供一个二级域名供开发者访问，也就是这里 Project Configuration 的 URL，对应的这个二级域名 azlbliyjwcxxxxx 也就是你这个项目的唯一标识 Reference ID（下文称 项目 id）。你可以到 https://app.supabase.com/project/你的项目 id/settings/api 中查看相关配置。
\n这里参考到了官方文档 Serverless APIs。
\n首先，创建一个 todos 表，并新增字段（列）task 为 varchar 类型，Save 保存。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Do9LHoUsYo.png\")
Insert row 添加一行记录，id 为 1，task 为 code。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_R9PEyH-spd.png\")
![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MLm6_i1Pb-.png\")
现在有了数据后，正常来说我们应该做什么？请求一下数据看看？不不不，应该是设置数据的权限。
\n打开到下图界面，我们要为 todos 数据新增一个 policy 策略。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MEKk1-qQFl.png\")
![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_W-C-pGNh1o.png\")
supabase 针对不同的场景提供了相应的策略方案模板，你也可以根据你的需求进行设置，这里作为演示不考虑太复杂，选择第一个允许任何人都可以请求到 todos 数据。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Oa_424N4gz.png\")
接着下一步即可
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_wV_MqXQXcK.png\")
此时就新增了一个所有用户都可查询的 todo 的策略，同样的你还可以添加只有授权用户才能够创建更新删除 todo，更新与删除只能操作属于自己的 todo 资源。
\n这时候设置好了数据的权限后，就可以尝试去请求了，打开下图页面，将 URL 与 apikey 复制下来。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_GDEeyFCI2E.png\")
选择你一个 http 请求工具，这里我选用 hoppscotch，将信息填写上去，请求将会得到一开始所创建的 todo 数据。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_aSbRfmlwb9.png\")
除了 restful api 风格，还支持 graphql 风格，可查阅文档 Using the API
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_R0HtkYmznS.png\")
正常情况肯定不会像上面那样去使用，而是通过代码的方式进行登录，CRUD。这里使用 Javascript Client Library，替我们封装好了 supabase 的功能。
\n首先，安装依赖
\n![\"\"](\"https://img.kuizuo.me/7_XKmbuK87.png\")
npm install @supabase/supabase-js
创建 客户端实例
\nimport { createClient } from '@supabase/supabase-js'
此时准备好上述的 URL 与 apikey，用于创建 supabase 实例，不过 supabase 还提供 type 类型支持，可以将生成的 database.types.ts 导入到实例中，如
import { createClient } from '@supabase/supabase-js'
import { Database } from 'lib/database.types'
const supabase = createClient<Database>(process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY)
此时有了 supabse 对象后，就能够请求数据了，像上述通过 http 的方式获取 todos 数据，在这里对应的代码为
\nconst { data, error } = await supabase.from('todos').select()
官方的演示例子 非常清晰，这里就不在演示新增更新等示例。
\n![\"image-20230218182910913\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image-20230218182910913.png\")
supabase 基于 PostgreSQL 数据库，因此当你创建完项目后，就自动为你分配好了一个可访问的 PostgreSQL 数据库，你完全可以将其当做一个远程的 PostgreSQL 数据主机。
\n可以在如下页面中查看到有关数据库连接的信息，当然你看不到密码。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_6uCHh3qrlE.png\")
测试连接，结果如下，并无问题
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_8-JOTiLI0G.png\")
supabase 令我感兴趣的是 Row Level Security，supabase 使用 Postgres 的 Row-Level-Security（行级安全）策略，可以限制不同用户对同一张表的不同数据行的访问权限。这种安全机制可以确保只有授权用户才能访问其所需要的数据行，保护敏感数据免受未授权的访问和操作。
\n在传统的访问控制模型中，用户通常只有对整个表的访问权限，无法限制他们对表中特定数据行的访问。而行级安全技术则通过将访问权限授予到特定的数据行，从而让不同的用户只能访问他们被授权的行。这种行级安全有一个很经典应用场景-多租户系统：允许不同的客户在同一张表中存储数据，但每个客户只能访问其自己的数据行。
\n这对于传统后端开发而言，如果不借用一些安全框架，实现起来十分棘手，要么业务代码与安全代码逻辑混杂不堪。
\n权限细分方面，无需担心，supabase 已经为你做好了准备，就等你来进行开发。
\n对于想要提供第三方登录，supabse 集成多数平台（除了国内），只需要提供 Clinet ID, Client Secret, Redirect URL 便可完成第三方登录。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_OvBRJ_elZR.png\")
这里演示下如何使用 Github，首先到打开New OAuth Application (github.com) 创建一个 Oauth Apps，其中 Authorization callback URL 由 supabase 提供，如下图。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_QVspy-oxQK.png\")
![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_jyaUMSDed2.png\")
当你创建完后，会提供 Client ID，与 Client secret，将这两个值填写到 supabase 中，并启用。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_QpRRxpR5o5.png\")
此时打开如下页面，将 Site URL 替换成开发环境，或是线上环境，在 Github 登录后将会跳转到这个地址上
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_zmfXC85ayC.png\")
此时 supabase 支持 github 登录就已经配置完毕，当你在前端触发登录按钮后，借助supabase 的 js 库，如
\nconst { data, error } = await supabase.auth.signInWithOAuth({
provider: 'github',
})
便可完成 Github 第三方登录。
\n接触过对象存储的开发者对 Bucket 应该不陌生，相当于给你一个云盘，这里演示如何使用。
\n打开如下界面，这里选择公开存储桶，比如说用于图床。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_2Is4Bfwf8f.png\")
点击右上角的 upload files，选择你要上传的图片。你可以为此生成一个访问 URL
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_vkuzeZZVJ_.png\")
你可以访问 1.png 来查看这张图片。如果是公开的话 一般都是类似https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/new-bucket/1.png
\n而私有的为 https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/sign/new-bucket/1.png?token=eyJhbGciOiJIUzI1NiIsInR5cCIxxxxxxxxxxxxxxxxx 路径稍微变化了下，还有就是多了个 token，如果不携带 token 则访问不了图片。
\n你可以到Supabase Storage API 查看 storage 相关 api。
\n本文中的所有图片数据都来源于 supabase bucket。
边缘函数可以分布在全球的接近您的用户各个地方，类似与 CDN，但 CDN 主要服务于静态资源，而 Edge Functions 可以将你的后端应用接口，像 CDN 那样部署到全球各地。
\n有兴趣可自行了解。
\n如果只单纯看看 supabase 文档，不去动手实践接入一下，总觉得还是差点意思。于是我准备使用 Nuxt 作为前端框架接入 supabase，官方模块 Nuxt Supabase 去编写一个应用。
\n原本我是打算写个 Todo List 的（恼，怎么又是 Todo List），但是看到 官方示例（一堆 Todo List）后我瞬间就没了兴致 🥀。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_1polvJf0q0.png\")
思来想去，不妨就简单做个图床吧。项目地址：https://image.kuizuo.me 有兴趣可自行阅读源码。（写的相对匆忙，仅作为演示，随时有可能删除，请勿将此站作为永久图床！）
\n可以到 https://app.supabase.com/project/项目id/settings/billing/usage 中查看相关资源使用情况，这里我就将截图放出来了。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_Bllhp6XlFz.png\")
说实话，对于个人独立开发者的项目都绰绰有余了。
\n在 资费标准 中可以看到，免费版最多 2 个项目，不过在上述的资源，其实已经非常香了，毕竟只需要一个 GIthub 账号就能免费使用，还要啥自行车。
\n![\"\"](\"https://azlbliyjwcemojkwazto.supabase.co/storage/v1/object/public/public/image_MNtdzsdJ2t.png\")
国内因为没有 supabase 的服务器节点，然后且有防火墙的存在，所以请求速度偏慢。不过体验下来至少不用梯子，速度慢点但也还在可接受范围。
\n用过 vercel 的你应该会想是不是也能自定义域名呢? 当然，不过这是 supabase pro 版才支持，一个月$25(美刀)，算了算了，再一眼 azlbliyjwcxxxxx.supabase.co就会爆炸感觉也蛮好记的。
说句实话，真心感觉 supabase 不错，尤其是对个人/独立开发者而言，没必要自行去购买服务器，去搭建后端服务，很多时候我们只想专注于应用程序的开发和功能实现，而不是花费大量时间和精力在服务器和后端服务的部署和管理上。
", "url": "https://kuizuo.me/blog/use-supabase-as-backend-service", "title": "将 Supabase 作为下一个后端服务", "summary": "本文介绍了如何使用 Supabase 作为后端服务，使开发人员可以更快地构建和部署应用程序，无需配置数据库或编写复杂的身份验证代码。将使用 Nuxt.js 和 Supabase，以实现一个图床网站为例，来演示如何在前端中使用 Supabase API 和 Storage 服务。", "date_modified": "2023-02-18T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "supabase", "nuxt", "project" ] }, { "id": "https://kuizuo.me/blog/use-fresh-build-web-applicatioin", "content_html": "这篇文章将使用 deno 的 web 框架 Fresh，一个简单的 Web 应用 Link Maker，一个用于将链接转换成卡片样式的预览效果。
\n这个项目也放在了 fresh 的 Showcase，感兴趣的可以查看一番。
\nfresh 自称是下一代 web 开发框架（这句话怎么这么熟悉?），是一个基于 Deno 的 Web 框架。它提供了许多用于构建 Web 应用程序和 API 的工具和功能。Fresh 框架特别强调简单性和灵活性，并着重于提供最佳的性能和开发体验。它支持 TypeScript，并且不需要任何配置或构建步骤。这些特性使得 Fresh 框架成为构建高效和现代 Web 应用程序的理想选择。
\ndeno 提供了非常友好的创建 fresh 项目的命令，运行:
\ndeno run -A -r https://fresh.deno.dev my-project
cd my-project
deno task start
根据你的喜好进行配置，如下
\n![\"\"](\"https://img.kuizuo.me/jSRfPu966v.png\")
此时会创建如下文件
\nmy-project
├── components # 组件
│ └── Button.tsx # 按钮组件
├── deno.json # deno配置文件
├── dev.ts #
├── fresh.gen.ts #
├── import_map.json # 依赖导入映射
├── islands # 群岛(组件群岛)
│ └── Counter.tsx
├── main.ts # 入口文件
├── routes # 路由
│ ├── [name].tsx
│ ├── api
│ │ └── joke.ts
│ └── index.tsx
├── static # 静态资源
│ ├── favicon.ico
│ └── logo.svg
└── twind.config.ts # twind配置文件
介绍几个文件：
\ndev.ts: 项目开发模式的匹配文件，假设你需要区分生产环境和开发环境，就可以通过 dev.ts，prod.ts 命令来指明入口main.ts: 入口文件，会用于链接 Deno Deploy。fresh.gen.ts: 这个清单文件会基于routes/ 和 islands/ 文件夹自动生成。包含项目的 route 和 island 信息。import_map.json: 这是用于管理项目的依赖项的导入映射。这允许轻松地导入和更新依赖项。其中最主要的两个目录，这里会细说。
\nroutes/: 存放项目中的所有路由。文件即路由，每个文件的名称对应于访问该页的路径。注：此文件夹中的代码永远不会直接发送到客户端.
其中 routes/api 通常存放一些 api 接口，这这里你完全可以将其当做一个 deno 的服务端，可以做后端能做的事情，通常来说就是提供一个可请求的 api 接口。
\n而其他文件就相当于一个可访问的页面组件，同样是文件路由系统，也可以在这里进行 SSR、中间件操作。
\nIslands/: 群岛，Fresh 中我并未看到对这一词的解释，你可以到 astro 群岛 看看新的 Web 架构模式，主要作用就是用于存放交互式组件（服务端组件），可以在客户端和服务端运行。有点类似与 next.js 的服务端组件，同样有两种状态（服务端，浏览器端）。
这一部分会有点难理解，你只要知道 IsLands 存放的组件有两种状态（服务端，浏览器端），下文称服务端组件，不同于 components 下的组件，服务端组件有一些优势，例如说
\n想要真正理解服务端组件，就不得不将其与 SSR 拿来对比了。
\nSSR 通常是将数据通过服务端的前端框架渲染成 HTML，直接将 HTML 返回给客户端就可以省去 xhr/fetch 请求的过程，只需要首次请求就能得到数据。此时页面交互，数据更新与传统的前端应用没有任何区别，通俗点说 SSR 就是省去 xhr/fetch 请求的过程。
\n而服务端组件会在服务端完成渲染，然后通过自定义的协议发送到客户端。前端应用会将新的 UI 整体（服务端组件）的合并到客户端 UI 树里面（也有叫 hydration 水合），此过程不会对客户端其他状态产生影响，还能达到保持客户端状态的目的，极大的增强了用户体验。
\n如果你仔细查看控制面板的网络请求输出，可以看到服务器端组件是可以请求的。（这里用的后面实战的截图作为展示）
\n![\"\"](\"https://img.kuizuo.me/v73eXB47yI.png\")
不过既然服务端组件也有很多限制，就比如说服务端状态下，是无法使用 Web 相关 Api 的，数据传输（通过 props）是有前提的，要 JSON 可序列化，也就是说只能传递基本类型、基本对象、数组，像 Date，自定义类，函数等复制对象是无法传递的。
\n项目还是相对比较简单的，将链接转化为一个卡片样式的预览效果（包含链接的标题，图片，描述）。
\n核心代码在 routes\\api\\link.ts 下，将会生成 /api/link 接口，例如访问 https://link-maker.deno.dev/api/link?q=https://kuizuo.me 你就可以得到如下 json 数据
{
\"title\": \"愧怍的小站\",
\"description\": \"Blog\",
\"image\": \"https://kuizuo.me/img/logo.png\",
\"url\": \"https://kuizuo.me\"
}
原理就是通过 fetch 请求目标 url，通常来说得到的是一个 html 页面，这时使用 deno-dom 解析成 Dom 对象，通过 css 选择器选取所要的数据，并整合返回给调用方。
\n有了这个接口，剩下的前端工作就相对比较轻松了，主要也就是细节话的问题。
\n下面我会说说,在我编写该应用的时候，有哪些开发体验上的不足之处，如果你恰好有使用 Fresh 框架编写 Web 应用的话，最好需要注意下。
\n当我移动项目 .ts/.tsx 文件的时候，vscode 会将该文件与其他引用该文件的路径更改为 .js/.jsx，这就比较蛋疼了，所以每当要移动文件的时候都要尤为小心。
\n还有就是文件的依赖关系不是那么准确，尤其是在首次进入项目工程的时候，比如说在 routes/test.tsx 中 导入了 components/Button.tsx 组件，当你在 tsx 中写了<Button></Button> ，vscode 并不会有任何的引入提示，当你打开 components/Button.tsx 文件后就又有了，搞得我都怀疑是不是没有该组件。
fresh 的 handler 提供两个参数，一般来都会写成下面这种形式，可以区分 Get，Post 请求
\nexport const handler = {
async GET(req: Request, ctx: HandlerContext): Promise<Response> {},
async POST(req: Request, ctx: HandlerContext): Promise<Response> {},
}
假设当前的请求是 /api/test?q=123，我想要获取 query 参数的 q，我得这么做
\nconst url = new URL(req.url)
const q = url.searchParams.get('q')
当时我尝试用 ctx.query 和 req.query 来获取 q 参数，然而 ctx 与 req 并没有 query 属性，在翻阅文档与源码，才得知 fresh 并没有将 query 参数解析到 req 或 ctx 下。
\n至于说为何要用 query 而不是用 param，主要是因为 url 的缘故，比如说 /api/link/https://kuizuo.me 这个链接，这时 param 是解析不出 https://kuizuo.me 完整 url 的，除非 url 编码，但这对使用者来说就不是很好，于是就舍弃了 param 参数的方案。
在这个应用中我所使用到了 html2canvas 库用于将页面的 div 元素转成 canvas，以便转成图片的形式并下载。然后在我导入的时候，要么提示找不到该包（大概率是因为 Commonjs），要么就是 html2canvas 不存在，最终无奈我只好将 html2canvas.min.js 存放在 static 下，并在页面中通过 <script src=\"/js/html2canvas.min.js\"></script> 方式导入，这样全局有了 html2canvas 就可使用。
我在 islands 下的组件中用到了 localStorage 用于持久化数据，然而在我尝试部署到服务器上的时候发现网站无法访问，并在错误日志中提示 localStorage is not defined。
\n其实这在很多 hydration 框架中都有这一个问题，在 islands 下的组件有两种状态（浏览器端，服务端），后文就称为客户端组件和服务端组件。也正是如此，服务端组件是没有客户端的运行时环境，就比如说你想要在组件中使用 localStorage 对象用来持久化数据，在两种状态下，首先会在服务端执行一遍，然而服务端并没有 localStorage 对象，此时就会提示 localStorage is not defined。
\n通常的做法是判断组件当前的状态，可以用如下方式来判断是否为浏览器环境。
\nimport { IS_BROWSER } from '$fresh/runtime.ts'
然后将 localStorage 等 Web 相关 API 的调用放在 IS_BROWSER 的判断中。
\n有篇相关文件非常值得阅读，或许对组件的 hydration 有更好的理解
\n💧 Hydration and Server-side Rendering – somewhat abstract
\n在前面也说过，Fresh 的前端渲染层由 Preact 完成。如果用户要用 React/Vue 那为何不选择生态更好的 next.js/nuxt.js 呢？所以目前来看，Fresh 还是有些无能为力。但可以肯定的是，fresh 的方向与 next.js/nuxt.js 的一致。
\ndeno Deploy 可以非常轻松的部署 fresh 应用，使用 Github 账号登录后，New Project，从 github 仓库中拉取项目点击 Link 即可部署完毕。
\n![\"\"](\"https://img.kuizuo.me/CYOAgv6IGe.png\")
这里的项目名为 link-maker，那么就会生成 专属访问链接 https://link-maker.deno.dev（也许要梯子才能访问）
\n最后，在我编写完该应用后，我对其做一个评价吧。收回一开始的一句话，fresh 自称是下一代 web 开发框架。
如果要让我在 next.js 和 fresh 两个相似的产品中做个选择的话，我肯定毫不犹豫的选择 next.js。一个以一己之力推动了前端的发展，到至今已有越来越多的项目使用 next.js ，我想作为任何一个前端学习者肯定会毫不犹豫的选择 next.js 去编写 web 应用。
\n就从用户的开发体验而言，就已经很难让我再次选择 fresh，更何况还有像 next.js/nuxt.js 这样的全栈框架。作为一个开发体验（Developer experience）优先的程序员角度来看，如果一个框架想要让别人广泛使用，一定要满足其开发过程，只有沉浸于此，才能不断思考，编写出高质量代码。即便无负担的配置，高性能编译，轻便的部署，这些在他人看来可选择的点（也是 fresh 的点），在我看来却显得很微不足道。
\n而为什么我会选择尝试 fresh，其实也就想看看能不能找到一个令我眼前一亮的一个全栈 Web 框架，然而目前来看，fresh 还有很长一段距离。
", "url": "https://kuizuo.me/blog/use-fresh-build-web-applicatioin", "title": "🍋 使用 Fresh 框架构建Web 应用", "summary": "使用 Fresh 框架构建Web 应用，用于将链接转换为卡片样式的预览效果图。", "date_modified": "2023-02-15T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "deno", "fresh", "web", "project" ] }, { "id": "https://kuizuo.me/blog/deno-is-not-only-a-javascript-runtime", "content_html": "Deno 是一个安全的 JavaScript 和 TypeScript 运行时，作者是 Ryan Dahl（也是 Node.js 的原作者）。Deno 的诞生之初是为了解决 2009 年首次设计 Node.js 时的一些疏忽。我认为这种改造动机很有道理，因为我相信每个程序员都希望有机会能重写他们已有 10 年历史的代码。
\ndeno 刚出的时候就听闻了，传言 deno 是下一代 node.js。不过如今看来，还革不了 node.js 的命。如果要说两者字面上的区别，Deno 的来源是 Node 的字母重新组合（Node = no + de），表示\"拆除 Node.js\"（de = destroy, no = Node.js）。
\n趁着假期学了一段时间的 deno（指文档刷了一遍），想分享本人作为 node 开发者在学习 deno 时认为的一些亮点，以及个人对 deno 与 node 见解。
\n默认情况下 deno 会根据不同的系统，选择相应的安装目录，以及依赖目录，你可以配置环境变量来改变 deno 的默认行为。
\n这里我选用 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 代码。
\n因为 deno 与 node 一样，都是 javascript 运行时（deno 合理来说是 typescript 运行时）。所以在 javascript 的部分就没什么好说的了，主要对比 deno 相比与 node 的优势，或说我个人觉得一些使用亮点。
\n以下是官方所介绍的亮点，我对其做了翻译
\n提供web 平台功能，采用网络平台标准。例如，使用 ES 模块、Web worker 和支持 fetch()。
默认安全。除非显式启用，否则无法访问文件、网络或环境。
\n支持开箱即用的 TypeScript。
\n提供单个可执行文件 （deno）。
为编辑器提供内置的开发工具，如代码格式化程序 （deno fmt）、linter （deno lint）、测试运行程序（deno test）和语言服务器。
\n拥有一组经过审查（审核）的标准模块，保证与 Deno 一起使用。
\n支持使用现有的 npm 模块
\n以下会针对部分亮点，进行个人的见解。
\ndeno 则是自带代码格式化（deno fmt）、代码风格（deno lint）、代码测试（deno test）、依赖检查器（deno info）等等的功能。而这些在 node 中，你需要通过第三方的库，如 eslint，jest 才能实现。
你可以在项目工程中添加配置文件 deno.json来定制化代码风格（rust 中也有类似的功能），但在 node 中必须要借助第三方的库，或是 IDE 才能实现。
\n不过也能理解，在当时的编程环境背景下，javascript 还主要作为前端的脚本语言使用，又怎能让 node 来做相关规范呢？（这句话可能有点不妥）
\n这点我认为对开发者是否选用你这门语言的一个加分项，并且这些功能也应该作为编程语言所自带的，有官方的背书（保证），对代码风格才更有所保障。
\n这里有份 官方小抄 可以知道通过deno xxx等命令能够做到 node 原本需要通过第三方库才能实现的功能。
| Node.js | Deno |
|---|---|
node file.js | deno run file.js |
ts-node file.ts | deno run file.ts |
npm i -g | deno install |
npm i / npm install | n/a |
npm run | deno task |
eslint | deno lint |
prettier | deno fmt |
rollup / webpack / etc | deno bundle |
package.json | deno.json / deno.jsonc / import_map.json |
tsc | deno check |
typedoc | deno doc |
jest / ava / mocha / tap / etc | deno test |
nodemon | deno run/lint/test --watch |
nexe / pkg | deno compile |
npm explain | deno info |
nvm / n / fnm | deno upgrade |
tsserver | deno lsp |
nyc / c8 / istanbul | deno coverage |
benchmarks | deno bench |
与 node 不同，使用 node 通常需要从 npm 官方包来下载并导，有 npm 这样的包管理器来统一管理这些包（package），我们通常称这种为中心化，而 deno 与 go 的做法很像，你可以将你的封装好的代码定义成一个包，并将其放在任何网络可访问的地方，比如 github，或是私有地址，然后通过网络读取文件的方式来导入，这种称为去中心化。
\n关于中心化与去中心化管理，各有优缺，这里不做细致讨论。
\n以下是 deno 官方远程导入的代码示例：
\nimport { 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（cdn）远程导入模块，那远程运行文件自然也不成大问题。有时候像快捷体验一下别人的代码，或是想要在浏览器中运行一下代码，这时候就可以通过 http 的方式来运行代码。
\n这里我准备了一段代码，并部署到我的站点上，你可以通过如下命令得到该代码的执行结果（如果你有安装 deno 的话），放心这段代码并无危害，就是一段简单的 console.log 输出。
\ndeno run https://deno.kuizuo.me/main.ts
在第一次使用时下载并缓存代码，你可以通过
\ndeno info http://deno.kuizuo.me/main.ts
来查看文件信息，如下
\n![\"\"](\"https://img.kuizuo.me/deb0_lGYRA.png\")
deno info 还可以查看 deno 的相关配置，默认缓存都设置在 C 盘，你也可以设置DENO_DIR 环境变量来更改 deno 目录，可以到 Set Up Your Environment 查看 deno 相关环境变量。
\n经常使用 node 的开发者应该对 node 的依赖感到无比厌烦，关于这部分强烈建议看 node_modules 困境，你就能知道 node 的 node_modules 设计的是有多少问题。看完你也就能知道为啥越来越多的 node 项目都使用 pnpm 作为包管理。
\n虽然 node 有了 pnpm 包管理器这种情况会好一些，但本质在项目目录还是需要 node_modules 文件。也许你用过其他语言的包管理器，你会发现基本都是将所有用到的依赖全局缓存起来，当不同的项目工程需要用到依赖时，直接去全局缓存中找，而不是像 npm 一样，下载到项目工程目录下，存放在 node_modules 里。
\n而 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 软件包，并且还非常友好。
\n不过如果你在 deno 中使用了 npm 包，可能会存在一些兼容性问题，万一遇到了，也可以通过添加 --node-modules-dir 标识，在当前运行目录下创建 node_modules 文件夹。详见 --node-modules-dir flag
在 2022 年 npm 出现过一些恶性的库，如 lodash-utils, faker.js, chalk-next。万一你不小心安装了上面，轻则项目无法运行，输出无意义乱码，重则删除本地文件。
\n又因为 npm 几乎没有代码审计的机制，任何开发者只需要有一个 npm 的账号就能在上面随意发布他想发布的包。通常来说电脑病毒都是通过随意读取与写入本地文件来达到病毒的目的，但在 deno 中，代码如果尝试写入与读入文件，都需要询问开发者是否允许操作。并且在 linux 系统，你可以指定像 /usr /etc 这样非 root 角色来操作该文件，避免真是病毒文件导致删除不该删除的文件。
\n此外像命令执行，网络访问，环境变量这些极易危害电脑的权限，deno 都会检测到，并做出提示告诫开发者是否允许执行。总之你能想到的电脑安全隐患，deno 都为你做好了。
\n这是我认为 deno 最大的亮点。
\n总所周知，浏览器的 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。
\n虽说与真实浏览器全局对象有些许差异，但这也足够让开发者少做很多工作。比如 Web 逆向者通常要扣取浏览器的 js 代码，并补齐环境使其能够在 node 中运行，而有了 deno 这将变得非常轻松！
\n与其说是 javascript/typescript 运行时，我更愿意说是浏览器运行时！
\n你可以在 Web Frameworks 中看到 deno 官方所推荐的 Web 框架，其中 Fresh 也是最为推荐使用的（后续我也会尝试使用该框架）。
\n而在 node 社区中，你会看到像 express，koa，nestjs 等等这种非 Node 官方或大背景的 web 框架（而且还很多），而这时对于初学者而言，就有点不知道该如何做出抉择。
\n而像 java 中你完全可以不用担心该学什么，说学 spring 就是在学 java 这可一点都不为过。可能这也是国内 java，尤其是 spring 的开发者尤为诸多的原因。
\n吐槽归吐槽，但我想表明的是在有官方的支持下，用户和开发者能够统一使用某个框架，一起维护与使用一个更好的框架。而不是个个 Web 框架的都有各自的优缺点，让使用者去选择，搞得这个框架是另一个框架的轮子一般。
\n所以我认为这种支持是很有必要。
\ndeno 像 vercel/netfily 一样提供了一个代码托管服务，可以将你的 deno 应用部署上去。对，目前来看还无法部署前端应用，因为要指明一个入门文件（main.ts）。
\n你可以通过 https://kuizuo.deno.dev/ 来访问我使用 deno Deploy 所创建的一个在线项目。将会输出一个Hello World! 的页面。
提供一个免费的线上环境体验，对开发者而言尤为重要，尤其是在将自己的项目成果分享给他人展示时，成就感油然而生。
\ndeno 相关的亮点我也差不多介绍完了，也许你对 deno 已经有一丝兴趣想尝试一番，以下我整理的对你也许有所帮助。
\n如果你是一个 Node 用户，考虑切换到 Deno，这里有一个官方小抄来帮助你。
\n如果你不想刷 deno 文档，想快速上手 deno 的话，这里我建议推荐看看 deno 官方所推荐的deno 代码例子 ，能够非常快速有效了直接了解 deno 标准库以及依赖导入导出。
\ndeno 是集成了 node 与 npm 的，也就是说允许直接使用 npm 包与 node 标准库，如果你想用 deno 来写 node，也行，详看Interoperating with Node.js and npm。
\n想要在 deno 中连接数据库，可看Connecting to Databases。
\n如果想看 deno 如何使用 deno 生态的 Web 框架创建一个 Web 服务，推荐fresh框架，并查看该例子fresh/examples/counter
\n关于 deno 就暂且落下笔墨，不妨思考一个问题，node 火吗。
\n作为 node 开发者，我肯定会说 node 火，不过更多是对 javascript 来说火。
\n如今 typescript 大势所趋，说 javascript 就等同于说 typescript，而 javascript 和 node 绑定已成事实，而前端也与 javascript 所绑定，如今的前端工程师要是不会 node，都不好意思说自己是个前端工程师。就现阶段看，没了 nodejs，前端技术得倒退十年（不夸张）。
\n如果是在 Web 前端，Node 确实已经火的一塌糊涂了，然而它的诞生并不是为了 Web 前端，而是希望将 javascript 作为服务器端语言发展。只是后来没有想到的是 Node.js 在前端领域却大放异彩，造就了如今大前端的盛世。
\n所以在 Web 后端的领域，Node 确实是不温不火，更多的公司都宁可选主流的后端开发语言，而不是优先考虑 Node。不过倒是在 Serverless 领域中，Node 有着一席之地。
\n所以我想 deno 的出现，不仅是针对 Node.js 的缺陷，更是针对 Node.js 后端开发的不足。至于说 deno 能否完成原先 node 的使命，只有时间能给我们答案。
\n从上述看来，你应该会发现 deno 并不和 node 一样是一个纯运行时环境。因为他不仅仅做了 javascript/typescript 运行时环境，还做了很多开发者好评的功能，一个为 javascript/typescript 提供更好的开发支持的产品。
\n但好评并不能直接决定销量，这些功能看似可有可无，没有激起用户从 Node.js 切换过来的杰出之处。就我体验完发现，好像 deno 能做的东西 node 大部分也能做，只是相对繁琐重复一些而已。但人们更倾向于做一件繁琐重复的事情，而不是做一个新的事情。
\n扪心自问，我真的很希望 deno 能火，就开发体验而言，比 node 好用太多了，但好用的东西代表不了用的人就多，这个领域中，生态尤为重要。想要让 node 用户转到 deno 开发还有很长一段路要走。
\n再来反问自己，我现在会将 deno 作为 node 替代品吗，我想我和多数 node 开发者一样，都不会将 deno 作为主力语言(因为有很多项目都已经使用node来进行开发与推动)。但作为个人开发者，尤其是 node 开发者，我认为还是非常有必要去尝试一番 deno，亲手目睹\"下一代Node\"。
\n希望本文能对你了解 deno 有所帮助。
\nDeno vs. Node.js 哪个更好 - 掘金 (juejin.cn)
\n为什么 Deno 没有众望所归？超越 Node.js 还要做些什么？ - 掘金 (juejin.cn)
\n连发明人都抛弃 node.js 了，还有前途吗？ - 知乎 (zhihu.com)
\n已经 2022 年了 Deno 现在怎么样了? - 知乎 (zhihu.com)
", "url": "https://kuizuo.me/blog/deno-is-not-only-a-javascript-runtime", "title": "Deno 不只是个 Javascript 运行时", "summary": "Deno 是一个安全的 JavaScript 和 TypeScript 运行时，作者是 Ryan Dahl（也是 Node.js 的原作者）。Deno 的诞生之初是为了解决 2009 年首次设计 Node.js 时的一些疏忽。我认为这种改造动机很有道理，因为我相信每个程序员都希望有机会能重写他们已有 10 年历史的代码。", "date_modified": "2023-01-20T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "deno", "node", "javascript", "typescript" ] }, { "id": "https://kuizuo.me/blog/rust-wasm-md5", "content_html": "我初识 WebAssembly 是当初想要分析某个网站的加密算法，最终定位到了一个 .wasm 文件，没错，这个就是 WebAssembly 的构建产物，能够直接运行在浏览器中。在我当时看来这门技术很先进，不过如今看来绝大多数的 web 应用貌似都没使用上，迄今为止我也只在这个网站中看到使用 WebAssembly 的（也许有很多，只是没实质分析过）。
恰好最近正在接触 Rust，而 Rust 开发 WebAssembly 也非常方便，因此本文算是我对 Rust + WebAssembly 的初探。
\n有关 WebAssembly 不做过多介绍，你可以到 MDN 中查看相关介绍。本文重点于 Rust + WebAssembly 实践与相关工具，在 Rust and WebAssembly (github.com) 或 https://github.com/rwasm 中查看 rustwasm 相关生态。
\n下载 wasm-pack，用于将 rust 代码打包成 .wasm 文件
\ncargo install wasm-pack
使用 cargo 有可能无法安装 wasm-pack（笔者就安装不了 openssl-sys），可以到 wasm-pack 官网下载对应的二进制文件进行安装。
\ncargo 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 目录下，如下
\n├─pkg
| ├─.gitignore
| ├─hello_wasm.d.ts
| ├─hello_wasm.js
| ├─hello_wasm_bg.js
| ├─hello_wasm_bg.wasm
| └─hello_wasm_bg.wasm.d.ts
如果想当 npm 包发布的话，可以添加 —scope 参数，将会在 pkg 下生成 package.json 文件用于发布或当做一个 npm 包来使用，这样也可以在前端工程中直接当做一个模块来导入使用。
wasm-pack build --scope mynpmusername
借助 wasm-pack 可以非常轻松的将 rust 打包成 wasm，同时还提供了 js 相关支持。直接打包成 js 可导入的 npm 包，而不是让用户导入 wasm 文件然后通过浏览器 WebAssembly 对象来加载 WebAssembly 代码，其他语言的 WebAssembly 开发也是如此。
此外 rustwasm 还提供了对应的模板 rustwasm/wasm-pack-template，可以帮你省去上面的一系列配置操作，专注于你的 wasm 开发。
\n由于上面我们已经将其打包成了一个 npm 包，只需要将配置好 package.json 的依赖即可，本地的话可通过下方格式，将 pkg 目录更改为 hello-wasm，并放置在根目录下。
\n \"dependencies\": {
\"hello-wasm\": \"file:./hello-wasm\"
},
这时候就可以通过 js 直接导入使用
\nconst js = import(\"./hello-wasm/hello_wasm.js\");
js.then(js => {
js.greet(\"WebAssembly\");
});
在 vite 生态中有个 rwasm/vite-plugin-rsw 插件，能够在 vite 中快速使用 wasm-pack。下文中的一个应用示例也将采用该插件进行开发。
\n回到一开始的标题，在实现这个功能我一般会想 js 如何实现 MD5 算法，通常来说 MD5 算法是个比较流行的加密算法，通过搜索引擎能够快速帮我找到一份 js 的 MD5 算法。不过我更习惯通过包管理器导入的加密库，如crypto-js。
\n同理，在 rust 中可以到 crates.io 中也可以找到你想要的库，如 digest，不过我这里主要是实现 MD5 算法便使用的是 md-5。以下是我的封装代码。
\nuse 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);
}
然后将这一部分的代码替换到一开始的示例中。
\nextern 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 函数，至此就已经完成了本标题的内容了。
\n这里我所借用 rwasm/vite-plugin-rsw 插件，在 vite 中配合 wasm-pack 进行开发的一个实例。代码部分就不做解读了，有兴趣可自行到翻阅源码：kuizuo/rust-wasm-md5
\n在线地址：http://rust-wasm-md5.kuizuo.me （不保证地址长期可用）
\n![\"\"](\"https://img.kuizuo.me/_XHPNCbC-B.png\")
众所周知，你在浏览器中按下 F12 打开 DevTools，并选择源代码面板中就可以看到当前访问的网站的所有代码。
\n![\"\"](\"https://img.kuizuo.me/6019y_U19n.png\")
而对于一些具有熟练度的逆向分析者中，如果不经过任何处理的代码被打包到生产环境中能够快速的定位出某个功能的具体代码位置。
\n而通过 wasm 就能很有效的将代码隐藏起来，不让逆向分析者查看，就像下面这样
\n![\"\"](\"https://img.kuizuo.me/BbA3n6wFws.png\")
![\"\"](\"https://img.kuizuo.me/81tgfDE_P7.png\")
这里我并没有将 md5 更改成不易猜测的名字，你也可自行下断点尝试一番，定位代码。当你定位到具体代码后，就会得到上图的二进制代码格式，几乎无法解读其意思。
\n不过虽说解读不出 wasm 的原代码（至少目前来说很难反编译成原始代码），但可以通过扣代码的方式来调用 wasm 对外提供的函数（这里为 md5 函数）。
\n这里仅是 wasm 的一种实际用例，更多情况下应该还是用 Wasm 来提高 web 应用性能的。
\n编译 Rust 为 WebAssembly - WebAssembly | MDN (mozilla.org)
\n\n前端入门 ｜ Rust 和 WebAssembly - Rust 精选
\nrwasm/vite-plugin-rsw: 🦞 wasm-pack plugin for Vite (github.com)
", "url": "https://kuizuo.me/blog/rust-wasm-md5", "title": "Rust实现MD5加密并打包成WebAssembly调用", "summary": "我初识 WebAssembly 是当初想要分析某个网站的加密算法，最终定位到了一个 .wasm 文件，没错，这个就是 WebAssembly 的构建产物，能够直接运行在浏览器中。在我当时看来这门技术很先进，不过如今看来绝大多数的 web 应用貌似都没使用上，迄今为止我也只在这个网站中看到使用 WebAssembly 的（也许有很多，只是没实质分析过）。", "date_modified": "2023-01-04T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "rust", "wasm" ] }, { "id": "https://kuizuo.me/blog/2022-year-end-summary", "content_html": "距离上一篇博文有一个月之久，距离上次编写代码也有一周之久，由于疫情封控全面放开，加上福建省教育厅通知的提前返乡，反而让我感到有些不适。往常这个时间点我忙于期末考试，会把代码的事情放一边，等到彻底放假后，开始闭关潜心学习。然而剩余的半个月变成了线上形式，课还是要上，考试还是要考，虽说身在家乡，但心不在焉的。
\n12 月已过半，也是时候该写年终总结了。迄今为止，我已学习了 3 年半的编程（还好不是两年半）。当下的技术不再是当初只会易语言的小伙了。只是当下已没有当初如此强烈的热情与精力了，我称之为老了。
\n今年主要总结我为何从逆向转 Web 开发，并明确我未来所要走的方向，也是本文的主题。仅作为个人感悟，不作为建议参考。
\n我从高中开始，每年都会记录这一年所发生的比较有印象的事情并写下自己的感悟。所以写年终算是个人习惯，并且我希望能够一直坚持下去，写到不能写为止。
\n写年终总结是个非常好的自我总结与反思的方式，总结这一年自身的变化，有哪些精彩与满足，有哪些遗憾和不足。同时定制明年的规划，以该目标不断前行，而不是漫无目的地活着，就失去了很多人生的意义。
\n同时也算是自我评价与建议，很多时候我们会收到很多别人有关自己的评价与建议，可人总会对他人有莫名的排斥感，就难以虚心听从他人的建议，从而犯错许多（说的是我就对了）。年终总结还有个作用就是弥补自己对某件事情未来可能要发生的情况，要如何做到不犯错，预先有个明确的预防意识。
\n即便可能要花数天的周期去回顾与总结，我也很愿意去总结，我常说回顾过去，就是在仰望未来。写年终所做的也就是这个过程。
\n写年终总结也算是种分享，分享自己的开发经历，当他人阅读时或许有所启发。
\n过去的，就过去了，别将当下的遗憾留到未来，这就是年终的最大意义。
\n今年大部分的开发时间都花在 Web 开发上，在此期间也接触到许多技术，并通过博客笔记的方式记录下来。
\n我很庆幸我的 Web 开发从一个 Beginner 到 Intermediate，现在回忆整个学习路程，一路学得都很野很随意，从未系统学习过，总是学到一半，就自认为已经掌握了，便开始进行实战项目，可以说很多知识都是在实战探索中了解的。
\n虽然很多人都直称我为大佬，但我离 Advanced 还有一大段的路途要走，而这段路途是无比的艰难与漫长。不过好在路不歪，只要肯走终会到达终点。
\n而带我入门的逆向技术，在今年没有丝毫的长进，说得过分点，就是弃坑了。也正如标题所说，至于缘由，细看下文。
\n熟悉我的人应该知道我之前是做爬虫与逆向分析，但是为何今年的技术栈彻底转型到 Web 开发上。
\n我常常和别人说起我的技术栈转型（从逆向转到开发），不过比较多的都会比较好奇我为什么不继续深造下去。
\n在此我也回顾了我从逆向转变到 Web 开发的过程，顺带也回答这个问题。不过在这里先说说我个人对逆向的看法：
\n就我接触逆向的过程来说，接触了易语言，JavaScript，Python，Java，Php 等等编程语言。
\n使用过了一堆的逆向工具，如 Frida、IDA、JEB、jadx 等等（我目前能想到比较有名的）。此外还有一堆知识，包括但不限于以下技术：自动化脚本、TCP/HTTP 协议、抓包、爬虫、加密学、图像识别（验证码、滑块位置）、汇编、反编译、AST 反混淆。
\n**要我说我在逆向中学到的不是如何使用这些工具或掌握某个技能，而是锻炼出一定的阅读与分析代码能力。**工具与技能总是瞬息万变，但阅读与分析代码能力却是实实在在，一成不变的，也是逆向中最值得学习的。
\n有接触过 CTF 想必再熟悉不过逆向工程的技术面广了。
\n逆向分析，说白话就是去看别人的代码，进行一些修改手段，达到自己想要的目的。比如修改某个软件的标题或作者信息、将别人的代码“偷”过来用、爬取某些网站或软件的数据。
\n但是随着现在越来越多潜在的安全问题，很多框架底层，服务厂商，都会对一些可能有安全问题的代码进行警告或者底层处理。比如使用 ORM 框架能够有效防止 SQL 注入，前端框架中涉及 XSS 攻击也会有相应的错误提示与处理，再如浏览器跨域以及跨站点 cookie 不共享，都是为了用户的安全而去考虑的。这样的例子有太多了。
\n简单说说安卓逆向的过程：拿到一个 Apk，发现有加壳（给代码加固让逆向者不易于看到源代码），这时候就需要通过脱壳才能查看到源代码；此时就算脱完了壳，接下来可能将面对经过混淆过的代码，这份代码难以用人眼去阅读，不调试运行，单靠静态分析很难分析出东西，这时候可能就要借助 AST 对代码进行还原；还原完了配合动静分析将代码给扣出来，而在分析的时候可能又有各种检测，比如抓包，反调试以阻碍逆向进度；最后就算逆向工作都做完了，代码也扣下来了，还要尝试运行扣完的代码，这时候极大可能还不一定能运行，然后又要回头看看到底那一步做错了。
\n可以说逆向的工作就是不断地调试，不断分析，最终拿到想要的结果。整个过程可以说非常耗时且折磨人，心智如果不够强大，真的容易劝退（我当下耐心也早不如当初了）。但是得到最终的目的，将非常爽，成就感爆棚，相当于一个解了几小时的题，最终被攻克的感觉。
\n前阵子在逆向圈中，看到过一张图，大致也把我的逆向学习流程也表达了出来，最终我的逆向学习也确实止步在 Flutter 上。
\n![\"\"](\"https://img.kuizuo.me/1cd67d5812e3061e_zy9LIkXWIM.jpg\")
上面所说到的逆向技术中，例如加壳，代码混淆，反调试，风控等等，都是阻碍逆向手段。同样对于爬虫而已，通常会采取反爬措施，包括但不限于封 IP、封账号、JS 参数加密、代码混淆、浏览器指纹、TLS 指纹、验证等。而且防护手段可以说是越来越多，逆向的难度也就越来越大。并且在服务开发那边只需要修改一点东西，逆向可能就需要从头再来一遍。
\n未来逆向的难度只增不减，但薪资可不一定保证这趋势。
\n从上面也不难看出逆向常常与安全挂钩，如果一个网站或软件不是那么好被逆向，那么间接说明安全性是比较高的。可一旦涉及到安全，同时又是互联网，就免不了网络安全与法律相关的风险。
\n在大多数逆向的对象（网站，软件）中，多数都是他人的劳动产物，当你未经他人允许的情况下，去爬取他人的数据，或是修改一些版权信息再次发布出来，就属于非法行为。本质和未经他人允许，偷人家的东西性质是一个样的。并且在有防护措施的情况下，绕过网站防护措施获取数据属于违背权利人意愿读取、收集数据，将有较大可能被认定为对计算机信息系统的 “侵入”。
\n要知道在逆向的行业中，有很多都是擦边灰产，至少我所在的逆向圈是这样的，抱着【仅供学习为参考，请勿用于非法用途】的想法做逆向工程。路子极易走歪，很少能够正常去走安全岗位的。相信你应该能看到许多类似的案件，如【某某程序员因非法侵入 xx 网站，获刑 x 年】。这不是危言耸听，目前国家对网络安全以及非法数据获取的打击力度，也将决定了这些案件将会越来越多，爬虫逆向也将会越来越邢。
\n简单介绍完我认为爬虫和逆向的看法后，再来说说自身因素。
\n我是很享受写代码的过程，一份高质量的代码会让人赏心悦目。我为此特意学习下设计模式、重构技巧以及 TDD 测试。这些在逆向中基本难以涉及，但是这些对开发的体验和代码的健壮性都是非常重要的，也是让我个人觉得技术有所提升的技能点。
\n在逆向分析中，大部分时间都不是在写代码而是在看（分析）代码，而反编译出来的代码，很有可能是带有混淆过的代码，而你想要分析这一块代码的作用，只能去一步步调试，将代码啃下来，从而推断运行时某变量的值，或是某个函数的作用。
\n虽然说开发岗位中，有很多情况下也是在看代码的日子中度过的，但相比反编译阅读代码而言，至少不至于那么晦涩难懂。
\n其次，在逆向分析中，遇到的网站或软件所用的技术一般都是较为稳定成熟的技术，而这些技术往往不是很新，因此需要去了解很多旧的技术，但这些旧技术仅仅只对逆向分析有用，甚至过段时间很有可能就会遗忘。并且要了解的旧技术还不少，学得将会特别杂。
\n而我又是一个喜新厌旧的人，对任何新鲜事物都抱有好奇尝试的态度。我终将认为旧的技术被淘汰是迟早的问题，新技术的出现肯定不是无缘无故的出现，必然是为了解决某些问题而诞生的，如性能，开发体验，安全等等。
\n这里有篇我对新技术的看法，推荐阅读一番。
\n在逆向开发，不，是在灰产开发中，有很多代码是别指望开源出来的，这背后会涉及到商业利益或是版权等问题。一旦代码放出来，将意味着你的代码将有很大的可能被别人利用做坏事，最终甚至祸及到自己。所以大多数情况下，你多半只能将自己的应用发布出去，而不是将源码开源，通常也就带有商业化的性质。
\n我想任何开发者肯定是希望自己的代码走的更远，走的正规，而不是被拿来做违背自身意愿的事情。
\n开源不仅能为自己提升一些技术知名度，展现自身技术的一面，同时代码被他人使用与认可，这番成就感就足够继续坚持开源下去。因为我有很多技术都是通过开源项目中学到的，所以我能感受到开源带来的魅力，也是对于前人的崇拜，想走开源的原因。
\n因为淋过雨，所以很想为别人撑把伞
\n其实在今年出头我还特意复习了一波安卓逆向，为了更深入了解了更底层的知识与工具（当然现在忘得也差不多了），因一些特殊原因我的电子设备不在了，别问，问就是坏了到现在还没修好。就导致我的编程语言环境，逆向工具，虚拟机配置，代码等数据直接灰飞烟灭，也让我停滞了 1 个月的学习。
\n我想这才是我从逆向转 Web 开发的最重要的理由了。
\n逆向的学习对我开发有很大的帮助。例如开发中的安全问题，我在开发中都会时刻考虑去考虑该问题。如加壳、SQL 注入、代码混淆、接口限流、接口幂等性（Fiddle R 包）等等安全性问题。
\n我庆幸我学过逆向，让我学到很多在开发中比较难学到的技能，如调试，阅读源码，而这些也是绝大多数 Web 开发者都欠缺的能力。
\n逆向应该就暂以告终，未来会有很长的一段时间，甚至以后不再接触深入专研逆向。
\n每当回想，【当时那么难的加密算法都能搞得定，开发一个功能还能有多难】，保持着这种心态，也让我保持着开发。
\n也是逆向激起我对编程的兴趣，可以说没有接触逆向开发，我也不太可能会接触到 Web 开发。
\n上面对逆向的看法仅个人分析而言，但是 Web 开发就一定好吗？我不敢下绝对的肯定，不同人不一定适合相同的技术，但是我特别看好 Web 技术（尤其是 JavaScript，偏前端向），以下是我看好的点。
\n目前仍有很多人还停留在 JavaScript 只能编写前端页面的水平，自从 Node.js 问世，目前绝大多数的应用都可以使用 JavaScript 进行编写。
\n换句话说，只要你会 JavaScript 就可以编写很多应用了。有个在国外经常被应用的一条和 JavaScript 有关系的著名定律：
\nAtwood 定律：任何可以用 JavaScript 编写的应用程序，最终都会用 JavaScript 编写
\nWeb 前端开发不用多说，目前还得用 JavaScript 来编写。而后端开发通过 Node.js 也有一己之力。近几年特别流行跨平台开发，也就是一份代码，多端运行。
\n使用 React Native 或是 Uniapp 这样的前端应用框架，顺带去了解一下相应平台的 API，就能够编写出安卓或 IOS 应用，做过小程序开发肯定知道小程序的技术栈就使用到前端开发的技术栈，如果你会前端开发，就能很轻松的上手小程序开发了。
\n并且越来越多的软件都是网页版优先，然后再通过 Electron 这样的跨平台解决方案，实现不同平台间的程序。诸如 Vscode，Typeorm 等等便是其中的佼佼者。
\n不过本质上都是在不同应用的平台上套浏览器的壳，然后接入一些该平台的接口，因此普遍应用的体积与内存都相对比较大，与原生相比自然是略逊与原生，不过这点性能上的差异在如今硬件升级如此普遍的物质生活也显得微不足道了。
\n但借助浏览器自带的跨平台性，你所编写的应用能够非常轻松的让他人访问，只需要用户有个浏览器，并且通过上述跨平台的解决方案，也能够有效的将你的 web 应用转成其他平台的应用，而不是在耗费时间与精力去编写另一套代码。
\n在一些技术文档上，会有 API/SDK 的支持，而绝大多数都支持使用 JavaScript/Node.js，也许该功能本身并不是使用 JavaScript 来编写的，但完全可以通过 JavaScript 来轻松调用该功能。并且如今 JavaScript 生态如此庞大，你不必担心库/包的问题，npm 作为世界上最大的开放源代码的生态系统（包管理器），在这里你几乎找得到你所想要的库/包。
\n此外有越来越多的第三方服务平台（通常称 Fass，函数即服务），专门提供数据接口与用户鉴权，如 firebase/supabase 或是国产的云开发产品（如小程序）。前端程序员只需要专注与业务代码，借助第三方开发平台，就能够编写一个高可用的应用。反而也映衬了，Web 开发好像可以没有后端，但必须要有前端的观念。
\n这句话的意思可能有点加班那味道，但我所要表明的是可以做的事情多了，意味着你的工作量增加了，同时你的编码价值也就提升了，不过实际价值（工资）的话不一定提升，因为这主要看老板和地区。
\n怎么理解呢，我举几个例子。
\n现在大部分的 web 应用都采用前后端分离的形式，但在曾经则是由后端通过模板语言渲染成 HTML 直接返回，通过前后端分离的形式，前端只需要专注页面交互的编写，而后端只需要保证接口可靠性。并且前后端分离也有一个特别显著的特点，能非常有效的节省服务器的资源，原本服务器的渲染动作迁移至客户端来做。也许有人会说，那这样 SEO 优化该怎么办，这不就有了 Next.js、Nuxt.js 这样的 SSR（服务端渲染） 框架，而这些工作，也是前端要做的。
\n并且越到后面你越能感觉到客户端（前端）远比服务端（后端）做的东西来的多，比如开发阶段的数据 Mock，前端国际化，设计原型等等。之所以会有这种感觉，也许是因为我的大部分开发都是前端，这里你也可以回想当下的工作量与往年相比是多了还是不变。
\n前端真的是每隔一段时间，必定会出一些新的技术，也不由让不少前端学习者感叹真的学不动。但伴随着新的技术出现，必然会有新的岗位与机会，这也是我看好前端的一个点。
\n不过这种机会在国内不太多见，反而在国外特别普遍。 多的不说，自行体会。
\n忘记从哪看到的一句话：“前端工程师的一大焦虑：永远能（且必须要）看到大量前沿的技术，但自己手上的活儿跟不上，导致眼高手低。”
\n不只是前端，做技术这行的，必须要跟着技术发展的角度，并且要时刻关注最新，主流的技术。
\n有关 Web 开发的一些想法与感悟就写到这，其实还有蛮多可写的，比如选择 Vue 与 React？为什么是 JavaScript？有太多自我审问的话题了，不过由于当下时间相对紧迫，有机会的话再续写吧。
\n综上，也就是我看好 Web 技术的几个点，也回答了我未来的方向。希望这些能够帮助一些不知抉择方向的伙伴。
\n回顾整个技术栈，基本都是在项目实践中不断学习。也许是因为逆向的缘故，因为逆向基本上都是靠实战出来的，导致我的学习路线也趋于实践。
\n不过在我看来，写项目是最直接能体现出所想学的技术。我在学习一门新技术时，我通常会用项目或者博文的形式来总结我的学习过程。我也乐意花时间在这上面，并将其分享出来。当有其他人也在学习这门技术时，看到该项目或博文，我就认为非常有意义。
\n我在学任何一门技术，会使用该技术写点东西；换言之是为了写点东西，而去学点不一样技术。
\n如今来看，确实没那么想写代码，尤其是那种工作量大，重复性强的代码，而编写这些代码，其实与搬砖无任何区别，本质也是重复性与劳动性的任务。
\n曾经可能是因为接触得比较少，对于很多软件背后的原理及实现一概不知，所以看到啥就都想写写看，最终很多项目都成为半成品。
\n而随着越深入的学习，反而自己所想实现的东西，前人都已经帮我们实现好了。完全可以借用前人的代码，在此基础上学习与使用，而不必从头再来，耗费很多不必要的时间。
\n到最后为了实现一开始所想实现的东西，不用再费尽心思，去开源社区搜寻一番，总能找到与自己所要实现的类似的产品，此时只需要会看，会改，总能达到自己最终要实现的东西，有时候自己也称为了别人口中的 CV 工程师。
\n也正因如此，写代码的欲望就不再那么强烈。很多自认为无意义的代码或者是以后都不一定用得上的代码就少写了许多。于是乎缺少了很多自我思考与专研的时间，虽说也确实节省了很多不必要的时间，加快最终功能的实现，但这就是自己想要的编程生活吗？或者说这就是绝大多数人的编程生活。
\n现在回想，是什么驱使我学习，我心中的答案是无能。
\n当你什么都不会时，或者是目前的能力还不足够将某件事情做好，你就会不断地焦虑，犹如热锅上的蚂蚁，想做但又怕做不好。
\n我有很多社会技能是欠缺的，比如人际交往，谈话技巧，合作行为等等，并且我本身也不愿去学习这些技能。正因如此，只有不断发挥自身长处，用自己所擅长的领域弥补自己的短板，以提升自我在社会的竞争力，以至于不那么容易被淘汰。
\n要让自己保持每天都处于学习状态真的太难了 😩，生活总有源源不断的琐事打扰着你。在忙碌的时候总是感觉时间不够用，哪怕有时一天花费了数十个小时，也总感觉做的事情太少了；哪怕每天计划都规划得好好的，但总是有一半还未完成。生活中大量的碎片化时间，而编程学习最不需要的就是这些碎片化时间。
\n回顾整个编程生涯有太多可感慨的，整个旅途几乎是一个人走完的，期间遇到的坎坷就只得依靠搜索引擎来解决，搜索引擎是我再生父母都不为过。没有人给我指引明确的道路，只依靠心中对技术的憧憬不断前行。走过低谷，登过山峰，而如今站稳身子就足矣。
\n今年也是我重归学校的一年，倘若，去年没有休学一年的话，如今我可能已经在外实习了，转瞬一年就过去了，如今的我还沉浸在当初休学和别人创业工作的日子。
\n也是因为当时休学急迫，后事做得并未完善，学校的一些课程并未申请缓考，最终视为缺考，即挂科。然后此前对大学的课程也是抱着可有可无的心态，也挂了几门课程，如果不是辅导员告知，我还有 34 学分要补（20 学分为严重预警，40 学分为退学或降级处理），我都不曾了解自己在学校挂了这么多科 😂。最离谱的是有个同班同学正好就被降级处理了，不过好在今年上半年并未挂科，加上下半年也重修了一些课程，还不至于离本科毕业证书越走越远。
\n回到学校后，就感觉如同坐牢一般，只不过环境相对舒适一番，尤其是在疫情当下更是如此，我这一年出校玩乐的次数好像不超过 10 次。当我仔细回想一下大学的真正意义是什么？貌似就是混个日子，混个证书。我也想不出大学能够有什么实质性的作用，也许是因为我所处的学校不行，换个好一点的大学或许都不是这样了。
\n不过今年回学校反而去参加了曾经都不怎么看上的社团（虽然现在也差不了多少），给社团写了些项目，主要也为了给自己重返学校带点个人知名度。但因为学校不是那么有名（臭名可能有），所以这里就不便放上相关信息。
\n明年的话我就大三下了，面对我的有条熟知的考研路。说实话，从目前来看，我对考研不抱有太大的希望，我是属于实践派的那种，我坚信没有什么是试不出来。背理论，刷八股，我很反感。
\n不知道由于什么原因，总感觉一段时间不写代码，真的就不会写代码。仿佛与自己写的代码成为了陌生人一般（所以写注释的重要性就体现出来了）
\n倘若读研的话，必然将会有数个月的时间重心不在代码上，到时候回来编写代码时，又发现自己好像又重新学了一遍似的。加之万一上岸失败的心理落差，会让自我觉得这几个月的努力都白费。而我又恰好是一位结果论者，即只在意结果，不在意过程如何。在别人的眼中，是难以看到你考研备战努力的过程，只会在意你上没上岸。这便是我不想考研因素之一。
\n但今年在互联网上所认识伙伴中挺多给我过于高的评价，都认为我作为一个学生，能有这水平是不是在某某牛逼的高校读书。然而并不是，我甚至都不好意思述说自己的高校，说是我的污点也不为过。也正因此身份上，这不得让我萌生读研或是留学的一丝丝想法，也不至于死绝。
\n自我认为离真正的大佬还差很长的一段距离，我只是靠着三分钟热度才维系下去，而那些真正的大佬是肯花费大量时间去编写他们所认为有意义的代码。
\n今年的年终就告一段落，与之前的年终总结相比，篇幅缩减了许多，主要感觉之前写的挺多流水账的，废话挺多的。也有一点是因为时间相对紧迫，其实 12 月我还没放假，都处于线上上课，线上考试的状态，而线上考试的方式我就不得吐槽了，提前打印给定的答题纸，题目以电脑的方式展示，最终将答案手写到答题纸上并通过手机扫描（扫描全能王）成 PDF 的格式提交，当然摄像头必然也是有的。总之麻烦事还是有的，还没到彻底闲下来闭关学习的时候。
\n按往常可能还有明年的规划，但我现在认为很多时候都难以依照自身意愿做事，而规划正好自己所设想美好的计划，很容易事与愿违。因为回顾过往的规划，有太多美好的计划，但在实际分析下也将变得不堪一击。不止项目需要可行性分析，人生计划同样需要，一些天马行空幻想，其实就不再有意义去记录了。
\n坚持做自己想做的事情，而不是逼自己做不愿做的事情。这是我编程学习中座右铭，也是给予他人编程学习的建议。
\n写于2022年12月22日 By 愧怍
", "url": "https://kuizuo.me/blog/2022-year-end-summary", "title": "2022 · 逆向到Web开发", "summary": "距离上一篇博文有一个月之久，距离上次编写代码也有一周之久，由于疫情封控全面放开，加上福建省教育厅通知的提前返乡，反而让我感到有些不适。往常这个时间点我忙于期末考试，会把代码的事情放一边，等到彻底放假后，开始闭关潜心学习。然而剩余的半个月变成了线上形式，课还是要上，考试还是要考，虽说身在家乡，但心不在焉的。", "date_modified": "2022-12-22T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "年终总结" ] }, { "id": "https://kuizuo.me/blog/graphql-practice", "content_html": "\n\nGraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。
\n
大概率你听说过 GraphQL，知道它是一种与 Rest API 架构属于 API 接口的查询语言。但大概率你也与我一样没有尝试过 GraphQL。
\n事实上从 2012 年 Facebook 首次将 GraphQL 应用于移动应用，到 GraphQL 规范于 2015 年实现开源。可如今现状是 GraphQL 不温不火，时不时又有新的文章介绍，不知道的还以为是什么新技术。
\n本文将上手使用 GraphQL，并用 Nestjs 与 Strapi 这两个 Node 框架搭建 GraphQL 服务。
关于 GraphQL 介绍，详见官网 GraphQL | A query language for your API 或相关介绍视频 GraphQL 速览：React/Vue 的最佳搭档
\n![\"\"](\"https://img.kuizuo.me/9a7412200a062646b729c8419be28b35.jpeg\")
Restful 架构的设计范式侧重于分配 HTTP 请求方法（GET、POST、PUT、PA TCH、DELETE）和 URL 端点之间的关系。如下图
\n![\"\"](\"https://img.kuizuo.me/17fc41e2de8d829dc2d41e31a0775df3.png\")
但是实际复杂的业务中，单靠 Restful 接口，需要发送多条请求，例如获取博客中某篇博文数据与作者数据
\nGET /blog/1
GET /blog/1/author
要么单独另写一个接口，如getBlogAndAuthor，这样直接为调用方“定制”一个接口，请求一条就得到就调用方想要的数据。但是另写一个getBlogAndAuthor 就破坏了 Restful API 接口风格，并且在复杂的业务中，比如说还要获取博文的评论等等，后端就要额外提供一个接口，可以说非常繁琐了。
有没有这样一个功能，将这些接口做一下聚合，然后将结果的集合返回给前端呢？在目前比较流行微服务架构体系下，有一个专门的中间层专门来处理这个事情，这个中间层叫 BFF（Backend For Frontend）。可以参阅 BFF——服务于前端的后端
\n![\"\"](\"https://img.kuizuo.me/Y4u9tNpZwR.png\")
但这些接口一般来说都比较重，里面有很多当前页面并不需要的字段，那还有没有一种请求：客户端只需要发送一次请求就能获取所需要的字段
\n有，也就是接下来要说的 GraphQL
\n![\"\"](\"https://img.kuizuo.me/8a141ec5fa73781d66fb2e1b60f9b49d.jpg\")
REST API 构建在请求方法（method）和端点（endpoint）之间的连接上，而 GraphQL API 被设计为只通过一个端点，即 /graphql，始终使用 POST 请求进行查询，其集中的 API 如 http://localhost:3000/graphql，所有的操作都通过这个接口来执行，这会在后面的操作中在展示到。
但是想要一条请求就能得到客户端想要的数据字段，那么服务端必然要做比较多的任务 😟（想想也是，后端啥都不干，前端就啥都能获取，怎么可能嘛）。
而服务端要做的就是搭建一个 GraphQL 服务，这在后面也会操作到，也算是本文的重点。
接下来便会在客户端中体验下 GraphQL，看看 GraphQL 究竟有多好用。
\n可以到 官网 中简单尝试入门一下，在 Studio 可在线体验 GraphQL，也可以到 SWAPI GraphQL API 中体验。
\n下面以 apollographql 为例，并查询 People 对象。
查询所有 People 并且只获取 name、gender、height 字段
![\"\"](\"https://img.kuizuo.me/kvWUNtlUbf.png\")
查询 personID 为 1 的 Person 并且只获取 name，gender，height 字段
![\"\"](\"https://img.kuizuo.me/Msg9xwWFrl.png\")
查询 personID 为 2 的 Person 并且只获取 name，eyeColor、skinColor、hairColor 字段
![\"\"](\"https://img.kuizuo.me/hX0l36Acme.png\")
从上面查询案例中其实就可以发现，我只需要在 person 中写上想要获取的字段，GraphQL 便会返回带有该字段的数据。避免了返回结果中不必要的数据字段。
\n{
\tperson{
\t\t# 写上想获取的字段
\t}
}
如果你不想要 person 数据或者想要其他其他的数据，不用像 Restful API 那样请求多条接口，依旧请求/graphql，如
![\"\"](\"https://img.kuizuo.me/Z0b6ya-auG.png\")
无论你想要什么数据，一次请求便可满足。
GraphQL 的大部分讨论集中在数据获取（也是它的强项），但是任何完整的数据平台也都需要一个改变服务端数据的方法。即 CRUD。
\nGraphQL 提供了 变更(Mutations) 用于改变服务端数据，不过 apollographql 在线示例中并没有如 createPeople 字段支持 。这个片段在线体验中就无法体验到，后在后文中展示到。这里你只需要知道 GraphQL 能够执行基本的 CRUD 即可。
此外还有 fragment 与 subscription 就不做介绍。
尝试完上面这些操作后，可以非常明显的感受到 GraphQL 的优势与便利，本来是需要请求不同的 url，现在只需要请求 /graphql，对调用方（前端）来说非常友好，香是真的香。
可目前只是使用了别人配置好的 GraphQL 服务，让前端开发用了特别友好的 API。但是，对于后端开发而言，想要提供 GraphQL 服务可就不那么友善了。因为它不像传统的 restful 请求，需要专门配置 GraphQL 服务，而整个过程是需要花费一定的工作量（定义 Schema，Mutations 等等），前面也提到想要一条请求就能得到客户端想要的数据字段，那服务端必然需要额外的工作量。
\n不仅需要在后端中配置 GraphQL 服务，用于接收 GraphQL 查询并验证和执行，此外前端通常需要 GraphQL 客户端，来方便使用 GraphQL 获取数据，目前实用比较多的是Apollo Graph，不过本文侧重搭建 GraphQL 服务，因此前端暂不演示如何使用 GraphQL。
\n你可能听过一句话是，graphql 大部分时间在折磨后端，并且要求比较严格的数据字段，但是好处都是前端。把工作量基本都丢给了后端，所以在遇到使用这门技术的公司，尤其是后端岗位就需要考虑有没有加班的可能了。
\n以下便会开始实际搭建 GraphQL 服务，这里会用 Nest.js 与 Strapi 分别实践演示。
\n官方文档：GraphQL + TypeScript | NestJS
\n\n仓库本文实例代码仓库： kuizuo/nest-graphql-demo
\n创建项目
\nnest new nest-graphql-demo
安装依赖
\nnpm i @nestjs/graphql @nestjs/apollo graphql apollo-server-express
修改 app.module.ts
\nimport { 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 {}
设置了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 非常关键，决定了你客户端能够请求到什么数据。
\n尝试输入 GraphQL 的 query 查询（可以按 Ctrl + i 触发代码建议（Trigger Suggest），与 vscode 同理）
\n![\"\"](\"https://img.kuizuo.me/a3yl4oVtSU.png\")
此时点击执行，可以得到右侧结果，即app.resolver.ts 中 hello 函数所定义的返回体。
![\"\"](\"https://img.kuizuo.me/bK9bvZ3QMm.png\")
在 nestjs 中有 Code first 与 Schema first 两种方式来生成上面的 Schema，从名字上来看，前者是优先定义代码会自动生成 Schema，而后者是传统方式先定义 Schema。
\n在上面一开始的例子中是 Code First 方式，通常使用该方式即可，无需关心 Schema 是如何生成的。下文也会以 Code First 方式来编写 GraphQL 服务。
\n也可到官方示例仓库中 nest/sample/31-graphql-federation-code-first 和 nest/sample/32-graphql-federation-schema-first 查看两者代码上的区别。
\nnest 提供 cli 的方式来快速生成 GraphQL 模块
\nnest g resource <name>
![\"\"](\"https://img.kuizuo.me/L9yYAn78Dw.png\")
比如创建一个 blog 模块
\nnest 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)
便会生成如下文件
\n![\"\"](\"https://img.kuizuo.me/XemqTcfz_D.png\")
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 如下
\n![\"\"](\"https://img.kuizuo.me/sJCQpllOXK.png\")
不过nest cli创建的blog.service.ts 只是示例代码，并没有实际业务的代码。
此外blog.entity.ts也不为数据库实体类，因此这里引入typeorm，并使用sqlite3
安装依赖
\npnpm 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 字段无需返回，就不必要加该装饰器。
如果你认为 添加 @Field() 是件繁琐的事情（nest 官方自然也想到），于是提供了 GraphQL + TypeScript - CLI Plugin 用于省略 @Field() 等其他操作。（类似于语法糖）
借用官方的话:
\nThus, you won't have to struggle with @Field decorators scattered throughout the code.
\n
因此，您不必为分散在代码中的 @Field 装饰符而烦恼。
@nestjs/graphql 会将 typescript 的 number 类型视为 Float，所以需要转成 Int 类型，即 @Field(() => Int)
在 BlogService 编写 CRUD 数据库业务代码，并在 dto 编写参数效验代码，这里简单暂时部分代码。
\nimport { 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
}
此时
\n![\"\"](\"https://img.kuizuo.me/7-twN56Aym.png\")
下面将演示 graphql 的 Mutation。
\n![\"\"](\"https://img.kuizuo.me/NPqShDN3Pl.png\")
![\"\"](\"https://img.kuizuo.me/c4ycwRs-po.png\")
![\"\"](\"https://img.kuizuo.me/xpkHhpS1-K.png\")
Query 就不在演示。
\n至此，在 Nest.js 中配置 GraphQL 服务的就演示到此，从这里来看，Nest.js 配置 GraphQL 服务还算比较轻松，但是做了比较多的工作量，创建 resolver，创建 modal（或在已有实体添加装饰器），不过本文案例中只演示了基本的 CRUD 操作，实际业务中还需要涉及鉴权，限流等等。
\nStrapi 官方提供 GraphQL 插件 免去了配置的繁琐。更具体的配置参见 GraphQL - Strapi Developer Documentation
\n这里我就选用 kuizuo/vitesse-nuxt-strapi 作为演示，并为其提供 graphQL 支持。
\nstrapi 安装
\nnpm install @strapi/plugin-graphql
接着启动 strapi 项目，并在浏览器打开 graphql 控制台 http://localhost:1337/graphql，以下将演示几个应用场景。
\n![\"\"](\"https://img.kuizuo.me/4GFUs8CmQJ.png\")
![\"\"](\"https://img.kuizuo.me/NMM4e3L_y8.png\")
![\"\"](\"https://img.kuizuo.me/E1eWrzjaEs.png\")
![\"\"](\"https://img.kuizuo.me/pclR7Zb6TE.png\")
![\"\"](\"https://img.kuizuo.me/g3RJL7RQWR.png\")
![\"\"](\"https://img.kuizuo.me/m7s17q2TG0.png\")
由于 Nuxt Strapi 提供 useStrapiGraphQL 可以非常方便是在客户端调用 GraphQL 服务。
\n<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 服务。
\nGraphQL 翻译过来为 图表 Query Language，我所理解的理念是通过 json 数据格式的方式去写 SQL，而且有种前端人员在写 sql 语句。在我看来 GraphQL 更多是业务数据特别复制的情况下使用，往往能够事半功倍。但对于本文中示例的代码而言，GraphQL 反倒有点过于先进了。
\n如今看来，GraphQL 还处于不温不火的状态，目前更多的站点主流还是使用 Restful API 架构。我不过我猜测，主要还是大多数业务没有 API 架构的升级的需求，原有的 Restful API 虽说不够优雅，但是也能够满足业务的需求，反而 GraphQL 是一个新项目 API 架构的选择，但不是一个必须的选择。
\n至于如何选择，可以参阅官方 GraphQL 最佳实践，至于说有没有必要学 GraphQL，这篇文章 都快 2022 年了 GraphQL 还值得学吗 能给你答案。我的建议是了解即可，新项目可以考虑使用，就别想着用 GraphQL 来重构原有的 API 接口，工作量将会十分巨大，并且还可能是费力不讨好的事。反正我认为这门技术不像 Git 这种属于必学的技能，我的五星评分是 ⭐⭐
\n但多了解一门技术，就是工作面试的资本。回想我为何尝试 GraphQL，就是因为我无意间看到了一份 ts 全栈的远程面试招聘，在这份招聘单中写到 【会 graphql 编写是加分项】。所以抱着这样的态度去尝试了一番，说不准未来就是因为 graphql 让我拿到该 offer。当然也是因为很早之前就听闻 GraphQL，想亲手目睹下是否有所谓的那么神奇。
", "url": "https://kuizuo.me/blog/graphql-practice", "title": "GraphQL 实践与服务搭建", "summary": "有关 GraphQL 介绍及上手实践，并在 Nest.js 和 Strapi 中搭建 GraphQL 服务", "date_modified": "2022-11-24T00:00:00.000Z", "author": { "name": "愧怍", "url": "https://github.com/kuizuo" }, "tags": [ "api", "graphql", "nest", "strapi" ] } ] }