Waldo-gcp

Waldo-gcp 在 2015 時 Google I/O Extended Taipei 時分享過一個計算最佳路徑的微服務。在提供幾組 Google Maps 上有效的地址，透過 Google Maps Distance Matrix API 來計算出每一個點一點之間的旅行距離及旅行時間。再透過基因演算出計算出周遊一圈旅行最短路徑

1
2
3
4
5
6
7

# 提供5組 Google Maps 上有效的地址
台北市內湖區瑞光路227號1樓,
高雄市鼓山區美術東二路106號,
台南市長榮路一段175號,
臺北市松山區南京東路五段123巷1弄15號,
高雄市五福四路131號2樓

此篇就對 Cage & Ping wedding 中實作專案中最為重要的 backend API (endpoint API) 部份進行簡單的說明，每一個 Google App Engine Service 實作的細節會在後序的篇幅中介紹

weddingcnp 系例傳送門

1. weddingcnp via GCP 簡介
2. weddingcnp via GCP - 1. 專案架構切分
3. weddingcnp via GCP - 2. 前端頁面設計實作
4. weddingcnp via GCP - 3. endpointAPI 設計實作
5. weddingcnp 前端 vue.js 設計實作
6. weddingcnp edm 寄送 sendgrid

endpointAPI 設計實作

圖一

圖二

Cage & Ping wedding 的網站大至上可以區分為靜態頁面(frontend Service, Golang) 及負責資料收集的 API (endpoints Service, Python). Google Endpoints API^[1] 是架構在 GAE 上的一個 RPC (remote procedure call) 服務。由於 endpoints API 是基於 ProtoRPC remote.Service 實作出來的，所以在實作我們的方法時也是依照 protorpc 的方式來定義，小弟在寫 Cage & Ping wedding 這一個網站的時候 Endpoints API 還是 1.0，所以這篇文章還是以 Endpoints API 1.0 來說明

此篇就對 Cage & Ping wedding frontend Service 使用了 GAE standard runtime 搭配 echo 網頁框架實作介紹

weddingcnp 系例傳送門

1. weddingcnp via GCP 簡介
2. weddingcnp via GCP - 1. 專案架構切分
3. weddingcnp via GCP - 2. 前端頁面設計實作
4. weddingcnp via GCP - 3. endpointAPI 設計實作
5. weddingcnp 前端 vue.js 設計實作
6. weddingcnp edm 寄送 sendgrid

weddingcnp 前端頁面設計實作

Cage & Ping wedding frontend Service(Module) 主要的功能如下

• serve 靜態資源(audio、js、images、css)，serve 動態資源(婚紗照片由 Google Cloud Storage 提供)
• 服務整個主體的網站架構中模版
  • 首頁介紹頁
  • 婚妙相簿頁
  • 婚宴地點介紹引導頁(訂婚、結婚)
  • 報名頁面(我要參加)^[1]
  • 隱藏網頁(求婚影片搶先看)，連結由喜帖中的 QR code 提供
  • bingo 遊戲

frontend Service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

.
├── public                // static resource
│   ├── audio
│   ├── css
│   ├── images
│   └── js
├── templates             // html templates
│   ├── bingo.tmpl        // bingo game
│   ├── chiayi.tmpl       // 地點引導
│   ├── gallery.tmpl      // 婚紗相簿
│   ├── greeting.tmpl     // 隱藏網頁，連結由喜帖中的 QR code 提供
│   ├── index.tmpl
│   ├── layout.tmpl
│   ├── live.tmpl
│   ├── luzhu.tmpl        // 地點引導
│   └── rsvp.tmpl         // 報名頁面
├── app-engine.go
├── app-standalone.go     // Google App Engine entry point
├── app.go
├── app.yaml              // frontend services yaml
├── index.yaml            // index for Datastore
└── main.go               // echo framework entry point

此篇就對 Cage & Ping wedding 中實作的專案架構進行簡單的說明，每一個 Google App Engine Service 實作的細節會在後序的篇幅中介紹

weddingcnp 系例傳送門

1. weddingcnp via GCP 簡介
2. weddingcnp via GCP - 1. 專案架構切分
3. weddingcnp via GCP - 2. 前端頁面設計實作
4. weddingcnp via GCP - 3. endpointAPI 設計實作
5. weddingcnp 前端 vue.js 設計實作
6. weddingcnp edm 寄送 sendgrid

