Mockline – 在几秒钟内根据 OpenAPI 规范生成实时模拟 API
嗨，HN，我是Excel——正在开发Mockline，这是一个从OpenAPI规范生成隔离的、基于Docker的模拟API服务器的工具。
问题：
每个冲刺开始时，我总是要在一个尚不存在的API上进行开发。可选方案很糟糕：要么等待后端发布，要么在硬编码的JSON上构建，而一旦有变动就会失效，或者维护一个本地的模拟，其他人根本不使用。
令人沮丧的是——规范通常是存在的，只是无法运行。我相信QA在编写集成测试时也会面临同样的挑战，因为他们要对一个尚未上线的端点进行测试。而这种情况持续的时间越长，测试就越会压缩到冲刺的最后48小时内。
Mockline的功能：
上传一个OpenAPI 3.0规范（YAML/JSON或远程URL）。Mockline会构建一个包含Contour CLI的Docker镜像（https://contour.trillionclues.dev），启动一个容器，并分配一个公共URL——在3到7秒内提供实时的模拟服务器和真实的HTTP响应。
此外，每个模拟都是针对特定规范版本进行隔离的。您可以运行合同测试以验证模拟是否与规范匹配，并对比两个版本以捕捉生产前的破坏性更改。
目前的进展：
> 规范上传和版本管理
> 模拟服务器提供公共URL
> 启动/停止/删除控制
> 合同测试和模式对比
> 仪表板内的API客户端实时访问端点
老实说，我非常希望能得到反馈：
1. “上传规范，获取实时模拟”这个抽象是否合适，还是团队更希望有Postman风格的手动响应定义？
2. 您会在CI中使用这个进行集成测试吗，还是3-7秒的冷启动对您来说太慢了？
3. 有没有人在针对gRPC或GraphQL规范进行开发？这在我们的路线图上，但我想知道这是否也是一个障碍。
非常感谢任何反馈——特别是来自QA工程师或任何尝试过其他解决方案的人。
mockline.xyz——等候名单在mockline.xyz/waitlist
查看原文
Hi HN, I'm Excel — building Mockline, a tool that provisions isolated, Docker-powered mock API servers from OpenAPI specs.<p>The problem:<p>Every sprint I'd start building against an API that didn't exist yet. The options were bad: remain blocked until the backend shipped, build against hardcoded JSON that drifts the moment something changes, or maintain a local mock nobody else was using.<p>The frustrating part — the spec usually exists, you just can't run it. I believe QAs hit the same challenge with writing integration tests against an endpoint that isn't live. And the longer this goes, the more testing gets compressed into the last 48 hours of a sprint.<p>What Mockline does:<p>Upload an OpenAPI 3.0 spec (YAML/JSON or remote URL). Mockline builds a Docker image with the Contour CLI baked in(https://contour.trillionclues.dev), spins up a container, and assigns a public URL — live mock server with real HTTP responses in 3-7 seconds.<p>Also each mock is isolated per spec version. You can run contract tests to validate the mock matches the spec, and diff two versions to catch breaking changes before production.<p>What's working:<p>> Spec upload and versioning<p>> Mock server provisioning public URLs<p>> Start/stop/delete controls<p>> Contract testing and schema diffing
> In-dashboard API client to hit endpoints in real time<p>Honestly, I'd genuinely love feedback on<p>1. Is "upload spec, get live mock" the right abstraction, or do teams want Postman-style manual response definition?<p>2. Would you use this for integration testing in CI, or is a
3-7s cold start too slow for that?<p>3. Anyone building against gRPC or GraphQL specs? That's on the roadmap but I want to know if it's actually a blocker too.<p>Would genuinely appreciate any feedback — especially from QA engineers or anyone who's tried to solve this a different way.<p>mockline.xyz — waitlist at mockline.xyz/waitlist