Mockline – 几秒钟内从 OpenAPI 规范启动实时模拟 API
1 分•作者: trillionclues•5 天前
大家好，我是 Excel，正在开发 Mockline，一个基于 OpenAPI 规范构建隔离的、由 Docker 驱动的模拟 API 服务器的工具。
问题：
每个迭代周期，我都会开始针对一个尚未存在的 API 进行开发。选择很糟糕：要么一直被阻塞，直到后端上线；要么针对硬编码的 JSON 进行开发，而一旦有任何改动，这些 JSON 就会漂移；或者维护一个本地模拟，但没人使用。
令人沮丧的是——规范通常是存在的，只是你无法运行它。我相信质量保证（QA）团队在编写针对尚未上线的端点的集成测试时也面临同样的挑战。而且这种情况持续的时间越长，测试就会越集中在迭代周期的最后 48 小时内。
Mockline 的作用：
上传一个 OpenAPI 3.0 规范（YAML/JSON 或远程 URL）。Mockline 构建一个内置了 Contour CLI（https://contour.trillionclues.dev）的 Docker 镜像，启动一个容器，并分配一个公共 URL——在 3-7 秒内提供带有真实 HTTP 响应的实时模拟服务器。
此外，每个模拟都针对每个规范版本进行隔离。您可以运行契约测试来验证模拟是否与规范匹配，并比较两个版本以在上线前发现破坏性更改。
目前已实现的功能：
* 规范上传和版本控制
* 模拟服务器配置公共 URL
* 启动/停止/删除控制
* 契约测试和模式差异
* 内置 API 客户端，可在仪表板中实时访问端点
说实话，我非常希望得到关于以下几点的反馈：
1. “上传规范，获取实时模拟” 这种抽象是否正确，还是团队更希望使用类似 Postman 的手动响应定义方式？
2. 您会在 CI 中使用它进行集成测试吗？3-7 秒的冷启动时间是否太慢？
3. 有人正在基于 gRPC 或 GraphQL 规范进行构建吗？这在路线图上，但我希望知道这是否确实是一个阻碍因素。
非常感谢任何反馈——尤其是来自质量保证工程师或任何尝试过以不同方式解决此问题的人。
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