建立Vue x Amplify的專案

  • 安裝Vue-CLI
  • 安裝Amplify-CLI

僅供參考

在安裝Amplify-cli時,需要設定後續操作amplify-cli的IAM user

CLI會問你“`? Profile Name:“`,我是輸入**amplify**可參考命名設定檔

初始化專案

$ vue create amplify-vue-project
$ cd amplify-vue-project
$ amplify init # 初始化amplify,幾乎都選預設值,environment輸入dev

到這邊其實就完成了,接下來非常建議要先看看Typical workflows知道用amplify pull/push管理雲上的資源

如果是團隊開發,記得要看看Team environments下每一篇才能在這個專案在各個環境切來切去的時候比較有頭緒

如果在同個專案、多aws帳號各自建立環境時,遇到從dev分支merge到production分支後,出現衝突的狀況…
可以來參考看看這篇

加上 AppSync GraphQL API

照著Create a GraphQL API做吧

更新GraphQL

你可以透過更新 project folder 下的“`backend/api/~apiname~/schema.graphql“`更新GraphQL API
雖然還有其他方式,但在這邊做的好處是,CLI會一併幫你處理一些事情:

  • 加上“`@model“`會幫你開 dynamodb
  • 加上“`@key“`幫你定義 dynamodb table 的 primary key,或者LSI以及GSI
  • 加上“`@auth“`替你在根據這份檔案產生出來的 mutation, query 及 resolver 內加上權限控管

其他方式?有哪些?

也可以直接到 AppSync控制台 開一個 sample api,sample api 好像會用 cloudformation 一併幫你開好 dynamodb table。

也可以先手動開好 dynamodb table,再去 AppSync控制台 開一個空白api,到**DataSource**分頁使用『建立資料來源』,裡面便可以直接把 dynamodb table 匯入成 graphql api,也會一併產生 resolver,但整體上來說還是沒有用 Amplify CLI 產生來的便利

想要過濾Subscription

可以參考Filter Subscriptions by model fields and/or relations而且要額外補充Using Subscription Arguments,其中的 **Argument null value has meaning** 章節很重要又很有趣

想要自訂resolver

參考Add a custom resolver that targets a DynamoDB table from @model

用不到後端資源了,想刪掉?

如果你使用過 Terraform…
要小心使用 amplify delete 指令,它的刪除跟 terraform 不一樣!

well
你可以執行“`amplify delete“`
但它的問題是,它不僅會把(目前env下)已經佈置上雲的後端資源收掉,還會把專案資料夾下所有後端資源的設定刪光光

有如JSON Selector的JMESPath

前陣子在看AWS文件的時候意外發現這個神奇的工具,它可以降低你從JSON中取出資料的程式碼的複雜度,同時降低了維護的成本。

要我說的話,它應該成為parse JSON的標配。具體來說,它是一種可以用來從JSON中取得指定結構的查詢語言,正如它官網自己所說的:

JMESPath is a query language for JSON.

案例-從ElasticSearch API取出結構化資料

比如說ElasticSearch的Date Histogram Aggregation API會回傳一個JSON:

我想使用下面的PHP程式碼

把它轉成下列這個格式的陣列:

有經驗的人應該很清楚, 當遇到複雜的JSON、而且要取出更多資料的時候, 上面這段程式碼的複雜度會急速飆高,而且難以維護。

如果使用JMESPath, 你可以透過下列的語法得到一樣的結果:

aggregations.sales_over_time.buckets[*].{key: key_as_string, value: doc_count}

在官網實驗JmesPath

如果你有興趣,可以到JMESPath官網,貼上更複雜的JSON,自己動手玩。比如說把上面這案例貼上去……

(我眼中的)網站是怎麼做出來的

通常要做出一個網站會有這些人的參與:

  • 客戶
  • PM(專案經理)
  • 設計師
  • 前端工程師
  • 後端工程師
  • 維運工程師

# 團隊要怎麼合作呢?
## PM

與客戶溝通需求,必要時畫草稿(wireframe或prototype)溝通,

  • 跟客戶溝通(釐清出重要的需求順序)
  • 跟客戶溝通,規劃網站頁面的架構(site map)
  • 協調時程安排- 追蹤團隊的進度

## 設計師

(以前只有網頁設計師,後來新興出 UI設計師、UX設計師。)

  • 拿到客戶需求,規劃設計視覺準則
  • 若有必要配合PM提案時,先做出草稿(wireframe或prototype),通常是PM自己繪製。
  • 製作提案用定稿(mockup),跟PM、客戶來回溝通確認

### 設計師與前端 都能做的事情

定稿的畫面用程式做出靜態網頁(切版),依每個團隊分工

## 前端

  • 讓靜態網頁加上動態的效果,成為動態網站
  • 網站需要資料匯入(如:名單),寫程式跟後端拿資料

## 後端

  • 處理跟加密、金流、存資料、架站有關
  • 思考如何儲存、如何抓出來給前端呈現
  • 負責各種網站功能的實作(舉例:登入功能)
  • 串接其他服務(如串金流、寄信、寄簡訊)
  • 網站上線


## 維運工程師

確定程式能放到伺服器上跑,並監控伺服器狀態,確保不會突然掛掉

# 視需求決定團隊規模
如果是做靜態頁面,可能就不需要後端;如果客戶需要出報表,通常只需要後端。

## 不是每個團隊都有的職位本篇開頭說的其實只是一般網站團隊的標配,在業界常見的職缺還有下面這些:- 使用者體驗設計師 UI/UX- 測試工程師 QA- DevOps工程師

# 常見的職業傷害

  • 眼睛不好
  • 坐姿不良且坐太久
  • 腕隧道症候群

# 參考

事件API專武:Beacon API

經典使用場景是用來**蒐集事件並傳送到後端伺服器**
因為只是要蒐集事件,所以其實直接往後端傳即可,根本不用在乎後端回傳什麼
這樣就跟一般AJAX差很多了

Example use cases of the Beacon API are logging activity and sending analytics data to the server.

尤其是在**網頁要關掉那一刻**傳出的事件,用原本的AJAX是包準傳不出去的
為什麼?
因為瀏覽器不會理會那些在網頁關閉瞬間要求的AJAX,但Beacon API送出去的可以

如何使用

必須要考慮支援程度的問題

其實是老生常談了,想用比較潮的API就是該死
IE根本跟樂高一樣

偵測支不支援的方式如下

if (navigator.sendBeacon) {
  // support
} else {
  // not supported
}

example

如果要單純的API範例可以去Using the Beacon API這邊看
我個人覺得Beacon必須要有Ajax做備援方案拉
所以底下的寫法會比較兼容一點

比如說我要傳送前端的事件給後端…

可以運作的範例可以參考這裡