前言

最初只是想重構蔬果行情站的應用程式，

目前專案是採用非正規的架構寫出，

而且相當小眾，壞了很難追到問題的原因；

近期較熟悉官方推薦的方式，

也對於這個專案有些新想法，就決定把它砍掉重練。

而前陣子 Google I/O 宣布：

Google Cloud Platform 提供 Always Free 方案，

便衍生了把蔬果行情站後端拆出去的念頭，

因為目前主機上有數個專案在運作，負擔太大了。

現狀

簡介

Google Compute Engine 架設爬蟲，

爬完資料就存本地透過 git push 到 GitHub，

手機 Client 直接去 GitHub 拿整理後的資料。

（也有些資料不需整理可以直接從 Open Data 拿）

一開始有寫 API，但某一版串 API 發現不太穩定，

覺得 GitHub 比較穩就拿掉 API 了，

索性也不存資料到資料庫（覺得資料庫膨脹很煩）。

優點

省錢，流量全導到別人家（賤）。

爬蟲伺服器只要開最小規格的就好。

缺點

資料檔案很佔主機容量，畢竟是開最小規格的。

應用的資料公開給別人看。

資料放美國不夠快，使用者絕大多數都在台灣。

某次 GitHub  掛掉，我的 App 也跟著死了，

那種主導權不在手上的感覺相當無力。

小結

我不想存一堆檔案在我的主機，

也不想把檔案放在救不到的地方。

新版 – 第一版

簡介

這版決定老老實實地將 API 納入主要規格，

後端 PHP 框架從原本的 CodeIgniter 轉為 Lumen，

爬蟲改寫，資料庫 schema 也稍做調整。

主機是 Compute Engine Free Tier（最低規格）。

優點

API 開放後的各種彈性。

沒有存一堆資料檔案。

資料庫有資料，咦？

缺點

規格最小的伺服器頂不住。

主機一樣是在美國。

小結

真心覺得爬蟲跟 API 在同一台爛主機很不妥，

API 開工前決定踩剎車。

新版 – 第二版

簡介

其實就是走舊版的老路，

但資料不放 GitHub，改放 Google Cloud Storage。

把上一版 API 帶來的負擔轉移到他處。

優點

台灣有機房，讀資料超快。

資料容量轉移到 Cloud Storage，減少主機空間負擔。

一樣可以開最小台的主機作為爬蟲，

不用為了 API 把機器開大台。

缺點

資料連結全都公開。

小結

當我接好 Cloud Storage，

突然想到：

若資料被盜連，流量錢是我在刷啊，幹！

（話說這資料真的有人想用嗎？）

新版 – 決定版

簡介

最終採用的架構，與上一版很相似，

但 Client 跟 Cloud Storage 中間多了一層像 API 的角色。

這一層用了 Cloud Functions 服務，

採用 Node.js 的 express 處理 Route，並驗證 Client 是否合法，

當驗證成功，就去 Cloud Storage 拉資料吐給 Client 。

優點

檔案連結不公開。

爬蟲的主機不放 API，較不吃資源。

有驗證機制。

缺點

目前 Cloud Functions 沒有台灣機房選項，

所以還是會連到美國，微慢。

小結

目前 Cloud Functions 還是 Beta 版，

應可預計未來會開放台灣機房，

屆時再轉過去即可。

豪華版

簡介

如果經濟狀況允許的話，我會這麼調整：

開一台 Cloud SQL instance，捨棄 Cloud Storage，

API 由 Cloud Functions 轉移到第二台 Compute Engine，

API 主機會直接連到 SQL instance。

每一次戳 API 的結果會 Cache 在 API 主機，

若負載大的時候，就加開 API 主機數量。

不提升 SQL instance 是因為使用者拿的資料幾乎都一樣，

大多都是靠 Cache 在提供資料，所以 SQL instance 相對輕鬆。

另外，Client 完全不依賴 Open Data，

也就是 Open Data 掛了，App 還是可以運作。

優點

API 可以處理更複雜的事情。

缺點

比較貴。

夢想版

簡介

後端全砍掉，只依賴政府的開放資料 API。

優點

省錢的極致。

政府提供高水準的開放資料（許願）。

政府不會隨便下架開放資料（許願）。

缺點

無，做夢是美好的。

後記

原本只是想重構應用程式，

沒料到後端會翻掉重做。

之前在粉絲團發文說要開工，

前陣子還回覆使用者：近期會發新版。

結果看了日期是四月的事情了，媽呀！

現在還得將應用程式用 Kotlin 改寫，

到底何時才可以發版啊……