不用寫程式也能產生 API — strapi
雖然這標題有點嚇人，但也確實也是我心中浮現的第一句話，今天想用個簡單範例跟大家分享一個才最近發現的工具 strapi 如何達成這個目標，推薦給
- 前後端工程師：想得到 CMS 工具的便利又不想被 theme 調整感到困擾
- 公司老闆：想知道可能可以如何更低成本、高效率完成一些簡單需求！
背景
今年花了一點時間嘗試接「小型網頁案子」來創造一點「業外收入」，做了幾個案子後發現其實大部分案子需求都蠻單純的，大致為
- 資料檢視（Read）：前台使用者能篩選出想要的資料
- 管理資料（Read、Create、Update、Delete）：後台權限管理
- 儲存圖片（Storage）：串接 aws s3
- 部署環境（Deploy）：aws route53 串接 domain、aws ec2 租機器
這時工作室老闆就有個 idea 是能不能我們做一個能「動態產生 API 」的系統，比如用手指點點系統介面就能決定 API 欄位這種天馬行空的想法，資料搜集後發現還真的有這種工具，而且還是個破 3萬個星星的開源專案「Strapi」，於是展開了這一段探索之旅及產生了這篇文章
Strapi 之於 Headless CMS
在 Strapi 官網上介紹自己的一句話是
Strapi is the leading open-source headless CMS. It’s 100% JavaScript, fully customizable and developer-first.
Strapi 定位是一個「Headless CMS」工具，傳統 CMS 大家應該會馬上想到 Wordpress 等等知名的工具，那他們有什麼差別呢？
Normal CMS v.s Headless CMS
一般的 CMS 與 headless CMS 最大差異就在這個工具「有沒有包含前台的介面」，一般 CMS 會擁有許多樣板可以選用，而 Headless CMS 最終就是輸出 API 跟 資料，而 frontend UI 就是自己實作
Headless CMS 優點
- 分離前台開發環境，不再受到 CMS 樣本的苦惱，比如 3D 特效、頁面切割等等都可以自行決定
- 獨立的後端、後台環境，可以獨立的水平擴增負載
- 專案開放，能在上面再客製化 API，而且 100% nodejs 對於相關開發者很友善
Headless CMS 缺點
- 前台須完全自行實作，如果不是客製化網站的需求，會相較模板開發費時
- 相較傳統 CMS 能支援的外掛數還不是很多（雖然我覺得很夠用），比如 Wordpress 有許多購物車外掛、SEO 外掛等等
Strapi 基本介紹
先介紹主要兩個功能 Content Manager 跟 Content-Types Builder
Content Manager
左測左上方就是能管理的資料分類，點入後會切換右邊畫面。
這邊就是管理後台基本的 CRUD 需求
Content-Types Builder
這是 Strapi 這主要功能，就是本篇主題能「不用寫程式就產 API」的功能。
點入後會看到三種分類
- Collection types
- Single type
- components（先不介紹）
Collection type 及 Single type 其實很像，就差在「後台編輯界面」跟「API 格式」的不同而已。
- Collection 是預期有多筆資料，比如一個網站應該會有很多 category，那就會有很多資料可以新增修改
- Single type 就是一筆資料的編輯，比如 Homepage 需要有標題跟 banner 圖可以編輯，但應該不會有兩個 Homepage 資料，只會有一筆。
重點應該在更右邊的部分，這是定義資料的內容，也將會是 API 的欄位，有蠻多種類可以編輯的，比如 text、number、media 等等常見的格式，以下我們用一個範例應該會更明白很多
Strapi 範例
假設今天要製作一個類似 Apple 官網商店的開發需求，想要有「瀏覽商品」跟「商品分類」的內容管理系統
Categories：儲存不同商品分類
因為一個電商網站會需要有很多分類來幫助使用者區分商品，這邊擁有 Mac、iPhone、iPad 這種以產品類型直接的分類
Products：儲存商品實體內容
當點選「iPhone」這個分類，會再列出在 iPhone 這個分類下面的商品們
實作 Categories API
Content-Types Builder -> Collection -> Create new collection type
因為 Categories 是會有很多筆的，所以選擇以 Collection 方式建立
完成之後就會產生 Categories 這個 Collection 在左上角了，點擊進入我們手動新增兩筆資料
如法炮製第二筆後的結果
測試 Categories API
接著要把 API 權限開放成 public
路徑：settings > roles -> public > categories
把 categoires API 當中的 find 跟 findone 打勾開放，右側也會提示 route 位置
- find 的是 /categoires
- findone 的是 /categories/:id
完美！
而這個 api 其實還附帶各種 filter、sorting，有興趣可以查這裡
實作 Products API
依照介面簡易的配置一些對應的資料欄位，這邊比較不一樣的是有新增了一個 relation with Categories 的欄位，用來建立產品跟 Categories 的關係
因為這邊多個產品應該會隸屬於一個 Categories，比如一個 iPhone 分類下面有 iPhone 13、iPhone 12
建立測試資料時，介面右側就會出現一個關聯欄位可以選擇
手工之後，有了三筆 Product 都是關聯到 iPhone Category 的資料，同時回到 Category 的資料會發現介面上也有顯示關聯了哪些 Product
測試 Product API
會發現 API Response 會自動把 category 資料關聯出來
同時 Category API 也有了變化，這樣就也可以透過 category 直接抓到專屬於特定類型的 products 們了。
參考文件
小結
今天只是簡單的分享如何使用 strapi 做到「不用寫程式也能製作 api」這個主題，其實 strapi 還提供其他功能，比如說
- 如何使用 Component Type 來做到更直覺的後來編輯介面
- 會員系統相關 API（登入、註冊、忘記密碼、授權管理）
- 後台權限管理（不同層級能預覽的 collection 範圍不同）
- 自訂 API 邏輯（預設寫 NodeJS 有自己一套 Service、Repository、Model 工具）
- 自訂後台介面（預設寫 React）
同時也有蠻多好用的外掛
- 第三方登入串接（Google、Facebook、Twitter、Github …）
- Swagger API 文件產生
- 支援 GraphQL 工具
- 支援 i18n 多語系配置
最後分享一個在探索過程的想法，在驚嘆工具的同時會覺得「哇，這麼方便的工具那麼會不會有很多未來 API 開發需求就都可以被取代了嗎」，我對這個答案是肯定的，雖然可能 strapi 還不是非常龐大有各種外掛支援，但不意外總有一天這種系統會像 WordPress 一樣成長到非常大。
另外這樣我是不是就沒「業外收入」了 XD，雖然實際上是少了好幾個需要我的案子沒錯，但這不一定是壞事，因為實際上我們是用更少的時間做到更多的事，同時我們也可以把時間更專注去面對更多更複雜需求的案子需求也蠻有趣的！
如果喜歡我這篇文，可以幫我拍手 1-10 下
如果覺得這文章對你有幫助，可以幫我拍手 10–30 下
如果對於 strapi 工具更多應用感興趣，可以幫我拍手 30–50 下
也記得 Follow 我 陳建宇 才不會錯過新文章哦
歡迎在下方留言，我很樂意與你討論聊天或回答問題！
