Manjusaka

2025 年第十七周周报

这周没有拖延！

生活

1. 本周的状态
   1. 突发性的眩晕想吐，不知道咋回事
   2. 精神状态保持的还不错
2. 本周的娱乐时间
   1. 番剧清单
      1. 杂旅继续高走，节奏我很喜欢！很不错
      2. Summer Pocket 新一话感觉也还不错
      3. 阳光马达棒球场，我喜欢的味道
      4. 我小栗姐就是牛逼，初开就是奇迹之马
      5. mono 女孩，这周摇曳露营有客串，山梨宇宙参上
      6. 魔女与使魔很不错欸！开香槟
      7. 炎炎消防队第三季，这周停更了，我xxxxxx？
      8. 奥特曼定档了！好开！
   2. 这周开始捡起之前的种田文看了，感觉还不错
3. 家里的蔷薇开的好茂盛啊
4. 本周抓小区里的猫去做绝育.jpg
5. 本周继续背单词

技术

1. 这周在折腾 WAF + GraphQL， 简直麻了
   1. 这件事本质上的是协议状态与业务状态的交集的问题
   2. 传统以 RESTful 为代表的设计，选择了将业务状态尽可能的与 HTTP 协议的状态进行结合（即两者的交集更倾向于 HTTP 协议一侧），用 Path 表示不同的模型抽象，用 Method 表示业务的 Action，用 HTTP Status 表示业务的状态码。
   3. 而 GraphQL 是选择了更倾向于业务状态一侧。用自己抽象的 DSL 在 Body 中进行处理。毫无疑问这样会带来更强的业务建模与复杂操作能力
   4. 但是从 SRE 侧的视角来看，两种设计风格在流量治理上会带来很不一样的手段。
   5. 比如以 RESTful 为例，因为设计风格在交集中更倾向协议一侧。所以我们能够很方便的以 HTTP 协议的状态为基准，做很多操作。例如对 Per Path 的 RateLimit ，其实本质上也就是对不同业务模型操作的 RateLimit，而这一部分的操作可以做的非常前置（从 CDN 开始做）
   6. 而以 GraphQL 这样的设计思路，我们需要对 Body 做完整的解析才能提取出状态。这意味着我们的操作在整个生命周期中非常的后置。也会有额外的 Overhead
   7. 目前看可能需要用一些比较 trick 的手段比如在 URL 里加上 operationName 之类的方式来暴露一些信息给协议层
   8. 最好的手段是把 GraphQL 扬了
2. 这周给 CPython 的 Remote Debugging 修了一个问题，不得不感叹很多人还是忽略了 Fork 本身行为带来的副作用
3. 这周基于 Cursor 给 Picimpact 水了几个 PR，还是好用啊（
4. 水了一篇博客 https://www.manjusaka.blog/posts/2025/04/26/3-14-is-one-of-the-best-python-version/
5. 这周又是继续骂 Prisma 的一周，真的难用啊啊啊啊啊
6. 最近做稳定性提升，感觉又有一些新的东西可以聊
7. 这周继续刷题

总结

期待放51假期！