從 0 開始的開放生態圈 — Openweb 篇

哪天用街口不再只是為了付錢？

我猜大部分的人進來街口就是幾秒的時間馬上刷掉

那如果街口有了繳費以外的功能，例如：商城、售票等等，大家進來的時間鐵定可以超過 1 分鐘吧ＸＤ

但是今天街口不想一直自己做產品，要怎麼快速擴展不同業務啊！最懶惰方式就是請別人做，前提是你需要具備足夠的核心價值和導流，讓別人想在你家產品上上架他的產品是嗎？

倘若我們能開發一整套系統，裡面有我們自己的語言、模組、IDE，讓第三方開發的小程序 App 能嵌入街口 App 中，街口的服務產品就會變得多元。

Openweb 前身，JKOMA 小程序起源

圖為第一版小程序 IDE Prototype (Jkoma = Jkos Mini App)

為了讓使用者體驗小程序時，可以更逼近真實的 App，我們期望開發者不是實作一個 webview 而已，而是逼近一個真正的 App，那我們要做哪些事情呢？

For Mobile

• Mini app Life cycle
• Multi-Thread Workers
• Template analyzer
• Allocate Mini app project
• Same layer rendering
• Data binding
• SDK
• Api for Javascript

For Web

• Mini app DSL Script
• Mini app IDE (desktop app by electron)
• Mini app Component library Injection
• Package Mini app (upgrade, downgrade)
• Debug Tool

and more…

上面任何一個都是一個研究項目，非常有趣兼具跳戰性，我們也努力了半年左右，考慮到各個層面的因素（ex: 人力、現實考量），我們決定先從 Openweb 開始，逐步實現不要貪心。

Openweb 登場

一個 Miniapp 小程序的簡單版，其實就是 webview。

未來我們也希望 openweb 可以更加豐富，慢慢趨近小程序的目標。

像是 Openweb 可引入的東西除了 js-bridge 外，還可以擴充很多 library，再加入友善的 IDE 模擬器，減少人力成本協助三方快速 Debug，從開發到部署串成一線。

什麼是 js bridge ?
與 App 溝通的管道，每個 webview 會建立一個管道，這個管道有很多功能，web 可以透過執行這些功能來達到目的。

Openweb SDK 開發

SDK 就是我們對外開放的能力，他們可以在 openweb 使用街口登入授權，或是拉起付款頁面，又或者調整 UI 介面。

首先製作 SDK 有哪些考量呢？

起初第一版主要是串接成功就收工，但是後續不好維護及擴張，於是有了第二版本：

• 統一核心共用模組 Bridge Model
• 統一 function 的參數順序
• 定義 function params schema
• 建立 params validator
• 建立 params refiner
• 可彈性注入外部 function ex: url formater
• 定義可使用 function 的最小環境版本
• 檢查 Openweb 當下進入的 webview 是否正確，才可以啟用
• 定義 error code 與 App error 做區隔
• 打包產出 umd, cjs 格式

假如我們都開發好了！那我們要怎麼 demo 給 QA 測試呢？

Openweb Playground

來建立一個 demo playground 吧！原本想說就簡單做一個給 QA Demo 用的平台就好，後來想想不對… 這樣每次新增一個 function 我就要重新上版這個 playground，實在太麻煩了。

剛好那時候聽到主管 Kim 哥說有一個 headless CMS — Strapi，要拿來做 mock data。

這時候突然想到似乎也可以利用這個當作後台，來上下架 sdk。

我認為的 Playground 功能列點有

• 可以 動態切換：不同 版本、格式、環境、分類的 SDK
• 可以 動態填寫 input 的內容並塞進 function
• 可以 看到最後組好的完整 function script
• 可以 看到 callback 結果
• 可以 同時執行多個 function（快速測試）

登愣！！🥳🥳🥳🥳🥳 這樣以後我們不需要每次更新 SDK 就得重新部署 Playground 拉。

如何添加新的 function 到 Playground

我們使用 Strapi 的主要功能是，他可以透過操作後台設定來建立 CRUD 的 Api：

• version: 提供幾種版本切換
• category：function 分類
• functions: 所有 function

再建立 function 樣板

• 利用建立好的樣板產生前台的 form 表單及 function script

花短短的時間，我們的 playground 已經很完整了。

有了這一套 SDK 建立方式，從此我們只要專注在 SDK 溝通正確即可，以及將新的 function 放進 strapi 裡。

如果也想把別的 webview 的 sdk 更新成這個模式是可行的嗎？

可以的，只要把舊的 sdk 更新，並重啟一台 playground 注入不同 sdk library 就可以 0 成本啟用一個全新 playground。

太好了，這下子又減少不少時間可以準時下班拉～～～～

Openweb 有什麼難？

多數人提及 Openweb 就說，喔！不就是 webview + sdk，是這樣沒錯，但實際接觸後會有很多你所不知道的細節在裡面。

除了前端，你需要了解 App 甚至了解第三方。

對於街口方 而言

1. App 針對三方 webview 開放使用的權限能力評估
2. App 的版本與 SDK 是否符合 Openweb 需要
3. 不同 Openweb 進入方式的處理，ex: Url scheme, Deeplink
4. 當第三方 Openweb 掛掉時，處理風險的方式
5. 把關不同進入的網址連結是否為被允許的網址
6. 評估第三方提出的需求是否要納入未來版圖去實作
7. 如何快速開發並測試 SDK

對第三方而言

1. 缺乏線上文件與第三方溝通，需提供一個開放文件管道

（low-code to no-code 讓所有不懂程式的人也能共同編輯文件）

2. 三方在撰寫 javascript 語法 與 框架方式各有不同，總會遇到千奇百怪的問題。

(例如：當第三方直接把他們官網放進來，你要怎麼讓他能 work，而且在 webview 要兼容各種手機有很多雷點可以說…）

3. 測試資料與開發工具需要窗口協調處理

4. 上線後的維護處理，發生問題時街口要如何第一時間告知

5. 當有 SDK 要升級時，許多流程要再重新 loop

在與三方串接過程中，每次都讓我們認知到現階段有哪些不足，並開始規劃下階段我們能怎麼突破

Miniapp 時期的產品不會白廢

雖然之前實作到一半的 Miniapp 相關產品最後並沒有繼續，但是讓我在學習過程中獲得不少啟發。

期待能將 Openweb 用在第二版的 Miniapp IDE 🤩 我相信可以解決當前多數的問題，我們仍需要點時間。

圖為第二版的 Miniapp IDE

套一句主管常說的話：

需求有時候不一定是 PM 提出，發現問題用有趣的方式解決，也是一個讓工作不無聊的方法之一 ！

如果你在工作上做過什麼酷東西，也歡迎和我們分享～～

接下來還有最後一篇，有興趣的人請不吝嗇的大力拍手手～ 😝😝😝