嗨，HN：
我创建Vayu是因为对当前API工具的状态感到沮丧。Postman已经变得臃肿，并且强制进行云同步，而像JMeter或k6这样的高性能工具往往缺乏良好的图形用户界面来进行快速调试。
Vayu试图填补这个空白。它是一个开源的、本地优先的API客户端（类似于Postman、Insomnia），其底层包含一个高性能的负载测试引擎（用C++20编写）。
关键技术决策：
- 侧车架构：用户界面使用Electron/React（为了可用性），但它会启动一个独立的C++守护进程（“引擎”）来处理实际的网络请求。
- 这使得用户界面在负载测试期间，即使引擎每秒处理数千个请求时，依然保持响应。
- 隐私：它是100%本地的。无需云同步，也不需要账户。
- 脚本：使用QuickJS进行测试脚本（兼容您已经熟悉的`pm.test`语法）。
我在Macbook Pro M3上本地测试过最高可达60k rps。
目前版本为v0.1.1。我有Windows、Linux和macOS的构建版本。（PS：macOS通过dmg文件运行需要一些额外步骤，可能需要找到解决方法）
我特别希望获得关于“引擎”性能和负载测试流程的开发者体验的反馈，同时希望开发者能帮助我改善用户界面。
代码库链接：[https://github.com/athrvk/vayu](https://github.com/athrvk/vayu)
返回首页
一周热榜
我一直遇到同样的烦恼：我想从脚本中上传一个文件，并仅仅获取一个链接——而不需要设置 S3 存储桶、身份验证流程或 SDK。
于是我构建了一个小服务和命令行工具来满足这个需求：
[https://storage.to](https://storage.to)
[https://github.com/ryanbadger/storage.to-cli](https://github.com/ryanbadger/storage.to-cli)
这个命令行工具负责繁重的工作（单次 PUT 与自动分块上传），所以思路非常简单：
```
storageto upload huge-file.zip
```
→ 会打印出一个可以传递给后续步骤的公共链接。
这个工具还处于早期阶段，故意设计得很简单：
- 匿名上传（尚未注册）
- 公共链接
- 命令行工具会自动将多个文件分组为一个集合
这个工具旨在快速、临时分享和脚本化工作流程，在设置存储桶感觉过于繁琐的情况下使用。
我发布这个内容主要是想确认它是否解决了一个实际的工作流程问题，或者大多数人是否已经有了更简洁的解决方案。
在你的类中采用成员的实现，并在C#中拥抱委托、组合优于继承以及混入风格的编码。
作者在此。之所以开发这个工具，是因为团队（包括我的团队）在CI/CD中不断与GCP认证作斗争。
谷歌为Firestore和Pub/Sub提供了模拟器，但没有为Secret Manager提供任何工具。我找到的唯一替代方案是一个基本的测试助手，只有18次提交，并且没有生产环境的关注。
这是一个生产级的实现，具有以下特点：
• 100% API覆盖（11/12个方法 - IAM故意省略，因为本地测试中没有认证）
• 双协议支持：原生gRPC + REST/HTTP
• 与官方GCP SDK兼容 - 只需将指向localhost而不是googleapis.com
• 所有变体的Docker镜像
• 90%以上的测试覆盖率
在安静发布的两个月内，有公司联系我，表示他们在生产CI/CD中使用该工具。我实现了他们的功能请求，并添加了完整的REST API支持。
最适合于：
• 封闭测试（无网络调用，确定性）
• 无需GCP凭证的CI/CD
• 无云成本的本地开发
我使用grpc-gateway来保持与GCP官方REST端点的语义兼容性 - 路径相同，JSON格式相同。
欢迎就实现、用例或与其他方法的比较提出问题。
GitHub: [https://github.com/blackwell-systems/gcp-secret-manager-emulator](https://github.com/blackwell-systems/gcp-secret-manager-emulator)
至少在过去半年里，我时常在思考软件工程的未来方向。关于我的业余项目，我现在使用Cursor/Claude Code来实现我的愿景（一个自2013年以来的数据库系统，作为在康斯坦茨大学项目的延续），进行我一直想做的大规模重构，但由于这将是一个耗时多年的重大工程，我一直没有动力去开始。如今，在人工智能代理的时代，这一切变得非常令人印象深刻，因为在很多情况下，确实存在非常重复的模式，此外还有一些我从未有时间（和技能？）自己解决的问题。当然，有时候测试没有意义，有时它们会出错（例如，宁愿删除测试或“简化”它们，而不是修复真正的生产代码问题……）。但另一方面，我在AI代理的帮助下构建了一个完整的前端（而我是一名后端工程师，一直以来都具备一些嵌入式软件工程的专业知识）。
话虽如此，每当我找到一些时间，我就能更高效地推进我的愿景（主要作为产品负责人兼架构师，而不是“手动”编写所有内容）。因此，我当然在想我们的工作在未来是否安全。我认为，你始终需要对代理进行严格指导，并在它们即将失控时立即制止，因此你必须具备高级软件工程师的技能；但另一方面，我相信小型高级工程师团队的效率可以比以往更高。因此，要么是未来你需要的软件工程师数量会减少，要么是你能够更快地交付产品，实施更多的创意，或者只是说新的创意可以比以前更高效地被探索——这意味着会有更多的小型初创公司？我真的不知道……