EotalkVol。01Eoapi，我们希望以开源的方式构建

　　Eotalk是由Eolink发起的泛技术聊天活动，每期会邀请一些技术圈内的大牛聊聊天，聊些关于技术、创业工作、投融资等热点话题。
　　第一期，由Eoapi的核心开发者秦圆圆和EolinkCEO刘昊臻来聊聊，并分享开源产品Eoapi，以开源的方式构建API生态系统。
　　刘昊臻：是否能够一句话介绍一下Eoapi是做什么的？他目前实现的功能有哪些？什么样的用户会适合使用Eoapi？
　　秦圆圆：Eoapi是一个API生态系统。目前它支持基础的API文档管理和API调试，以及插件系统，用户可以通过插件简化和API相关的各种工作。当然现在的功能还比较弱，项目刚起步，从立项到今天8个月，正式发布才3个月。即使是未来也不会无限制地加功能，Eoapi的重点会放在生态建立上，所以我们会花比较多时间在拓展上，系统只做基础的核心功能，通过增加系统的可拓展点来让插件系统越来越强。总之就是就是保证核心基础功能的易用性，通过插件系统和社区一起共建生态。
　　刘昊臻：开发者能通过Eoapi做些什么事情？
　　秦圆圆：用户可以在Eoapi上托管自己平台的API，并对API进行调试，研发团队日常工作和API相关的工作都可以在Eoapi上进行。我们还会去通过拓展插件，像使用其他的API的网关或者像JMeter之类的工具进行测试时，我们会发布一些插件，帮助用户把API信息直接同步到网关，就不需要用户在网关上手写一些API信息，从而实现用户在Eoapi中托管的信息与其他平台信息之间的联通。
　　刘昊臻：所以，它其实是一个偏API的管理和测试的工具，是吗？
　　秦圆圆：是的，它的基础功能是这样的，也有其他与插件相关功能，还会有一些和其他产品合作的一些周边的功能的生态。
　　刘昊臻：所以我们从用户的角度来理解，Eoapi是一款带有文档管理，API测试等核心功能的工具外，用户还可以通过插件去拓展Eoapi的功能。比如我们可以把在Eoapi上管理好的API信息直接发布到API网关来完成发布工作，是这样子吗？
　　秦圆圆：是，然后比如现在很流行的低代码平台，我们在低代码平台中拖拉拽组件的时候，它虽然是一些UI上的工作，但实际上背后还是需要调用API。所以这时候低代码平台就需要获取一些API信息，再形成整个页面对接的过程。低代码平台的这些API信息就可以从我们平台获取，并通过插件来实现。我们甚至可以通过一条信息再加一个生成代码的插件，测试人员就能通过API生成测试代码来减少他们写测试代码的成本。基本上你能想到的市面上的与API相关的功能，只要我们的拓展足够强，它都可以集成在我们Eoapi上。
　　刘昊臻：目前市面上有许多免费或开源的API管理或者测试产品，比如我们公司Eolink也是提供了API的管理和测试功能，还有像Postman、Swagger、Jmeter、YAPI、RAP等，为什么圆圆你还想要做一个API产品呢？从产品定位、功能特性上会有什么不一样的么？Eoapi有什么亮点能吸引用户？
　　秦圆圆：首先用户群体不一样，Eolink本身功能是很强，但同时也比较复杂，支持复杂的权限和各种深度功能，不适合个人开发者，也不适合轻量级团队，比如35个人的开发团队，其实他们用不到那么深的功能，所以开源产品可以满足这部分开发人员的需求。
　　再加上考虑到API信息在很多团队是属于比较秘密信息，有安全性要求。所以蛮多团队是要求不能将API托管在SasS产品上，希望自己部署API工具，我们开放了源码，同时数据托管在自己的平台，所以使用开源可以自己管理API数据，同时源码完全开放不会担心安全性。
　　Postman、Swagger偏单点垂直的工具，我们希望以API信息为核心，能够通过插件的方式把整个流程多种工具串联起来，和其他产品相比的话，目前功能的确比较弱，但是也能覆盖基本的，像文档、快速测试的产品，而且本身轻量级产品用不了很深的功能，这个功能强度还是足够的，当然我们会不断地强化功能。
　　当然，最重要的区别是Eoapi目前是以插件生态为主的，我们会更加希望构建生态，Eolink后续也会有这种生态，开源上面的插件也可以拓展到Eolink上，所以这个是定位上的区别。
　　功能上，我们希望将体验、易用性做到极致，像Postman、Swagger功能越来越多，而且越来越复杂了，这也是用户主要吐槽的点。
　　刘昊臻：Eoapi和Eolink的产品之间是什么关系呢（或定位有什么差异）？是否会担心Eoapi会抢走部分Eolink的用户？
　　秦圆圆：我觉得是一个互补的关系，Eolink本身覆盖了需求更深的企业，Eoapi满足小微型团队的需求。首先目标用户定位是不同的。其次抢走也是正常的事情，而且未来一切都说不准，我觉得我们会更加关注怎么为用户提供更大的用户价值，所以未来是竞争关系也说不准，团队里面有竞争也是好事情，会让产品更加有生命力。
　　刘昊臻：Eoapi在开发过程中是否有一些技术难点？（比如插件系统）你们是怎么解决的？
　　秦圆圆：其实蛮多的，从一开始我们内部的技术栈和开源用的技术栈是不一样的，所以会涉及到技术栈与架构升级的东西，然后API调试的功能需要剖析整个HTTP协议调用层面的流程和细节，是一些库没有办法提供的，扎实的又上了一门计算机网络课。
　　不过印象中最难的主要是两点：插件系统的设计和实现；数据库代码统一。
　　先说插件系统的难点在哪。说一下概念，插件是一种运行在特定平台拓展平台原有功能的程序，就像游戏世界里的游戏装备，提高额外的力量属性之类的加成，但是必须要穿在你身上才有用。
　　那我穿个装备把人穿没了，是不是很不合理？所以插件系统可能就会有这样的问题，因为加入了插件系统其实是加入了一种新的角色，插件开发者，可能是官方、也可能是企业，所以代码你没有办法完全掌控。
　　如果你插件系统隔离做得不好，装个插件导致应用崩或者拖慢应用速度的情况比比皆是，就算是windows系统迭代演变那么多年了，有些程序卡了你电脑还是会崩，所以做好插件和主系统的隔离是一个难点。
　　若隔离系统隔离得太好了，那么用户能拓展的一些工具或者功能就会受限，若隔离不好则会影响到原有的核心系统得运行。所以这里也需要有一个平衡，针对不同的需求和应用系统来提供不同的功能点。除此之外还有要考虑设计那些hook，插件API的权限控制，根据不同的运行环境比如Web、桌面端或者是Node这些运行环境提供不同的API，插件的生命周期与界面的UI怎么统一，以及插件之间复用的资源滥加载等等问题。
　　第二个问题就是数据库代码的统一。数据库代码统一是因为开源既支持单机数据库也就是本地数据源indexeddb，也支持远程数据源Mysql，所以为了兼容不同的数据库语法，同一个逻辑我们可能要写两种形式的代码，我们不想在重复的工作上浪费时间。
　　所以我们是通过自己定义了一套DSL，然后通过编译手段将DSL生成两套数据库API，这个主要不是我负责实现的，所以感兴趣可以在Github的Discussion和我们交流。
　　刘昊臻：怎么解决？
　　秦圆圆：在加入这个项目之前，我就有好几年的浏览器插件开发经验，所以站在使用者的角度对插件系统的要素还是比较了解的，相关设计的需求制定首先没有问题，其他成员也有插件开发的经验。
　　我们用的语言是Javascript嘛，所以可以参考的是市面上成熟的插件系统设计，比如用Electron开发的VSCode插件系统，Web技术实现插件的Chrome浏览器，可以通过阅读源码、官方文档吸收他们的设计经验，再权衡后结合我们的需求融合到我们插件系统的设计中。
　　除此之外我们还参考了qiankun的微前端设计，插件系统中遇到的一些问题微前端也会遇到，例如代码隔离简单粗暴用iframe还是electron的browserview，多应用多插件的怎么加载等等。
　　目前我们花了半年时间去研究它，但还有很多问题我们是还在解决的，比如代码隔离，我们并没有隔离得很好，插件之间的通信方式等等都是还要继续完善的。
　　刘昊臻：Eoapi接下来半年的迭代计划是什么？
　　秦圆圆：我们会加入一些前后置脚本可以让API测试这个功能更强，同时我们会支持API多协议，后续我们会支Websocket、TCP、UDP、GraphQL等等，让我们后续可以更好地对接各个平台或者应用。打磨核心功能，提高易用性。
　　第二个迭代方向是国际化，我们希望面向全世界所有的开发者，扩大用户群体，这样有利于共建生态，在这个涉及到文化、创新、技术、经济、政治等等诸多的因素，之前主要做国内的产品，所以国际化是一个尝试也是一个挑战。
　　最重要的当然是逐渐完善插件生态，一个是通过暴露更多的核心系统API，提供官方插件。最后是寻找用户迫切的需求和一些痛点，打通应用，和其他厂商合作开发插件。
　　刘昊臻：你对Eoapi未来的展望是什么？比如我们分别想象1年后、3年后、5年后的Eoapi，它可以为大家带来什么价值？
　　秦圆圆：我们发现市面上很多和API相关产品是没法直接对接的，我们希望能够让比如说：研发团队的API信息可以和测试团队打通，和你的网关打通或者说你的防火墙，或者说你的拖拉拽的低代码平台的组件的对接来自我们平台的API信息，或者说直接通过API可以生成调用代码、测试代码等等。
　　在这个API工具的上下游可以做很多东西，但是我们不可能在一个产品里面集合所有功能，所以这个东西在目前市面上比较少见或者说压根没有。
　　我们希望有种共同的语言，共同的环境能够把系统内部任意两个或多个应用连接起来，让他们连接起来的载体就是API信息，站在这个角度来看，我们能不能做一个API信息这种开源产品，同时又能形成一个生态系统，基于这样我们发散开来会觉得说我们做一个拥有比较强大插件功能同时又管理基础API信息的东西就可能实现这个，因此我们觉得做这样的尝试是有益的。
　　而且我们会发现技术，尤其是计算机相关的都是集众家之长，通过开放不断发展而来的，在这个领域里保持封闭的那些，都没有经过市场的洗礼，就消失在了历史的舞台上。
　　有人说你只是一个软件项目，只是一个工具，为什么可以称之为生态？工具只是一个生态的载体，生态不只是产品的代码，还包括用户、开发者、社区等等为这个产品源源不断创造价值的实体，都是生态的一环。所以无论是1年、3年、还是5年，我们的终极目标就要打造一个API生态系统，你让我看到很远的东西，我说实话我看不到，只能相信判断，相信开放是未来的趋势，相信合作而不是封闭能够创造更大的用户价值；
　　3、5年后，我希望Eoapi能够成为一个生态系统，上面有各式各样的插件，打通所有和API有关的工具链，不再寄希望于一个产品解决所有问题，而这一切都是由前端的业务代码Javascript实现的；
　　3、5年后，我希望Eoapi不只是我们团队在维护，会遇到互联网各行各业的用户、各个国家的贡献者、与不同的团队合作开发插件，希望有没有我们，生态都仍然可持续。生态系统传递的是能量，我希望API信息就是我们API工具生态系统中的能量。
　　刘昊臻：如果社区和第三方开发者可以参与进来，你觉得大家可以提供的帮助有什么？以及他们怎么参与进来？
　　秦圆圆：开源其实就是一种公开透明的协作方式，对于为开源做贡献常见的误解就是：为开源做贡献必须得提交代码。事实上，但一个开源项目能够运转发挥大价值从来就不仅仅只有代码，代码当然重要，但项目中有很多不需要编码的重要部分，做这些也一样是超棒的贡献，集自己的长处帮助社区。
　　如果你是我们的用户，对产品有独到的见解，那你可以提Issue反馈Bug或者提产品的建议，这里提一下我的理念。在Issue上有个label叫goodfirstissue，可以先从这个标签关联的Issue开启你的第一次代码贡献。
　　开发插件当然也算是一种代码贡献，比如之前有用户就提了他的场景是希望可以导入Curl变成API文档，我们没多久就支持用户可以自己开发导入插件。
　　如果你热爱写作，还可以在完善官方文档，在社区描述产品以及产品的功能等等，还有一些社区推广，这些都是我们希望得到的贡献，我觉得为开源贡献力量得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。
　　刘昊臻：能否介绍一下Eoapi开源产品的历程，帮助其他想要做开源产品的团队了解如何从零到一逐步做起来，其中又有什么值得特别关注的点？
　　秦圆圆：
　　关于立项：产品定位解决哪些用户的问题；定项目名称，最好不要重复，公司的项目还不能侵权别人的商标；你想要在国内还是国际发布，提前准备域名建立官网，当然直接使用Githubpages也是可以的；项目选什么License，Apache还是GPL还是超灵活的MIT；在哪个平台开源Github还是Gitee。
　　关于组建团队：招聘：技术过硬是基本需求，有开放的心态、有一定文字功底会更好地胜任开源工作；组建开发者关系部（布道师，文字工作者等）；选协作工具，定协作的流程，开源团队的氛围相对业务团队来说决策会比较自由、开放。
　　关于代码流程上考虑：补充社区规范；代码合规；发布频率发布策略，例如版本号用什么规范，发布版本需要beta；CICD流程。
　　关于怎么运营：
　　有时候我们会有种观念，觉得酒香不怕巷子深，这是没问题的，但是你如果能做到巷子不那么深，酒不就能让更多人喝到了吗？
　　不是说我为了运营我就不弄产品了，运营和做产品一样重要，相辅相成，只是我们在不同的阶段运营的侧重点不一样。开源因为面向的是开发者，所以他的手段可能和C端的不一样，我这里不说具体的方法，因为我也不算专业的，所以就讲两个小故事，来表达我对开源运营的看法。就是说某个开源项目A（不点名怕得罪人哈哈）在线下举办活动的时候拉了微信群，参加活动的人进群后，项目运营的小伙伴告诉大家点个star就可以领取奖品，被骂惨了；又有某个开源项目发起了一个叫灭虫计划的活动，就是将项目里面某些简单的Bug释放出来让大家修复，其实我一开始听的时候也没什么感觉，就像Github本身也有goodfirstissue，但还是引起争议了，因为有人发现这个活动其实对于软件质量、贡献者水平提升的收益不大，目的指向了Issue和贡献者的数量，为了追求数量刷出来的Issue甚至降低了开发效率，比较形式主义。
　　这两件事让我觉得我们在做运营的时候，首先要了解开发者团队，不要功利地刷数据，不要感动自己，做影响力而不是使用营销手段做运营，更多是传递我们的产品能帮助用户解决什么样的问题，关注产品价值和用户价值。
　　刘昊臻：因为开源团队里还有蛮多其他成员，可以麻烦你介绍一下目前的开源团队成员么？他们各自在团队内的分工，他们的特质，以及你最欣赏大家的点是什么？
　　秦圆圆：其实我们开源团队主要有三个人，我githubscarqin，kungfuboy俊杰，buqiyuan小缘。
　　Scarqin主要负责开发、运营和产品设计，偏重产品设计。
　　Kungfuboy俊杰主要负责的是技术架构、插件核心系统开发、官方插件开发，在技术上他会经常从系统的角度给我们分享如何划分逻辑，以及善用工具解决工程系问题。他的座右铭是将机器编程进行到底，卷死人类，日常喜欢用编译手段开发小工具提效，基本上每次团队分享别人都是讲和前端、工程有关的内容，而他的主题不是机器编程，就是在机器编程的路上。我最欣赏他对于技术的热情以及对于解放人类手动编程事业的执着追求，对了，还做得一手好ppt。
　　buqiyuan小源，主要负责组件库、业务功能开发，他是我们中最年轻的人，也是最晚加入团队的贡献者，面试时我就知道他有个开源项目比目前Eoapistar数还要多的组件库项目。他是属于除了沟通技术之外就基本上很少说话的人，一开始开口的时候也会紧张，我们刚开始交流还担心表达有问题，直到我看到了他的第一份文档，逻辑十分清晰，我相信能写这样一份的人表达和理解肯定是没有问题的，就是不爱说话罢了。
　　我自认在他这个年纪，并没有在业余时间那么积极地参加开源项目，所以我最欣赏对贡献社区的热情，是个内心有自己的小宇宙的人。因为我是技术转产品嘛，所以也有很多东西在学习中，其实他们给了我很大的支持，原型图画的不好全靠脑补。之前是远程现在我们在同一个小办公室，经常讨论技术、用户场景、产品等等，我们还会一起写官方文档，回复issue和用户交流等等。
　　感觉就像是一个并肩作战的突击小队，我喜欢和他们交流技术，分享产品设计心得，办公室还会堆很多小零食饿了就一起吃，我非常享受这样的氛围。
　　刘昊臻：开源团队最开始是完全远程协作的，直到最近才见面，因为其实能够真正实现远程办公的的远程协作团队并不多，能否介绍一下你们是如何进行远程协作的，并且其中踩过什么坑、如何解决等？
　　秦圆圆：我觉得其实远程办公和线下协作的很多问题都是共通的，只是远程办公将问题放大了。所以我相信如果能做好远程，也一定可以做好线下的工作的。
　　首先要提前规划好Roadmap，产品计划。让大家都知道我们这个阶段最重要的事情是什么。因为每个人都有很多工作在做，开源里不只是要做代码开发，可能还要写文档回复客户问题等等，所以我们每个阶段会有一个很重要的内容时间点，只要在那个时间点内完成相应的工作，其他的工作自己去安排发挥，提前规划好Roadmap和产品计划。我们还需要以各种文档为基础的协作，提前写技术方案预估时间，完成后归档相关文档以便其他成员理解。保持开放，有问题及时沟通，以及每周固定时间周会，明确Roadmap，沟通进度等等。公开透明是良好协作的基石。
　　刘昊臻：你从一个跟着产品需求来做迭代的工程师角色，转变成一个既要负责思考产品，又要做开发，还需要带领团队的角色，在这个过程中，你觉得从工作内容、心态、能力等方面有什么改变么？
　　秦圆圆：之前做开发主要是按照需求的迭代走，其实大部分工作是自己可以自己独立完成，进度能自己控制。带团队后你会做很多协调大家更好地工作的事情，比如任务分配、跟进和其他团队沟通协调资源、团队成长等等。
　　其实有些事情蛮琐碎的，但是可能不得不做，从一开始的手忙脚乱，到现在起码在我心目中是及格了。在工作内容上的最大变化是写代码的时间变少了，其实我自己真的很享受写代码的时间，我很喜欢一部电影叫心灵奇旅，里面提到一个心理学概念叫心流，心灵的心流水的流，进入心流模式的人就进入了自己的沉浸世界，极度专注。
　　自己个人技能多了很多，学会了原型设计、如何写文案、运营的知识、和各种团队的人协调合作等等，感觉做产品就是要成为一个全能的人，所以未来还有很多知识要学习
　　刘昊臻：在这个转变过程中，你觉得遇到最大的问题是什么？是怎么解决的？
　　秦圆圆：之前是任务导向，现在变成目标导向。所以一开始会做很多不是自己擅长的问题，所以第一反应是为什么是我，太难了，我做不了，拒绝、排斥、沮丧。
　　现在想的是我到底要怎么做才能实现，要找谁做，缺什么，我怎么才能获得这些资源。这种变化不是一时之间的，而是渐进的，可能过去容易沉溺在舒适区，其实只要走出第一步建立自信，后续的工作都会容易很多。不再被动的判断一个任务是否合理，能做才做，而且觉得自己有主动权可以去处理这个任务。
　　当然也不要逞强，明明做不好还要硬着头皮接，接了就尽全力去做就好了，确实不行，及时承认自己做不到也是一种勇气。
　　刘昊臻：最后，麻烦对eotalk的朋友做个寄语吧。
　　秦圆圆：感谢大家参加今天的分享，我觉得开源就是一种协作方式，让你随时随地地参与你感兴趣并愿意为之投入的项目，遇见那些和你志趣相投之人，从帮助他人中收获成就感和快乐，我一直觉得我从开源项目中得到的收获的远大于我的贡献。希望未来能够在开源世界里与再次与大家相遇，一起共建API生态。