從 0 開始的開放生態圈
本篇主要講述建立公司對外服務的開放生態圈的心路歷程，以及我們為什麼要做整合？
身為工程師每次都在使用各種平台的 console，什麼時候才能自己做一個呢？ 這是我在協助串接第三方時，常常會問自己的問題。
也就是有這樣的想法，才會有今天的小成果，那就讓我們來瞧瞧從 0 開始會遇到哪些挑戰吧！
很特別的是這個產品是由工程師們啟發並規劃設計的，因為以往 RD 都是接收需求方，所以能夠有此次規劃實驗產品經驗是很寶貴的。
接下來就開始摟！
開放平台是什麼？
簡單來說，就是為了拆除大家一直認為街口就等於支付的印象標籤，開始打造更多外部服務的串接，並逐步將需求統整歸類，因而誕生開放平台。
核心目標
如何讓第三方快速串接並減少人力成本是本次探討的重點。
當接入的第三方愈多，我們擁有的樣本數愈多，此時我們可以：
- 檢視開發與測試上的不足。
- 不斷修正產品服務的價值定位。
有了開放服務，不就可以串接第三方了，那為什麼要特地做一個平台呢？
沒有平台下的服務如何讓外部串接？
假設某天 PM 提出擴增以下兩個服務需求
當 RD 快速做完需求後，我們開始要跟第三方拉扯：
- 如何申請服務？ 需要找到窗口並有一系列人工簽署流程才能申請
- 如何串接服務？ PM / RD 緊急產出應急的 PDF 文件，每當文件一改變需重新傳新的文檔給對方
- 如何順利開發與測試？ 給與各項測資及工具，並在雙方 RD 一來一往後完成
- 如何上線至街口 App？ 開發辛苦一波後，口頭告知窗口，幾月幾號要上線
- 上線後發生問題？ 對方窗口互相知會後，手動下架
- 隨著有新服務的誕生及突發狀況，（步驟 2,3,4,5) 會出現不斷 loop 地獄
為什麼我們沒有在當下思考後續問題，原因可能是新服務需要搶先釋出，測試市場反應與可不可行，這導致許多服務都是這樣來的。當新服務過了一年後，也就成了無法隨意割捨的歷史包袱，可能有著嚴重耦合的關係，未來要整合會非常辛苦。
依照目前流程，串接一個服務都得耗費大量人工成本來解決問題
於是乎為了解決一直被擺爛的問題，開始思考如何建置一個平台讓外部使用者可以無障礙串接。
列出開放平台有哪些要素？
- 開放能力蒐集: 豐富開放能力，吸引他們與我們串接，擴增生態圈
- 服務解耦: 無論是舊有服務的依賴，或是新服務的擴建，需要避免嚴重耦合
- 開發者平台: 開發者擁有的專屬空間，自定義其所有服務從申請、開發至上線
- 沙箱測試: 快速完成測試並且確保覆蓋度
- 開放文件: 順利且快速開發須具備完善的文件，減少窗口間的溝通成本
- 串接格式統一: 將各項服務的串接方式統一化，快速接入新的服務
太讚了，可以開始逐步實現上述功能以達到快速開發快速上架。
這麼多項目裡我們要從哪裡開始呢？
我認為是 “開發者平台”。
有了平台可以讓外部方有更好的服務窗口，並趁機釐清一下我們有哪些服務需要提供並整合。
開始畫出開發者平台輪廓
首先我們有已知的兩項服務
先列出腦中的功能，感覺列得煞有其事就可以開始畫一下：
商品
+ openweb
- 個人
- 通知設定
- 信箱
- 應用程式
- app1 (test)
- 狀態：開發中 / 已發布
- 設定
- 基礎
- 應用程式編號
- 應用程式密鑰
- 應用程式網域
- 顯示名稱
- 應用程式類別 tag
- 進階
- API 版本
- 允許最低版本設定（checkbox 功能打勾 自動配置)
- 安全性
- 伺服器 ip 許可清單
- 允許內開外來網域
- 用戶端權杖
- 角色
- 管理員
- 測試人員
- 開發人員
- 測試用戶
- manifest
- 發布
- 服務 provider
- 埋點數據追蹤
- 要求授權頁面
- 收件夾
- 申請核可上版
- 上線位置(街口 UAT APP / 街口 APP)
- 審核流程
- 審核要求列點
- 打勾
- 按確認
- 成功/失敗：送通知信到收件夾及 email
- 快速入門
- app2 (prod) - 可以 clone 一份出來
+ OAuth此時自己在腦中走一遍圖像流程，也許會看到一些問題：
- 服務的應用程式底下是否會用到其他服務？ ex: Openweb 底下可能會用到 OAuth Login
- 畫這張圖時，是否仍然在用既有功能的角度規劃？ 應該跳脫原有方向，假想自己是開發者的角度
- 在有限時間下我能全部功能做完嗎？ 先切割階段性需求，再產出 prototype 不斷往回修正
此時我們需要簡化需求，確認我們的方向是成功的，努力才不會白費。
應用程式 +新增應用程式
---
+ 設定
- 基本
+ 發布
- 最新發布
- 歷史發布
+ 服務
- Openweb
- 基本
- OAuth
- 基本
- 安全性新的 wireframe，不但解決了上述問題，看起來更加合理，應用程式之於服務可以做更多事情
- 假如我是第三方開發者，我想在我應用裡開啟
Openweb, 並在任何時候使用OAuth登入，且加入購買商品功能時可以用OnlinePay付款。 - 當所有服務不再衝突而且可以用一句話完美呈現，我認為他就是一個正確的方向。
為開發者平台加入登入機制
講登入前我們先想一下這個產品定位是 b2b or b2c ??
我的想法是，如果目標是人人都可以是開發者，那沒有比用自家帳號做登入還棒的事了，既然有 App 又有掃 Qrcode 的功能，何樂而不為呢！
登入使用街口帳號的好處是，我們可以掌控開發者平台接下來的操作都是屬於這隻手機的帳戶，意思是將來任何與街口 App 的服務都可以與開發者平台的帳號做連動。
開發環境的多樣性
當登入開發者平台時，我們可以開始開發，並在測試街口 APP 上看到開發中的服務，當我們希望這個服務可以上架到正式站 APP 時，我們需要走部署正式環境流程，也就是：
開發模式 to 發布模式
(以上這兩個模式，需要打的 API 環境是不相同的）
以下可以看出新的方式開發者平台取代窗口，且平台能同時處理兩種環境，即是：開發與正式環境
對外的開發者平台不會分兩個平台環境，因此可以想像平台環境複雜度是高的。
正式站即開發站
會有上述的環境複雜度，是由於舊有流程若有支付的需求無法動到正式站資料，因此我們需要保留空間，即使開發與正式分離，也可以透過不同模式處理不同環境下的處理，但未來最好方式是：
- 一個開發者平台
- 一個街口 App
當我們可以使用一個街口 APP 進行開發至上架，不但減少很多開發成本，也能讓開發流程更加順暢，but 前提是所有服務都能有效整合。
正式流程的發布
當開發者完成開發，會需要一個發布正式站功能，不需要讓開發者直接對窗口，我們為開發者每次發佈的版本做個紀錄，視情況需求還可以做個 rollback (當然這還不在本次規劃中)
首先需要有個畫面：
側選單為
- 發布
- 最新發布 (建立新發布，審核成功後，由後台部署)
- 歷史發布（存放每個版本的版號，及要部署內容）正式發佈流程
發布審核通過後，需要做一系列的 clone 行為， 將原先在開發環境有過的流程，在開發者平台的 deploy mode 也走一次，才算完成部署。
- 模式切換：
dev mode->deploy mode
看到這邊的讀者們，是否有個疑問，這樣後台也要再做一次前台要做的事情，豈不是要維護兩套機制？？
是的，接下會為大家解釋我們怎麼解決的。
前後台業務邏輯相似
在開發後台時，常常有些功能會與前台重疊。舉例來說：
如果看了上述的正式發布流程，我們要怎麼實作比較好？
讓後台可以 clone 原本開發者在前台的操作行為
- 後台再開發一次要上正式部署的主要幾隻 function ？
- 前台開 api 給後台呼叫？ (可惜的是有些特定 api 前台是沒有權限呼叫的)
- 部分用前台 api，部分後台自己開發？
- 開一個共用服務 service?
答：我選擇 (4) 的變形
那我不希望維護更多的機器，是不是有辦法做一個共用模組呢？
共用模組的定位
- 建立 db setting/migration
- 操作所有 db function
- 商業邏輯 api
DB 集中管理：原先不管是前台還是後台，都需要有各自 db 設定
商業邏輯抽離：各自專案不會存在各自維護的邏輯，或是兩專案沒有同步到的問題剩下的是我們要用什麼工具呢？
最後選擇是 typegraphql
到這邊很多人會問，咦？這樣不是多一個 service 要維護嗎？
因為 graphql 通常會跑在一個 server, ex: apollo server
沒錯，但是何嘗不能把 graphql 當成一個 library 呢？
讓前後台依賴這個套件，我們就不需要特別開啟一個服務多一個成本了。
太好了這個想法看起來實驗成功！也是我們現在的 @jk/opendql
如果今天 QA 要測試業務邏輯，也可以透過 apollo server，並且前後台也一起測到了，因為他們都吃同一隻 api 呀！實在是太方便了
有了 @jk/opendql 我們的分層更加清晰，彼此專案不會不知道彼此在做什麼事，你今天需要什麼東西你就去模組拿取，並且當模組的開發模式建立完畢後，與你一同開發的夥伴也會很好上手。
管理服務多樣化，沒有結束的一天
講到服務，這算是想解決也很困難的一環，從街口公司創立開始的服務，到現在新開發的服務，你要怎麼樣才能夠將其整合，想到就十分頭痛啊…
假設以下是目前要整合的服務
歸納問題
1. 不是所有服務都有 Gateway，有的話：
- 申請服務時需要填寫 IP 白名單
- 前端實作不同 Gateway 註冊/更新方法
- 不同服務之間，可能使用相同 Gateway
- 不同開發模式 mode (dev/deploy) 實作
2. 依賴項目完全不同
- 各項服務無法共用邏輯
- 需區分服務 table
3. 後端 Gateway 重構
- 統一呼叫及回傳邏輯
- 釐清內部商業邏輯依賴複雜關係
4. 既有後台的服務定位
- (理想) 從既有後台拔除，整併至開發者平台
- (實際) 部分拔除，部分整併
上述講得很簡單其實有很多是現在做不到的，也是我們為什麼一直沒好好做整合的原因之一，此時推行者就扮演很重要的角色了。
講到這邊相信很多讀者快睡著了ＸＤＤ
來一點 Demo 吧！
登入開發者平台
建立新應用程式
發佈到正式站
簡單的幾個功能，其實背後卻耗費了我們很多心力整合，在開發者體驗上呢，我們先致力於將所有人工處理自動化，並在未來新的服務加入時，可以建立在相同的規範底下。
未來的開發者平台，我們將有更多串接服務，並添加自動化測試項目，提高街口開發者的人數，讓街口生態圈可以逐步建立起來。
之後還會有相關文章，有興趣的人可以繼續 follow 呦！
