時常用到 Postgres 轉換資料的功能，來即時協助 PM 了解目前使用者實際狀況，底下紀錄常用的指令。首先安裝 Postgres 環境，這邊其實就是用 Docker 方式來啟動一個全新的 Postgres DB。

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

  db:
    image: postgres:12
    restart: always
    volumes:
      - pg-data:/var/lib/postgresql/data
    logging:
      options:
        max-size: "100k"
        max-file: "3"
    environment:
      POSTGRES_USER: db
      POSTGRES_DB: db
      POSTGRES_PASSWORD: db

上面的 environment 參數可以自由調整，接著透過 docker-compose up -d 來啟動資料庫進行 App 串接。

身為網站工程師，您不能不知道什麼是 GraphQL，這是一個前端跟後端溝通的 API Query 語法，大幅改善了前後端的合作模式，這篇會跟大家介紹為什麼麼要學 GraphQL，以及整理出三大 GraphQL 優勢，讓大家了解跟傳統 RESTful API 有什麼不同。當然不是叫開發者捨棄 RESTful API，而是根據專案的不同，來決定不同的技術 Stack。像是服務跟服務之前您說要用 GraphQL，肯定被打槍，而是要用更輕量的 RESTful API 或 gRPC。好了，底下來說明三點 GraphQL 的優勢。

相信各位開發者在寫 Go 語言專案，現在肯定都是使用 Go module 了，而 Go Module 檔案預設寫在 /go/pkg/mod 目錄內，要串 CI/CD 流程時，由於不在專案路徑底下，所以每一個 Container 無法共用 /go/pkg/mod 路徑，造成重複下載第三方套件，其實跨容器的解決方式可以透過 Drone 的 Temporary Volumes 方式解決，但是最終希望跑完編譯流程時，可以將最後的 mod 目錄打包留到下次的 CI/CD 部署流程使用，這時候如果可以改變 /go/pkg/mod 路徑，就可以動態調整目錄結構了。底下是針對 Drone 這套部署工具進行解說。

Go 語言除了內建強大的測試工具 (go test) 之外，也提供了效能評估的工具 (go tool pprof)，整個生態鏈非常完整，這也是我推薦大家使用 Go 語言的最大原因，這篇會介紹如何使用 pprof 來找出效能瓶頸的地方。假設開發者在寫任何邏輯功能時，發現跑出來的速度不是想像的這麼快，或者是在串接服務流程時，整個回覆時間特別久，這時候可以透過 benchmark 先找出原因。

1

go test -bench=. -benchtime=3s ./lexer/

context 是在 Go 語言 1.7 版才正式被納入官方標準庫內，為什麼今天要介紹 context 使用方式呢？原因很簡單，在初學 Go 時，寫 API 時，常常不時就會看到在 http handler 的第一個參數就會是 ctx context.Context，而這個 context 在這邊使用的目的及含義到底是什麼呢，本篇就是帶大家了解什麼是 context，以及使用的場景及方式，內容不會提到 context 的原始碼，而是用幾個實際例子來了解。

程式碼範例請看這邊

之前就有看到 Docker 推出 BuildKit 功能，這次跟大家介紹什麼是 BuildKit。現在部署編譯流程肯定都會用到 Docker，不管測試及部署都盡量在 Docker 內實現，來做到環境隔離，但是要怎麼縮短 Docker 在編譯 Image 時間，這又是另外的議題，本篇跟大家介紹一個實驗性的功能就是 BuildKit，原始碼可以參考這邊，希望未來這實驗性的功能可以正式納入 Docker 官方，網路上其實可以找到很多方式來做 Docker Layer 的 Cache，我個人最常用的就是 --cache-from 機制，可以適用在任何 CI/CD 流程，詳細說明可以參考這篇『在 docker-in-docker 環境中使用 cache-from 提升編譯速度』，下面使用到的程式碼都可以直接參考此 Repository，我還是使用 Go 語言當作參考範例。

相信各位開發者對於 GraphQL 帶來的好處已經非常清楚，如果對 GraphQL 很陌生的朋友們，可以直接參考之前作者寫的一篇『Go 語言實戰 GraphQL』，內容會講到用 Go 語言實戰 GraphQL 架構，教開發者如何撰寫 GraphQL 測試及一些開發小技巧，不過內容都是以 graphql-go 框架為主。而本篇主題會講為什麼我從 graphql-go 框架轉換到 gqlgen。

最近正打算使用 GitHub Actions 來串接 AWS 服務 (ECR + ECS)，上網找了一堆 ECR 套件，發現就連 AWS 官方都只有實作 Login 進 ECR，後面編譯跟上傳動作就需要自己寫，可以看看底下是 AWS 官方套件的範例:

去年 GitHub 推出 Actions，就有不少開發者相繼把 CI/CD 流程內會使用到的 Plugin 都丟到 Marktetplace，而在這 Docker 容器時代，肯定是需要用自動化上傳容器到 Docker Registry，而官方也在上週正式釋出第一版 GitHub Actions，雖然在 Marktet 尚有不少開發者已經有實現了此功能，但是官方既然推出了，就採用官方的套件會比較適合。底下我們來看看如何使用 Docker 推出的 GitHub Aciton 來自動化上傳 Docker Image。除了介紹如何使用 GitHub Action 上傳 Image 外，我也會拿 Drone 的 Docker Plugin 來進行比較。

在閱讀本文章之前，作者有寫過一篇『graceful shutdown with multiple workers』介紹了在服務停止前做一些正確的 Shutdown 流程，像是處理 Http Handler 或關閉資料庫連線等等，假設有服務內有實作 Worker 處裡多個 Job，那該如何等到全部的 Job 都執行完畢才正確關閉且刪除服務 (使用 Docker) 呢？底下是整個運作流程: