@SchwarzeR 哈哈哈哈，这个架势让我想起 Python 的前摇，和一般的前摇不一样

```
class FastAPI(Starlette):
"""
技能前摇开始
"""
开始施法
```


```
class BackgroundTasks(StarletteBackgroundTasks):
"""
A collection of background tasks that will be called after a response has been
sent to the client.

Read more about it in the
[FastAPI docs for Background Tasks]( https://fastapi.tiangolo.com/tutorial/background-tasks/).

## Example

```python
from fastapi import BackgroundTasks, FastAPI

app = FastAPI()


def write_notification(email: str, message=""):
with open("log.txt", mode="w") as email_file:
content = f"notification for {email}: {message}"
email_file.write(content)


@app.post("/send-notification/{email}")
async def send_notification(email: str, background_tasks: BackgroundTasks):
background_tasks.add_task(write_notification, email, message="some notification")
return {"message": "Notification sent in the background"}
```
"""

def add_task(
```

Java 还有专属技能前摇: XyzController - XyzService - XyzServiceImpl - XyzDao - XyzDTO

> 在客户端使用 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

@horizon 如果写代码不折腾，不有趣，就只剩下 996 了。
这是前端部分公共的内容 https://github.com/wenerme/wode/tree/main/packages/console
这是后端部分的公共内容 https://github.com/wenerme/wode/tree/main/packages/nestjs

这是一个假的 demo https://wode.vercel.app/console fake 的账号密码 admin admin

@p1gd0g 整理下发到了这里 https://v2ex.com/t/1067291

@p1gd0g 开发时间和精力有限，转 node 后速度快了很多，这里有心路历程 https://www.wener.tech/story/crm-trails

把以前的一些思路也汇总了，因为无法编辑了，贴在这里，原文 https://github.com/wenerme/wener/blob/master/story/2024/2024-07-18-how-i-note.md



# 我记录思考的方式简单总结

增加了一个

1. AWESOME 了解和整理一个领域的资源，能够快速找到一个领域的优秀资源
- 如果是企业，则需要了解竞争对手
- 例如 Kubernetes 相关 https://wener.me/notes/devops/kubernetes/awesome
- 例如 AI 相关 https://wener.me/notes/ai/ml/awesome

## 如何用记笔记来索引知识 {#how-i-indexing-my-knowdge-by-taking-notes}

> 2022-07-21 的一些思考

1. **工作** 是重复的任务 - Job is recurring work
2. **经验** 是解决重复问题的方案 - Experience is solution for recurring situation
3. **知识** 是重用经验 - Knowledge is about reusing experience
4. **记笔记** 是重用获取知识的时间 - Noting is about reusing time used to acquire the knowledge

要完成任务，只需了解一点点知识。知识是积累、演变和时间的结果，由小片段组成。条条大路通罗马，你必须找到自己的那条。

通过记笔记，首先做一组标记，然后深入挖掘，最终形成一个知识池。

**索引知识**

- 大脑容量有限（字面意义上的）
- 索引是为了直达重点
- 重点如：列表、表格、代码 这样的表现方式
- 记录内容是关于：上下文、背景、原因、关系、为什么、注意事项 等

重点可能非常简单，例如 Next.js 不支持 ESM ，这就足够做出决策。
但如果你想了解更多，你将花费更多时间得出结论，是的，它还没准备好，**但是...**。

不要浪费 5 分钟选择技术，使用你已经足够了解的无聊技术。

**Thoughts**

- **体系结构和设计** - 选择是关键，你最好了解它们。
- 不要在同一块石头上绊倒两次。
- 记笔记是为了自己，写文章和博客是为了别人阅读。
- 记笔记可以释放大脑压力，就像将思维分散到另一个地方。

记笔记是思考的反映，就像散点图，索引将其变成有向图，这是我们建模知识的方式。
写作就像绘画，试图在说服你一个观点，这个观点在在标题或第一段中已经提出，其余的文字都是在证明“我早就告诉过你了”。

正确写法是这样的

```
*.example.com {
tls {
dns <provider_name> [<params...>]
}

@foo host foo.example.com
handle @foo {
respond "Foo!"
}

@bar host bar.example.com
handle @bar {
respond "Bar!"
}

# Fallback for otherwise unhandled domains
handle {
abort
}
}
```

万万没想到

@SantuZ 谢谢，试了下，应该可以用视频方式标注，不过就是标注的 帧 数和生成的帧数不匹配