wenerme

> 在客户端使用 KDF

那不等同于数据库存储的是 plain 的密码了么？如果数据泄漏，那么客户端直接 post 到获取到的 hash 就能匹配对 password 了。如果想增加客户端的 PoW ，那不如引入专门的 captcha 来做。

@xiaoshan5733

> 在做技术选型时一般会考虑哪些因素呢？

先做个方面了解，逐步筛选，锚定一些核心的，再围绕核心的技术去做选择。
一般我们说单有了锤子，看什么都是钉子。
然后再增加不同领域的锤子，逐步叠加就好。

例如数据库，刚开始的时候，数据库都是 mysql ，后来自己能做决定了，开始去了解，了解到 pg ，发现真的很不错。然后需要做分析的时候，也了解了一些例如 clickhouse 之类的等等，但是最终要得到一个 **trade off**，每个技术方向都是有价值的，但是做技术选择是有自己的背景的，多积累这样的 trade off ，会帮助之后做选择。
因此大约在 pg 10 用到了现在 15 、16 ，当需要 OLAP 场景的时候，也尝试通过 pg 解决，当需要搜索，需要做 AI/向量搜索，也是在通过 pg 解决。这里锚定的点就是 pg ，锚定了这个基本点后，可以更加深入的去使用 pg 的一些功能，例如我不会介意直接在 pg 里写 js （用 pg v8 ）。

例如 OS ，选择了 alpine ，之后 os 相关的场景 物理机、镜像、容器等 全都是 alpine ，得到的回报值得投入。
前端后端之类的同理，只是这些领域锚定的内容可能还会有变化，例如前端一开始 antd ，然后变为 tw 。后端确定 nodejs 后，一开始 nestjs rest 然后 gql 反复，但最终能 settle down 到一些固定的技术栈。这些也都是自己的技术投资，非常乐意沟通和分享这些内容。

这些核心的点是不会变的，但是围绕这些点的技术是会不断发展的，新的的东西也在不断涌现，保持好奇和兴趣，从 程序员 变为 工程师。搞这些真的好玩 😄。

到现在，原意分享，帮助别人去用 alpine 、pg 这些也是一种乐趣，非常有意思。

@horizon

> 你这个仓库挺难看懂的。。。说实话

是的，因为主要是面向自己的，想要 to public ，需要做的事情就太多了，只是分享一些想法和思路。

@ixixi

> 我也写过 crm 你们卖的咋样

没有成行的产品，都是内部用，然后我这边是以研发为主，crm 在用，但同时这套逻辑做了另外两个简单系统的后台，都不是 crm 的。

@mark2025

> 确定了要先 GRPC 的方式开发
> ========
> 为啥呢？

因为当时很 buy in buf[1] 那一套, 其实现在也还是能接受，如果是需要 rpc/server to server ，我还是可能会考虑 grpc ，或者实现一个简单的 rpc ，但目前减少了 server to server 这一层，部分逻辑还是保留，目前以 gql 直接暴露给前端为主。


[1]: https://github.com/bufbuild/buf

@raphaelsoul

> 产品优先 出活优先

和

> 行业铁律“过早优化是原罪”，技术是为产品服务的，技术层面花里胡哨产品却不好好设计，最终就是被市场淘汰。

这样的论调都是类似的，都是站在公司的角度，而不是个人的角度。我觉得两者是相辅相成的。

@qsnow6 有道理，但是被市场淘汰的是企业、公司，而不是折腾技术的个人，不折腾技术的个人反而会被行业淘汰。如果有公费折腾的机会，就应该好好利用。

@C0dEr

> 但能不能至少给个架构，功能说明啥的，方便理解先？

我的仓库里大多都是笔记性质的 https://wener.me/story/how-i-note / https://www.v2ex.com/t/1058208#reply2
我一般用笔记来索引这些信息。

> 架构，功能

一般我会以总结的方式形成类似 Design XXX 这样的，design 目录下有不少这样的内容，我一般主要参考学习别人现有的，然后总结沉淀自己的。

https://wener.me/notes/dev/design/schema
https://wener.me/notes/dev/design/erp
https://wener.me/notes/dev/design/ao-factory

@sunchuo

> 看下来感觉 op 是想后端尽可能少写代码，前后端尽可能少的重复劳动。所以一开始朝着 lowcode 方向走了。
我做过几乎一样的事情。

是这样的，但 lowcode 根本不可满足业务需求，只能通过大量的代码定义去减少重复的工作内容。

例如

```ts
export const LeadResource = defineResource({
name: 'Lead',
idType: 'lead',
title: '线索',
icon: <ActiveToggleIcon icon={BsTelephone} iconActive={BsTelephoneFill} />,
metadata: {},
});
```

这样能通过扩展和维护这个 Resource 构建大多元素，例如

```ts
defineMetadata(LeadResource, ResourceListViewSelectorMetaKey, {
views: [
{
label: '开放线索',
value: 'open',
query: {
filters: [`state = "${LeadStatusType.state.Open}"`],
},
},
],
});
```


不少内容和你的实现都有类似的地方，比较有意思, 只不过我大方向选择的 GQL 。

但我会尽量避免生成，而是通过动态去创建，目前主要用到生成的是 ts 的 interface 生成 zod 、typebox （ jsonschema ，但是有类型）。

> 但我会尽量避免生成，而是通过动态去创建

主要是方便修改复用，生成时怕的是生成后改不动会形成包袱。动态构建例如

```ts
export function createListPayload<T extends object>(Type: Constructor<T>): Constructor<PageResponse<T>> {
let name = getObjectName(Type);
let key = `${name}ListPayload`;
return computeIfAbsent(getTypeCache(), key, () => {
@ObjectType(key)
class ListPayload {
@Field((type) => Int)
total!: number;
@Field((type) => [Type])
data!: T[];
}

return ListPayload;
});
}
```

对查询方法也适用，可以按需增加查询方法，例如 https://github.com/wenerme/wode/blob/f846c2158ff83ad7fcde781abd29ef7505f11258/packages/nestjs/src/type-graphql/resource/withBaseQuery.ts#L11