weddingcnp 專案架構

Cage & Ping wedding 完全架構在 Google App Engine 上，再功能任務上需要達到幾個要求

• 服務靜態頁面, 一堆的 html/css/javascript 及些許的動態資料
• 作為 API 的伺服器，收集前端表單送過來的資料並儲存至 Datastore 中
• webmasters domain owner

project structure

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

.
├── endpoints               // endpoints instance
│   ├── apis
│   ├── handler
│   ├── lib
│   ├── app.py
│   ├── app.pyc
│   ├── app.yaml
│   └── ...
├── frontend                // frontend instance
│   ├── public              // 公開資源
│   │   ├── audio           // 音樂檔
│   │   ├── css             // 靜態網頁用 css
│   │   ├── images          // 靜態網頁用 image
│   │   └── js              // 靜態網頁用 javascript
│   ├── templates           // golang 模版
│   │   ├── bingo.tmpl
│   │   ├── .....
│   │   └── rsvp.tmpl
│   ├── app-engine.go
│   ├── app-standalone.go
│   ├── app.go
│   ├── app.yaml
│   ├── index.yaml
│   └── main.go
├── ownership               // webmaster instance
│   ├── app.yaml
│   └── googleae8f4bcce8bec00c.html
├── dispatch.yaml           // dispatch.yaml
└── makefile                // cli helper makefile

Cage & Ping wedding 是一個我們為結婚喜宴處理朋友出席報名相關事宜特別開發的網站，所有的服務全部建構在 Google Cloud Platform 上

功能大至如下:

• 喜宴相關資訊

  • 訂婚場/結婚場時間、地點、交通資訊
  • 出席人數統計(強制使用 Google/Facebook 登入)。訂婚場/結婚場，人數、葷素、兒童椅等，需不需要住宿

• 婚紗搶先看，先公開一部份。喜宴當天再公佈所有照片

• 喜宴進行中的 Bingo 遊戲
• EDM (發佈 email 給參加的朋友)
• GA (關心一下有多少人來看)

labstack/echo 一個輕量、高效的 Golang 網頁框架，讓使用者非常容易的建立 RESTful API 伺服器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package main
import (
	"net/http"
	"github.com/labstack/echo"
)
func main() {
	e := echo.New()
	e.GET("/", func(c echo.Context) error {
		return c.String(http.StatusOK, "Hello, World!")
	})
	e.Logger.Fatal(e.Start(":1323"))
}

1
2
3
4
5
6
7

# run echo API server
$ go run main.go
⇛ http server started on [::]:1323
# get request
$ curl http://localhost:1323
Hello, World!

最近因為公司專案的關係，開始接觸 Facebook Live API，需要動態的透過 API 去建立一組 Live 直播 並將 rtmp 的整個字串拆解成 ServerUrl 及 StreamKey 二個部份再由 ffmpeg 拿到這個資訊去 streaming。因為 Youtube Data API v3 可以別分拿 StreamName 及 IngestionAddress, 所以只需要對 Facebook 的部份特別處理

LIVE DEMO

在開發 GAE 應用程式時，難免會遇到應用程式需要處理圖片的問題。GAE 的應用程用可以直接存取靜態的資源檔案，這塊直接在 app.yaml 檔案中設定就可以了，不過也因為 GAE 應用程式的特性，需要將所有的資源上傳一份到 GAE 正式環境中，所以會發現上傳專案的容量大小會爆增(如果你將所有需要的圖檔階直接放在程式內)。

專案檔案太大會影響 GAE 在自動擴展的效能，所以盡可能的將不必要的東西移多專案外(圖檔等)

本來是使用 brew 來管理 golang 的版本，brew 及 brew cask 某些程度是很方便，不過也越來越覺得彈性差了點。繼 node 使用 tj 大神的 tj/n: Node version management 之外，golang 也打算使用 moovweb/gvm: Go Version Manager 來管理版本，不過在照著官方步驟時報錯了，順手記錄了一下解決的方式

Atom 是一個 GitHub 開發的免費、開放原始碼編輯器，目前有非常多的擴充工具可以安裝(4,913 packages)，也有非常多的主題佈景可以安裝(1,645 themes)，彈性非常的高，你可以打造成自己熟悉的開發環境。