Eotalk 是由 Eolink 發起的泛技術聊天活動，每期會邀請一些技術圈內的大牛聊聊天，聊些關于技術、創業作業、投融資等熱點話題，
第一期，由 Eoapi 的核心開發者秦圓圓和 Eolink CEO 劉昊臻來聊聊，并分享開源產品 Eoapi，以開源的方式構建 API 生態系統 ，
以下為演講內容：
劉昊臻： 簡單介紹一下自己吧，
秦圓圓：大家好我叫秦圓圓，目前在負責 Eoapi 的核心開發作業，
劉昊臻： 是否能夠一句話介紹一下 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 本身功能是很強，但同時也比較復雜，支持復雜的權限和各種深度功能，不適合個人開發者，也不適合輕量級團隊，比如 3-5 個人的開發團隊，其實他們用不到那么深的功能，所以開源產品可以滿足這部分開發人員的需求，
再加上考慮到 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 叫 good first issue，可以先從這個標簽關聯的 Issue 開啟你的第一次 代碼貢獻，
開發插件當然也算是一種代碼貢獻，比如之前有用戶就提了他的場景是希望可以匯入 Curl 變成 API 檔案，我們沒多久就支持用戶可以自己開發匯入插件，
如果你熱愛寫作，還可以在完善官方檔案，在社區描述產品以及產品的功能等等，還有一些社區推廣，這些都是我們希望得到的貢獻，我覺得為開源貢獻力量得到的回報就是能夠學習到很多、受教很多、且能夠鍛煉任何你能夠想到的經驗，
劉昊臻： 能否介紹一下 Eoapi 開源產品的歷程，幫助其他想要做開源產品的團隊了解如何從零到一逐步做起來，其中又有什么值得特別關注的點？
秦圓圓：
關于立項：
-
產品定位/解決哪些用戶的問題；
-
定專案名稱，最好不要重復，公司的專案還不能侵權別人的商標；
-
你想要在國內還是國際發布，提前準備域名建立官網，當然直接使用 Github pages 也是可以的；
-
專案選什么 License，Apache 還是 GPL 還是超靈活的 MIT；
-
在哪個平臺開源 Github 還是 Gitee，
關于組建團隊:
-
招聘： 技術過硬是基本需求，有開放的心態、有一定文字功底會更好地勝任開源作業；
-
組建開發者關系部（布道師，文字作業者等）；
-
選協作工具，定協作的流程，開源團隊的氛圍相對業務團隊來說決策會比較自由、開放，
關于代碼流程上考慮:
-
補充社區規范；
-
代碼合規；
-
發布頻率/發布策略，例如版本號用什么規范，發布版本需要 beta；
-
CI/CD 流程，
關于怎么運營:
有時候我們會有種觀念，覺得酒香不怕巷子深，這是沒問題的，但是你如果能做到巷子不那么深，酒不就能讓更多人喝到了嗎？
不是說我為了運營我就不弄產品了，運營和做產品一樣重要，相輔相成，只是我們在不同的階段運營的側重點不一樣，開源因為面向的是開發者，所以他的手段可能和 C 端的不一樣，我這里不說具體的方法，因為我也不算專業的，所以就講兩個小故事，來表達我對開源運營的看法，
-
就是說某個開源專案 A（不點名怕得罪人哈哈）在線下舉辦活動的時候拉了微信群，參加活動的人進群后，專案運營的小伙伴告訴大家點個 star 就可以領取獎品，被罵慘了；
-
又有某個開源專案發起了一個叫滅蟲計劃的活動，就是將專案里面某些簡單的 Bug 釋放出來讓大家修復，其實我一開始聽的時候也沒什么感覺，就像 Github 本身也有 good first issue，但還是引起爭議了，因為有人發現這個活動其實對于軟體質量、貢獻者水平提升的收益不大，目的指向了 Issue 和貢獻者的數量，為了追求數量刷出來的 Issue 甚至降低了開發效率，比較形式主義，
這兩件事讓我覺得我們在做運營的時候，首先要了解開發者團隊，不要功利地刷資料，不要感動自己，做影響力而不是使用營銷手段做運營，更多是傳遞我們的產品能幫助用戶解決什么樣的問題，關注產品價值和用戶價值，
劉昊臻： 因為開源團隊里還有蠻多其他成員，可以麻煩你介紹一下目前的開源團隊成員么？他們各自在團隊內的分工，他們的特質，以及你最欣賞大家的點是什么？
秦圓圓： 其實我們開源團隊主要有三個人，我 github scarqin，kungfuboy 俊杰，buqiyuan 小緣，
Scarqin 主要負責開發、運營和產品設計，偏重產品設計，
Kungfuboy 俊杰 主要負責的是技術架構、插件核心系統開發、官方插件開發，在技術上他會經常從系統的角度給我們分享如何劃分邏輯，以及善用工具解決工程系問題，他的座右銘是將機器編程進行到底，卷死人類，日常喜歡用編譯手段開發小工具提效，基本上每次團隊分享別人都是講和前端、工程有關的內容，而他的主題不是機器編程，就是在機器編程的路上，我最欣賞他對于技術的熱情以及對于解放人類手動編程事業的執著追求，對了，還做得一手好 ppt ，
buqiyuan 小源 主要負責組件庫、業務功能開發，他是我們中最年輕的人，也是最晚加入團隊的貢獻者，面試時我就知道他有個開源專案比目前 Eoapi star 數還要多的組件庫專案，他是屬于除了溝通技術之外就基本上很少說話的人，一開始開口的時候也會緊張，我們剛開始交流還擔心表達有問題，直到我看到了他的第一份檔案，邏輯十分清晰，我相信能寫這樣一份的人表達和理解肯定是沒有問題的，就是不愛說話罷了，
我自認在他這個年紀，并沒有在業余時間那么積極地參加開源專案，所以我最欣賞對貢獻社區的熱情，是個內心有自己的小宇宙的人，因為我是技術轉產品嘛，所以也有很多東西在學習中，其實他們給了我很大的支持，原型圖畫的不好全靠腦補，之前是遠程現在我們在同一個小辦公室，經常討論技術、用戶場景、產品等等，我們還會一起寫官方檔案，回復 issue 和用戶交流等等，
感覺就像是一個并肩作戰的突擊小隊，我喜歡和他們交流技術，分享產品設計心得，辦公室還會堆很多小零食餓了就一起吃，我非常享受這樣的氛圍，
劉昊臻： 開源團隊最開始是完全遠程協作的，直到最近才見面，因為其實能夠真正實作遠程辦公的的遠程協作團隊并不多，能否介紹一下你們是如何進行遠程協作的，并且其中踩過什么坑、如何解決等？
秦圓圓： 我覺得其實遠程辦公和線下協作的很多問題都是共通的，只是遠程辦公將問題放大了，所以我相信如果能做好遠程，也一定可以做好線下的作業的，
首先要提前規劃好 Roadmap，產品計劃，讓大家都知道我們這個階段最重要的事情是什么，因為每個人都有很多作業在做，開源里不只是要做代碼開發，可能還要寫檔案回復客戶問題等等，所以我們每個階段會有一個很重要的內容時間點，只要在那個時間點內完成相應的作業，其他的作業自己去安排發揮，提前規劃好 Roadmap 和產品計劃，我們還需要以各種檔案為基礎的協作，提前寫技術方案預估時間，完成后歸檔相關檔案以便其他成員理解，保持開放，有問題及時溝通，以及每周固定時間周會，明確 Roadmap，溝通進度等等，公開透明是良好協作的基石，
劉昊臻： 你從一個跟著產品需求來做迭代的工程師角色，轉變成一個既要負責思考產品，又要做開發，還需要帶領團隊的角色，在這個程序中，你覺得從作業內容、心態、能力等方面有什么改變么？
秦圓圓： 之前做開發主要是按照需求的迭代走，其實大部分作業是自己可以自己獨立完成，進度能自己控制，帶團隊后你會做很多協調大家更好地作業的事情，比如任務分配、跟進和其他團隊溝通協調資源、團隊成長等等，
其實有些事情蠻瑣碎的，但是可能不得不做，從一開始的手忙腳亂，到現在起碼在我心目中是及格了，在作業內容上的最大變化是寫代碼的時間變少了，其實我自己真的很享受寫代碼的時間，我很喜歡一部電影叫心靈奇旅，里面提到一個心理學概念叫心流，心靈的心流水的流，進入心流模式的人就進入了自己的沉浸世界，極度專注，
自己個人技能多了很多，學會了原型設計、如何寫文案、運營的知識、和各種團隊的人協調合作等等，感覺做產品就是要成為一個全能的人，所以未來還有很多知識要學習～
劉昊臻： 在這個轉變程序中，你覺得遇到最大的問題是什么？是怎么解決的？
秦圓圓： 之前是任務導向，現在變成目標導向，所以一開始會做很多不是自己擅長的問題，所以第一反應是為什么是我，太難了，我做不了，拒絕、排斥、沮喪，
現在想的是我到底要怎么做才能實作，要找誰做，缺什么，我怎么才能獲得這些資源，這種變化不是一時之間的，而是漸進的，可能過去容易沉溺在舒適區，其實只要走出第一步建立自信，后續的作業都會容易很多，不再被動的判斷一個任務是否合理，能做才做，而且覺得自己有主動權可以去處理這個任務，
當然也不要逞強，明明做不好還要硬著頭皮接，接了就盡全力去做就好了，確實不行，及時承認自己做不到也是一種勇氣，
劉昊臻： 最后，麻煩對 eotalk 的朋友做個寄語吧，
秦圓圓： 感謝大家參加今天的分享，我覺得開源就是一種協作方式，讓你隨時隨地地參與你感興趣并愿意為之投入的專案，遇見那些和你志趣相投之人，從幫助他人中識訓成就感和快樂，我一直覺得我從開源專案中得到的識訓的遠大于我的貢獻，希望未來能夠在開源世界里與再次與大家相遇，一起共建 API 生態，
點擊此處看直播視頻！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501252.html
標籤：其他
上一篇：leetcode 155. Min Stack最小堆疊(中等)
下一篇：OpenStack-T版基礎環境