在ApiCat发布前，他的前身产品已经运行了两年多了，事情要从我就职的上一家公司说起。当时我负责公司一款产品，在最初开发这款产品的时候只有Android版，产品试水成功后陆续开发了iOS和Web版，之后产品就开始快速的迭代更新，服务的用户也越来越多。没过多久我们就开始遇到了一些问题，服务端API的数量越来越多，API文档的更新维护成本越来越高。开发客户端的同学也需要从逐渐庞大的API文档中去寻找自己要用到的API，这让维护和阅读API文档的同学都开始痛苦起来。
我们当时API文档是写在Gitlab的wiki里，markdown文档，每次新增API就在文档后面追加API文档，Copy一下前面文档的内容过来，格式不变，内容一修改，新的API文档就完成了。随着产品不断迭代，一些问题就逐渐暴露出来了。例如：在某些接口中，用户的联系电话这个参数我们定义为mobile，但是之后新增的其他接口中也用到了联系电话这样的参数，由于已经忘了之前的接口内容，新的接口将参数名称定义为了phone，这样就导致我们一些接口联系电话的参数名称是mobile，一些又是phone，没有个统一的定义。我们就幻想文档可以定义全局的公共参数，在接口中可以引用。
还有这种情况，我们有一些参数在很多接口中都会用到，比如type参数是一个整型的参数，1表示时间、2表示金额、3表示次数等等。每当新增一个type类型的时候，所有用到type这个参数的接口都需要更新，需要将参数描述更新到最新，否则就会引出Bug。
还有这种问题，由于我们的客户端有APP，当用户下载安装后很多用户不会及时更新APP的版本，就会有很多老版本的APP在运行着，但服务端接口在迭代更新，随着版本迭代会增加一些请求或返回参数，这些接口同时兼容着新老APP，但这个接口对应的文档是最新最全的，有时候上线发布后发现老版本的用户受到了影响，在用户不升级的情况下我们需要在服务端debug对应的接口去修复用户的问题，这时候查看的文档是最新的，我们没有办法像坐时光机一样回到半年前或一年前去看当时的接口长什么样子。在你眼前的只是一篇最新3.0版本的文档，然而2.0版本的文档早已随着产品迭代修改掉了。如果让开发同学每次在接口发生变化就新建一篇文档打上版本tag，这无疑是一场噩梦，一段时间后同一个接口有多个版本的文档，开发同学再也不想维护了。我们需要文档只用维护一份，同时能够在固定的时间点打上tag进行归档，然后可以继续更新下去，当需要回顾历史文档时，可以快速回到当时的版本下查阅文档。
还有很多各种各样的问题，我相信在产品年复一年不断迭代过程中，大家多多少少都会遇到一些问题。后来我们的API数量突破了300+，文档的问题已经严重影响了我们的开发效率，为了效率的提升，必须要解决掉这个问题了。于是我就去试用了一些API文档相关的产品，有开源产品也有商业产品，但效果都不太理想，基本上都只能解决我们一部分问题，剩下一部分是没办法解决的。于是我动了造轮子的念头，后来就写了一个简陋的版本便开始使用了，自己给自己提需求，自己再写代码实现功能。后面虽然大家效率有了提升，但并没有达到我内心的预期，由于当时负责多项事情，精力很难照顾到这款产品。在我19年初离职后，就再也没有继续开发过这款产品，但这个躁动的心却一直没有停下。我曾在18年底找过自己团队的伙伴想一起把这款产品做好后开源出来，但由于一些列的原因最终并没能实现。
离职后做了大半年的自由职业，做了一些项目，有图像识别相关的，有旅游社交相关的，低效对接开发过程让我重新想设计一款API文档管理软件，于是我在19年底的时候找了曾经团队的伙伴表达了我的想法，告诉他我想怎样把这款API管理软件做成一个商业化的SaaS，之后我们就决定冒险一试。
原本我打算20年初就开始注册公司着手做这件事情，结果疫情来了，直到3月份复工后我才将公司注册下来，于是逆流而上，开始了ApiCat的旅程。
欲知后事如何，请听下回分解。写到这里已经挺晚了，作为一个又要做产品又要做项目的穷困企业创始人，这时候该去补觉了，有了好精力，才能做出好产品，服务好用户。
网友评论