React Native 开发心得分享

要说 2024 年 Node.js 的 ORM 框架应该选择哪个？毫无疑问选 Prisma。至于为何，请听我细细道来。



本文面向的对象是饱受 TypeORM 折磨的资深用户(说的便是我自己)。只对这两个 ORM 框架从开发体验上进行对比，你也可以到 [这里](https://www.prisma.io/docs/orm/more/comparisons/prisma-and-typeorm) 查看 Prisma 官方对这两个 ORM 框架的对比。

## 整体对比

### 更新频率 & 下载量

TypeORM 距离上次更新已经过去半年之久了（下图截取自 24 年 1 月 1 日，没想到年初竟然还复活了）

![Untitled](https://img.kuizuo.cn/2024/0113165614-Untitled.png)

从下载量以及 star 数来看，如今 Prisma 已经超过 TypeORM，这很大一部分的功劳归功于像 Next.js、Nuxt.js 这样的全栈框架。

![Untitled](https://img.kuizuo.cn/2024/0113165632-Untitled%201.png)

上图来源 [https://npmtrends.com/prisma-vs-typeorm](https://npmtrends.com/prisma-vs-typeorm)

而在 Nest.js 的 [Discord 社区](https://discord.com/channels/520622812742811698/1156124199874732033) 讨论之中，Prisma 也成为诸多 Nest.js 开发者首选的 ORM 框架，因为它有着更好的开发体验。

在大势所趋之下相信你内心已经有一份属于自己的答案。

### 文档 & 生态

从文档的细致程度上 Prisma 比 TypeORM 要清晰详尽。在 [Get started](https://www.prisma.io/docs/getting-started) 花个数十分钟了解 Prisma 基本使用，到 [playground.prisma.io](https://playground.prisma.io/) 中在线尝试，到 [learn](https://www.prisma.io/learn) 查看官方所提供的免费教程。

此外 Prisma 不仅支持 js/ts 生态，还支持其他语言。丰富的[生态](https://www.prisma.io/ecosystem)下，加之 Prisma 开发团队的背后是由商业公司维护，无需担心需求得不到解决。

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%202.png)

## 开发体验对比

在从开发体验上对比之前，我想先说说 TypeORM 都有哪些坑(不足)。

### findOne(undefined) 所查询到的却是第一条记录

首先 TypeORM 有个天坑，你可以在 这个 [Issue](https://github.com/typeorm/typeorm/issues/2500) 中查看详情或查看 [这篇文章](https://pietrzakadrian.com/blog/how-to-hack-your-nodejs-application-which-uses-typeorsm) 是如何破解使用 TypeORM 的 Node.js 应用。

当你使用 `userRepository.findOne({ where: { id: null } })` 时，从开发者的预期来看所返回的结果应该为 null 才对，但结果却是大跌眼镜，结果所返回的是 user 表中的第一个数据记录！

你可能会说，这不是 bug 吗？为何官方还不修。事实上确实是 bug，而事实上官方到目前也还没修复该 bug。再结合上文提到的更新频率，哦，那没事了。

目前解决方法则是用 `createQueryBuilder().where({ id }).getOne()` 平替上一条语句或者确保查询参数不为 undefined。从这也可以看的出，TypeORM 在现今或许并不是一个很好的选择。

### synchronize: true 导致数据丢失

`synchronize` 表示数据库的结构是否和代码保持同步，官方提及到请不要在生产环境中使用，但在开发阶段这也并不是一个很好的做法。举个例子，有这么一个实体

```ts title='user.entity.ts' icon='logos:nestjs'
@Entity()
export class User {
 @PrimaryGeneratedColumn()
 id: number

 @Column()
 name: string
}
```

当开启了 `synchronize: true`，并且将 `name` 更改为 `title` 时，一旦运行 nest 服务后就会发现原有 `name` 下的数据全都丢失了！如图所示

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%203.png)

因为 TypeORM 针对上述操作的 sql 语句是这样的

```sql
ALTER TABLE `user` CHANGE `name` `title` varchar(255) NOT NULL
ALTER TABLE `user` DROP COLUMN `title`
ALTER TABLE `user` ADD `title` varchar(255) NOT NULL
```

也就是说，当你在开发环境中，修改某个字段（包括名字，属性）时，该字段原有的数据便会清空。

因此针对数据库更新的操作最正确的做法是使用迁移(migrate)。

### 接入成本

在 Nest 项目中，Prisma 的接入成本远比 TypeORM 来的容易许多。

相信你一定有在 `xxx.module.ts` 中在 imports 中导入 `TypeOrmModule.forFeature([xxxEntity])` 的经历。就像下面代码这样：

```ts title='xxx.module.ts' icon='logos:nestjs'
@Module({
 imports: [TypeOrmModule.forFeature([UserEntity])],
 controllers: [UserController],
 providers: [UserService],
 exports: [TypeOrmModule, UserService],
})
export class UserModule {}
```

对于初学者而言，很大程度上会忘记导入 `xxxEntity`，就会出现这样的报错

```bash
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。

```ts title='user.service.ts' icon='logos:nestjs'
@InjectRepository(UserEntity)
private readonly userRepository: Repository<UserEntity>
```

一旦实体一多，要注入的 Repository 也就更多，无疑不是对开发者心智负担的加深。

再来看看 Prisma 是怎么导入的，你可以使用 [nestjs-prisma](https://nestjs-prisma.dev/docs/basic-usage/) 或者按照官方文档中[创建 PrismaService](https://docs.nestjs.com/recipes/prisma#use-prisma-client-in-your-nestjs-services)。

然后在 service 上，注入 PrismaService 后，就可以通过 `this.prisma[model]` 来调用模型(实体) ，就像这样

```ts title='app.service.ts' icon='logos:nestjs'
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。

### 更好的类型安全

Prisma 的贡献者中有 [ts-toolbelt](https://github.com/millsp/ts-toolbelt) 的作者，正因此 Prisma 的类型推导十分强大，能够自动生成几乎所有的类型。

而反观 TypeORM 虽说使用 Typescript 所编写，但它的类型推导真是一言难尽。我举几个例子：

在 TypeORM 中，你需要 select 选择某个实体的几个字段，你可以这么写

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%204.png)

你会发现 post 对象的类型提示依旧还是 postEntity，没有任何变化。但从开发者的体验角度而言，**既然我选择查询 id 和 title 两个字段，那么你所返回的 post 类型应该也只有 id 与 title 才更符合预期**而后续代码中由于允许 post 有 body 属性提示，那么 post.body 为 null 这样不必要的结果。

再来看看 Prisma，你就会发现 post 对象的类型提示信息才符合开发者的预期。像这样的细节在 Prisma 有非常多。

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%205.png)

这还不是最关键的，TypeORM 通常需要使用 `createQueryBuilder` 方法来构造 sql 语句来满足开发者所要查询的预期。而当你使用了该方法，你就会发现你所编写的代码与 js 无疑，我贴几张图给大伙看看。

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%206.png)

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%207.png)

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%208.png)

这无疑会诱发一些潜在 bug，我就多次因为要 select 某表中的某个字段，却因拼写错误导致查询失败。

### 创建实体

在 TypeORM 中，假设你要新增一条 User 记录，你通常需要这么做

```ts
const newUser = new User()
newUser.name = 'kuizuo'
newUser.email = 'hi@kuizuo.cn'
const user = userRepository.save(newUser)
```

当然你可以对 User 实体中做点手脚，像下面这样加一个构造函数

```ts title='user.entity.ts' icon='logos:nestjs'
@Entity()
export class User {
 @PrimaryGeneratedColumn()
 id: number

 @Column({ unique: true })
 username: string

 @Column()
 email: string

 constructor(partial?: Partial<UserEntity>) {
 Object.assign(this, partial)
 }
}
```

```ts
const newUser = new User({
 name: 'kuizuo',
 email: 'hi@kuizuo.cn',
})
const user = userRepository.save(newUser)
```

于是你就可以传递一个 js 对象到 User 实体，而不是 newUser.xxx = xxx 像 Java 版的写法。

而要是涉及到多个关联的数据，往往需要先查询到关联数据，然后再像上面这样赋值+保存。这里就不展开了，使用过 TypeORM 的应该深有体会。

而在 Prisma 中，绝大多数的操作你都只需要一条代码语句外加一个对象结构，像上述 TypeORM 的操作对应 Prisma 的代码语句如下

```ts
const user = await prisma.user.create({
 data: {
 name: 'kuizuo',
 email: 'hi@kuizuo.cn',
 },
})
```

### 根据条件来创建还是更新

在数据库中操作经常需要判断数据库中是否有某条记录，以此来决定是更改该记录还是创建新的一条记录，而在 Prisma 中，完全可以使用 upsert，就像下面这样

```ts
const user = await prisma.user.upsert({
 where: { id: 1 },
 update: { email: 'example@prisma.io' },
 create: { email: 'example@prisma.io' },
})
```

### 聚合函数

在 TypeORM 中，假设你需要使用聚合函数来查询的话，通常会这么写

```ts
const raw = await this.userRepository
 .createQueryBuilder('user')
 .select('SUM(user.id)', 'sum')
 .getRawOne()

const sum = raw.sum
```

如果只是像上面这样，单纯查询 sum，那么 raw 的值是 `{ sum: 1 }` , 但最要命的就是 `select` 配合 `getRawOne` 还要额外查询 user 实体的属性，所得到的结果就像这样

```ts
const raw = await this.userRepository
 .createQueryBuilder('user')
 .select('SUM(user.id)', 'sum')
 .addSelect('user')
 .where('user.id = :id', { id: 1 })
 .getRawOne()
```

```ts
{
	user_id: 1,
	user_name: 'kuizuo',
	user_email： 'hi@kuizuo.cn',
	sum: '1'
}
```

所有 user 的属性都会带有 `user_` 前缀，这看上去有点不是那么合理，但如果考虑要联表查询的情况下，就会存在相同名称的字段，通过添加表名(别名)前缀就可以避免这种情况，这样来看貌似又有点合理了。

但还是回到熟悉的类型安全，这里的所返回的 raw 对象是个 any 类型，一样不会有任何提示。

而在 Prisma 中，提供了 专门用于聚合的方法 [aggregate](https://www.prisma.io/docs/orm/reference/prisma-client-reference#aggregate)，可以特别轻松的实现聚合函数查询。

```ts
const minMaxAge = await prisma.user.aggregate({
 _count: {
 _all: true,
 },
 _max: {
 profileViews: true,
 },
 _min: {
 profileViews: true,
 },
})
```

```ts
{
 _count: { _all: 29 },
 _max: { profileViews: 90 },
 _min: { profileViews: 0 }
}
```

---

看到这里，你若是长期使用 TypeORM 的用户必定会感同身受如此糟糕的体验。那种开发体验真的是无法用言语来形容的。

## Prisma 生态

### 分页

在 Prisma 你要实现分页，只需要在 prismaClient 继承 [prisma-extension-pagination](https://github.com/deptyped/prisma-extension-pagination) 这个库。就可像下面这样，便可在 model 中使用paginate方法来实现分页，如下代码。

```ts
import { PrismaClient } from '@prisma/client'
import { pagination } from 'prisma-extension-pagination'

const prisma = new PrismaClient().$extends(pagination())
```

```ts
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)。

:::tip 两种分页的使用场景

按页查询: 用于传统分页，例如翻页

光标查询: 根据游标进行查询，例如无限滚动

:::

而在 TypeORM 你通常需要自己封装一个 paginate方法，就如下面代码所示（以下写法借用 [nestjs-typeorm-paginate](https://www.npmjs.com/package/nestjs-typeorm-paginate)）

```ts
async 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 方法，支持链式调用。但这无疑增添了开发成本。

### 根据 Schema 自动生成数据验证

得益于 Prisma 强大的数据建模 dsl，通过 [generators](https://www.prisma.io/docs/orm/prisma-schema/overview/generators) 生成我们所需要的内容（文档，类型），比如可以使用 [zod-prisma-types](https://github.com/chrishoermann/zod-prisma-types) 根据 Schema 生成 [zod](https://github.com/colinhacks/zod) 验证器**。**

举个例子，可以为 schema.prisma 添加一条 generator，长下面这样

```prisma title='prisma.schema' icon='logos:prisma'
generator client {
 provider = "prisma-client-js"
 output = "./client"
}

generator zod {
 provider = "zod-prisma-types"
 output = "./zod"
 createModelTypes = true
	// ...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 信息，其中片段代码如下

```ts title='zod/index.ts' icon='logos:typescript-icon'
export 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 类，就像下面这样

![Untitled](https://img.kuizuo.cn/2024/0113165658-Untitled%209.png)

当然你可能并不想在 nestjs 项目中使用 zod，而是希望使用传统的 [class-validator](https://www.npmjs.com/package/class-validator) 来编写 dto。可以使用社区提供的 [prisma-class-generator](https://github.com/kimjbstar/prisma-class-generator) 根据已有 model 生成 dto。

---

合理来说，Prisma 并不是一个传统的 ORM，它的工作原理并不是将表映射到编程语言中的模型类，为处理关系数据库提供了一种面向对象的方式。而是在 Prisma Schema 中定义模型。在应用程序代码中，您可以使用 Prisma Client 以类型安全的方式读取和写入数据库中的数据，而无需管理复杂模型实例的开销。

![](https://img.kuizuo.cn/2024/0113171541-202401131715135.png)

总而言之，你若想要[更好的类型](https://www.prisma.io/docs/orm/prisma-client/type-safety)，简洁的[实体声明语法](https://www.prisma.io/docs/orm/prisma-schema/data-model/database-mapping#prismas-default-naming-conventions-for-indexes-and-constraints)，况且带有[可视化桌面端应用](https://www.prisma.io/studio)，以及更好的[生态完备](https://www.prisma.io/ecosystem)，那么你就应该选 Prisma。

## 总结

在写这篇文章时，我也是彻底的将 Nestjs 项目中由 TypeORM 迁移到 Prisma ，这期间给我最大的变化就是在极少的代码量却又能实现强大的功能。许多涉及多表的 CRUD操作可以通过一条简洁的表达式来完成，而在使用 TypeORM 时，常常需要编写繁琐臃肿的 queryBuilder。

TypeORM 有种被 nestjs 深度绑定的模样，一提到 TypeORM，想必第一印象就是 Nestjs 中所用到的 ORM 框架。然而，Prisma 却不同，是一个全能通用的选择，可以在任何的 js/ts 框架中使用。

从开发体验的角度不接受任何选择 TypeORM 的反驳，有了更优优秀的选择，便不愿意也不可能在回去了。如果你还未尝试过 Prisma，我强烈建议你亲身体验一番。

有了 Prisma 就别用 TypeORM 了

又到了年底写年终总结的时候了，说实话今年感觉没什么内容可写。上半年发生了比较多的事不方便叙述，而下半年我忙于学校课程 + 课程重修，过得其实还有点浑浑噩噩。

不过如今都大四了，也确实是要考虑实习的事了。我想结合我自身情况，谈谈我是怎么看待工作或者往远点说职业规划方面的想法。



## 一些经历

### 工作经历

我目前一共有 3 段工作经历

1. 休学一年在厦门本地某工作室(共4人)与他人创业。 2021.1 ~ 2022.1
2. 在北京的一家公司(规模不大)远程实习。 2022.8 ~ 2022.10
3. 在 [3R 教室](https://3rcd.com) 兼任助教与开发组成员。 2023.1 ~ 2023.12

事实上，对我而言也仅有休学的那一段才能算是工作，而其他两者从年限与工作性质来看不能算是一份真正的工作。但也不能说不是，至少也替别人做过事、签过合同、领过工资的。

不过我想稍微提提我是怎么找到这三个工作的，或者说这三份工作是怎么找到我的 -> **全靠分享**

我不止说过一次分享的重要性，我的第一份工作就是在网络分享了[一个大学生自动完成视频、作业的程序](/blog/chaoxing-helper)，恰好被我当地一个工作室的同事看到，寻求我能否改进功能一同合作，于是一拍即可，便开始[休学](/blog/narrate-a-college-student#休学)。

剩余的两个工作同样也是，一个契机是我当时正好在研究 [Strapi](https://strapi.io) 编写了一篇文章，这家公司恰好用到这门技术；而 3R教室则是因为创始人所用的与我博客相同的网站生成器 [Docusaurus](https://docusaurus.io/zh-CN) 在这个机缘下认识的，后来创始人创业开了3R教室，我也就利用业余时间在其中扮演助教身份，赚个零花钱。（其实我很热心肠的，哪怕我不当助教，只要时间允许的情况下，你有问题问我也会尽数回答）

### 接单经历

同样的，分享也能很大程度上提升你接单的资本。

我并非想要炫耀什么，而是分享实实在在给我带来了很多好处，我希望你能够分享一些内容，一些见解心得，哪怕是一些笔记、对他人问题的回复，都可能给你带来一些意想不到的好处。

我就有一个同学将自己的笔记、课设以及每次专业课期末考试的文档放到 CSDN 上（没错就是那个 IT 界的毒瘤），现在这不到期末了嘛，他的私信就有一堆人找他写课设啥的。

回归到正题，我接过单不多也不少，绝大多数是那种对我而言挺简单的问题，但对于一些人而言就比较困难。例如前几天一个例子，我编写过 [js-deobfuscator](https://github.com/kuizuo/js-deobfuscator) 一个 js 混淆还原的工具，正好有人需要将一份混淆代码还原出来，于是寻求我的帮助，发了个红包给我。有时哪怕只是回答别人一个问题，甚至都可能会收到来自他人的红包。想想看，你在技术群里是不是有过这个现象。

还有一个网站的单子我印象很深，是一个用于销售流量、虚拟会员等商品的网站，不同与普通的商城系统，充值是通过卡密，使用卡密到特定的网站上使用。当时一个网站全套 5000，客户也算熟人了，还帮我推荐几个人购买，相当于这一套网站(模版)，帮我赚了几 w，还省去我很多开发成本，后续我都无偿给他提供技术服务。

事实上至少现在为止我并不是很喜欢接单，也很少主动接单。小的单（也可叫零活）通常以一顿夜宵作为回报或是看在人情的份上；而大的单（通常为外包单），通常要求交付时间快，很多时候只为了更快的完成功能，而不考虑代码质量。并且通常没有维护性可言，就更别说写测试和重构了。写久了，代码虽然写的是快了，但堆屎山的速度都堪比屎壳郎了。代码能力的提升反而不是很大。

在我看来当因某种目的收了他的钱财时，往往就要花费时间精力去完成这个目的，而从我内心上很难平衡这点。所以只要我不收钱，我就可以不做事了（bushi

### 赚钱经历

我赚的第一桶金其实还不是我工作，在上大学前我已经赚过对我两桶金了，还全都是依靠网络上的资源，而非现实打工。一次是初三当时向别人学习如何刷钻以及购买钻卡来接单帮别人刷钻，另一个是作为线报群群主（现如今更多的称之为羊毛群，但我更愿称撸界），发布一些活动和教程通过拉人头引流赚钱。而也是再次契机之下，学会了开发(定制)软件。

这并非本文重点，因此我并不想过多介绍，但或许这会作为后面的铺垫。

不过我还是想说：**赚钱不易**。我现在回看我过去的一些经历，只能说运气成分很大，而又恰好在风口之中。在如今的互联网环境下，想要复刻曾经的路, 无疑是死路一条。

## 为何不实习？

背景介绍完了，那就来说说实习的事情，为何我都大四了，还不找实习？

不是不找，而是很难找到满意的。我在今年暑期的时候有尝试找过，投过几家大厂，无一例外，了无音讯。这对我当时而言，打击还蛮大的。因为三流学校出身，确实很难过（双关），加之没人内推，海投基本上是没希望的。

如今前端的职位卷之又卷，僧多粥少，在厦门一些中小公司所提供的前端实习待遇（薪资大约在 3k~4k），况且对自身的提升并不是特别大，在我不是一笔性价比划得来的买卖。

反观学校的情况那可就更头疼了，你敢相信在大四上最该实习的时候，极为不合理的教案却还要给学生安排课程，还是专业课的那种，以下我的课表。

![](https://img.kuizuo.cn/2023/1231064437.png)

此外，我还需要重修当初因休学而没去考试的几门课程（还挺多的，重修费还交了我不少😢），导致我最后一场考试时间是在 12月中旬。还是强调那一点，我不希望工作与学业这两者同时进行。关于这学校的诸多不满，待我毕业后我一定要说说，感受什么叫中国的私立大学。

此外还有一点，也是我不想提及的一点，这段期间我是处于“监视”状态，内心总悬着一个不知何时爆炸的炸弹，生怕突然爆炸将会打乱我的行程。

![image-20231226224325326](https://img.kuizuo.cn/202312271649106.png)

好在如今期限已到，心里悬着的一块石头终于放下来了，如释重负。

于是在上述的因素下，今年下半年我就不想找实习了。

## 为何又想实习了？

最主要的一点就是以我目前学生(应届生)的身份，是可以有机会争取到一份好的实习的，乃至是大厂的实习。

其次是我并没有一个很好的项目演进经历，看完我的一些工作经历不难发现我所待的公司/工作室的体量都不大，甚至我到现在都没真正体验过打卡上班（当然我也希望不要有）。而这就是小厂或者初创公司的同病，各个流程所要负责的任务很模糊。我当时休学和他人创业工作，基本上都是我一人负责项目开发；第二个远程实习也是我当时主动退出的，因为工作形式与接单无疑；第三个就不用多说了。

尤其是在技术层面的团队协作之中，还缺乏相当多的实践经验。所以在自我分析下，为了学习某些只在公司才能学到的东西，就非常有必要到大公司去一趟。

我大概率以后是不太可能再考虑坐班，所以这或许是我仅有为数不多的上班经历了。不过我想既便真正要开始打卡上班，要开始适应国内 996，未来我铁定会后悔有过这段历程。

![1703021156782.png](https://img.kuizuo.cn/202312250547469.png)

### 那么该怎么找呢？

那么在如今就业形势如此严峻的时代，我又该如何找工作？

关于这点我其实并没有什么很好的经验分享，这也算是我首次主动找工作。不过我可以肯定的一点是，只单靠海投与某些招聘软件，想要拿到一份心意的 offer 很难。若是能通过一些关系，牵一条线（走内推），才是最佳选择，所以多积攒人脉交际圈是很有必要的。

这一部分我想待我后续找到工作后，再来做个心得分享也不为迟。（不说了，我去准备项目与简历去了）

:::success 补

[记 · 在 AI 公司入职一个月的体验与感悟](/blog/experience-of-an-ai-company)

:::

## 远程工作

[电鸭](https://eleduck.com/)的sologen：**只工作，不上班**。很好表明远程工作的意图。

远程工作（remote work）是我当下认为最具性价比的工作形式，你可以过着四五线城市的生活水平而不用考虑一线城市的房租与消费，却赚取一线城市的薪资。往大点说就是挣美元花人民币。

但是远程工作并非多数人想的那么轻松的，很多人对远程工作有个误区，就是可以自由决定上班时间，很自由。其实不是的，不用上下班通勤，那就把通勤的时间拿来工作。没有额外房补开销，那就拿来压低工资。而该开的会还是得开，说白了就是换个地方上班，懒床是睡不了一点的，好一点的是冬天起来不用遭受寒风的洗礼罢了。

有的远程工作还会要求你记录每个时间段(细到每小时)你都做了哪些工作，我暑期的就有一份我老师推荐的远程工作(实习)就是这样，我就没干了。要论自由，接单/自由职业是最自由的，项目进度、时间都由你自己把握。

此外还有一点就是技术栈的因素。我并没有跟随国内的主流的 Web 开发技术栈去学习什么 Java，也庆幸还好当初认为 Java 这门语言繁琐的要死，让我转变使用 JS/TS 来进行 Web 全栈的开发，而如今的重心也是在 JS/TS。

而这套技术栈在国外的远程工作的岗位占比很大，一些初创公司也会采用这套技术栈。而我本身学的就是 JS/TS，自身优势反而更能体现出来。但反观在国内绝大多数公司我也就是老老实实做前端的那种。况且如果只想靠国内的主流传统的技术栈而去争取一个远程岗位，我认为当下还是很难实现的。就国内的职场环境下，如今工作都难找了，就别说本身岗位就少的远程工作了。

## 正常坐班

退而其次，那就正常上下班通勤，而这又有的抉择了。就以我自身举例把，我老家福建宁德且我在厦门某三流大学读书，意味着我只要在福建本地找工作，就可以过的相对来说舒服，人脉资源、衣食住行都不用过多考虑。但倘若选择在外打拼，意味着可能要适应陌生的城市生活，建立起新的人际网络，面对未知的困难和挑战。而这其中所能利用的、所要遭受的，都得由自个儿来承担。

今年冬至的时候我与家里人商讨过这个问题，家里人的意见更多偏向于留在本省，只求我稳稳当当，脚踏实地。因为我从小到大独立性很差，加上我确实有那么亿点宅，到外面恐怕是吃不消。所以在他们眼里哪怕在本省薪资不是令我那么满意，但至少可以过一种相对舒适的生活。而我自己则认为有必要去外面见见世面，有时候很多苦只有自己吃过才知道有苦。

不过最终如何选择，还得取决于我自己。这对于多数人也是值得花时间思考的。

最终如果选择重归故里，那么一开始就身在其中是否会更好？又何必在外漂泊，独自承受着一切。

### 我对打工/上班的看法

我经常拿我高考结束的那个暑假来做例子，我的一些高中同学去当外卖骑手、餐厅服务员，将他们的假期时间拿来打工赚钱，而我却埋头苦干的[学习编程(易语言)](/blog/2020-year-end-summary)，以兴趣驱使我学习一门技术。

或许是因为有过几段[赚钱经历](#赚钱经历)，加上家境和个人意愿，所以至今为止我都不可能会去从事这种回报率不高，或者说没有“未来”的工作。与其打工/上班，尤其是耗费大量时间与体力劳动的，不如将时间拿来提升自己综合能力。（个人观点，或许有些极端）

可能是由于受自由的影响加上年轻有精力折腾，同时自己又是那么不走”寻常路“、不遵循“规则”的人。所以像那种安稳平淡，重复劳动的工作，如体制/编制内的职业就不太那么感冒。

但从现实是没人想打工/上班，却依旧有人从事这些工作。绝大多数打工人别无选择，因生活所迫，只得忍受和抱怨打工/上班的痛苦，却又寄人篱下。

## 期望的工作

要说不工作是不可能的（但打工是不可能的），或许是因为这几年的一些工作经历有关，导致我有点习惯了远程，加上网间传闻 996 的压力下，我现在对坐班甚至还有些厌恶。对我最理想的工作环境就是能够自我在决定在某个时间点是否工作，例如在工作日放假，在节假日上班。

接单虽说也是，那这毕竟不是一份正经的工作，更多意义上来说是份兼职。更多是作为一时之需，接单又不可能接一辈子（搞得工作能工作一辈子似得）。

而我想说的是做个自由职业者，在细一点也就是独立开发者。但是现在来看这并非易事，不仅需要一定的技术能力和营销水平，最关键的想法就已经让绝大多数人对这份职业扼杀在摇篮中。

## 现状

首先我对自己的生活方式定义是：**偏向于自发的能量爆发，而不是有条理的持续努力。**

今年我的 github contributions 出现过了几次长时间的空缺，那段期间我基本上没有在写代码，而是将心思用在其他事情上。例如只打游戏（好在游戏如今也是戒了）、只想摆烂（好在是摆的有点多了）、只想复习（好在该考的试都已经考了）。**这就导致很多时候我会将全部精力专注在某件事情上，而抛弃其他与之无关的事情**。

这也就导致了我很难养成一个良好的习惯，我的生物钟也因此而发生巨变。贴一张极为离谱的作息

![Untitled](https://img.kuizuo.cn/202312250547470.png)

总之持之以恒在我这还不存在过，**多数的开始是因一腔热血，而最后结束时却草草了事**。

我想是是过度的自由造就了这般现状，想要解决这个问题，坐班可能还真可以。

---

或许是因为比同龄人提前踏入过社会，有过几段工作经验，所以在就业形势严峻的时代，其实我反倒不是那么慌张。

何况目前经济状态也还算正常，哪怕不找工作也足够养活我自己好一整子。至少相比同龄人下，我已经挺富裕了。也没必要搞个打赏在自己的网站或项目上放置收款二维码等无关项目信息。对我而言，编写这些的目的不是为了接某个单，赚个打赏费，更多是一时兴起，分享给有需要的人，希望让其更为纯粹一些，仅此而已。

我对赚钱的态度也很简单，悦己便可（做点让自己愉悦的事情），数额能够维持自身生存便足够了。不过现在我还没开始到还贷的境地，或许只有压迫感来临时，才会让我激起对金钱的渴望，改变对金钱的态度。

**取悦自己，生活最好的心态。**

## 感慨

接触 web 开发算下整整两年半的时间，在这期间我并没有很好地扩张自己的技术面。在折腾方面确实不如以往，学习主动性也欠缺许多。不同于一开始所学习那样，喜欢瞎捣鼓，看到某个东西就会想尝试安装。

明年也就 24 岁了，面对即将到来的本命年，下一个阶段的走向其实很迷茫，面对我的是留学还是工作，我到现在都没有定数…

虽说我现在大四还在读，但其实我已经比同龄人晚毕业 1-2 年了（此时怀着感慨的泪水不禁流下）。心智上还保留着校园少年的青雉 ，同时也多了份成熟的稳重。

有过这些经历让我收获了更为珍贵的经验和独特的成长路径，我想未来的日子必定是丰富多彩的。

## 往年回顾

- [2022 · 逆向到Web开发](/blog/2022-year-end-summary)
- [2021 · 休学一年](/blog/2021-year-end-summary)
- [2020 · 编程之旅-起点](/blog/2020-year-end-summary)

2023 · 谈谈职业规划

关于 restful api 想必不用多说，已经有很多文章都阐述过它的设计原则，但遵循这个原则可以让你的 API 接口更加规范吗？以下是我对 restful api 风格的一些思考🤔。



## 思考

此时不妨思考一个问题，现在以下几个接口，你会怎么去设计 url 路径？

- 查询文章
- 查看文章详情
- 创建文章
- 更新文章
- 删除文章
- 查看我的文章
- 查看他人的文章

前 5 个接口想必不难设计，这边就给出标准答案。

- 查询文章 `GET /articles`
- 查看某篇文章详情 `GET /articles/:id`
- 创建文章 `POST /articles/`
- 更新文章 `PUT /articles/:id`
- 删除文章 `DELETE /articles/:id`

当然，我相信肯定也有`GET /article—list` `POST /add-article` 这样的答案，不过这些不在 restful api 风格的范畴，就不考虑了。

而这时 查看我的文章 或许就需要稍加思考，或许你会有以下几种方式

- `GET /my-articles` 从资源角度来看肯定不好，因为此时在 url 不能很直观地体现请求资源，同时在控制器文件(controller) 就与 article 分离了，并且还占用了 / 下路径。
- `GET /articles/mine` 则又不那么遵循 restful api 风格，挺违和的。

那么这时不妨遵循 **资源从属关系**，在这里 文章所属的对象就用户，因此查看他人的文章可以这么设计`GET /users/:userId/articles` 获取特定用户（userId）的文章列表。

而 查看我的文章 同样也可用此 URL，只需将 userId 更改为自己的便可。从 api 的 URL 来看是很舒服了，但是从代码开发的角度上问题又有了问题了。。。

对于 user 资源，是不是也有查询，创建，更新，删除等接口，即 查询用户 `GET /users`，创建用户`POST /users/` 等等。。

我是不是就需要在 user 这么重要的资源控制器上去添加一些其他方法，所对应的代码就如下所示

```jsx
@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 资源进行解耦，有可以有比较清晰接口分类。

:::warning

不过针对这种情况我可能的解决办法是下会额外 **起一个别名**，例如 author，将 `/users/:id/articles`转为 `/authors/:id/articles`，不过在这里指向的是用户 id，而不是新建一个 author 实体（资源）。

这里的 id 会根据情况而定，假设业务中需要创建 author 实体的情况下，对 author（作者）这一身份有一些操作，如普通用户变成一个作者，获取所有作者，那么这么做就再适合不过了。

在比如说一个更鲜明的例子 商店(store) 与 商品(product)。

:::

业务再稍微复杂一下，现在要为业务增加以下几个功能，你又会如何设计

- 收藏他人文章
- 获取我收藏的文章

答案应该会有两种，即 `POST /articles/:articleId/collections` 与 `POST /collections`

而这就令我特别头疼，因为这两个都符合 restful api 风格，也确实都能很好的满足业务功能。于是在我尝试抓包拥有相关的网站后，我发现几乎都是后者的 url。后来一想，前者更像是获取某种资源，而不是用于创建资源。后者确实更能胜任多数场景，比如说现在我需要收藏某个专栏，那么我用 `POST /collections` 足以胜任，只需要传递 条目id与条目类型，后端根据这两个条件找到对应条目数据便可。假设后续业务多一个资源需要收藏也不成问题。但换做前者的话，就得再多写一个重复性接口。

## 抽象资源

restful 更多是针对实际存储的资源，核心是名词，对于增删改查的业务可以说非常适合，但现实情况下不只有增删改查，就例如上述的收藏功能。

对于一些个别接口需要另外表达，如 登录 `POST /login`、获取个人信息 `GET /profile`

对于一些非增删改查的操作，还是使用 RPC 式的 API 更为实在，即 **`POST /命名空间/资源类型/动作`**，至少不用再为某个操作决定 PATCH/PUT 还是 POST/DELETE。

## 针对同一实体，区分不同用户

问题还没结束，不妨碍继续使用上述文章的例子，针对 文章 这一实体，又要怎么定义（区分）用户与作者或管理员路径呢？

管理员所看到的数据肯定远比用户来的多，如果使用同一个接口（如 `/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，往往需要发送多条请求，例如获取某篇文章数据与作者数据

```
GET /articles/1

GET /articles/1/author
```

要么两条请求获取相应数据，要么为调用方“定制”一个接口，如`GET /getArticleInfo`，这样只需一条请求便可得到想要的数据。但这个就破坏了 restful API 接口风格，并且在复杂的业务中，比如说还要获取博文的评论等等，后端就要额外提供一个接口，可以说是非常繁琐了。相比之下 [GraphQL](https://graphql.org/) 就更为灵活了。

## 写到最后

在我写这篇文章之前，我尝试抓包看过很多网站的请求 url，见识到各式各样的 url 路径，基本上很难找到遵循 restful api 风格的网站，绝大多数的操作除了获取外用 GET，其余全用 POST 。对于复杂的业务，restful api 风格实在过于难以胜任。

如果说变量命名是编程最大的痛苦，那么写接口最大的痛苦我想就是定义 url 路径了。

## 相关文章

[RESTful API 对于同一实体，如何定义管理员和用户的路径？](https://www.v2ex.com/t/482682)

[RESTful API设计经验总结](https://blog.51cto.com/LiatscBookshelf/5427906)

[为什么很多后端写接口都不按照 restful 规范？](https://www.zhihu.com/question/438825740)

关于 restful api 路径定义的思考

核心命令

```bash
git remote set-url --add origin 远程仓库地址
```

如：`git remote set-url --add origin https://git.kuizuo.cn/kuizuo/blog.git`

此时打开 `.git/config`，可以看到这样的配置

```bash {4}
[remote "origin"]
 url = https://github.com/kuizuo/blog.git
 fetch = +refs/heads/*:refs/remotes/origin/*
 url = https://git.kuizuo.cn/kuizuo/blog.git
```

上述命令 git 配置添加新的 url 记录。也可手动添加、修改。

`git push origin --all` 推送至所有远程仓库