gofight 支援多個檔案上傳測試

Go-Logo_Blue

gofight 是一套用 Go 語言撰寫的 HTTP API 測試套件,之前已經寫過一篇介紹用法,當時候尚未支援檔案上傳測試,也就是假設寫了一個檔案上傳的 http handler 在專案內如何寫測試,底下來看看該如何使用。

Continue reading “gofight 支援多個檔案上傳測試”

Go 語言專案程式碼品質

Screen Shot 2018-03-17 at 11.40.12 PM

本篇想介紹我在寫開源專案會用到的工具及服務,其實在編譯 Go 語言同時,就已經確保了一次程式碼品質,或者是在編譯之前會跑 go fmtgo vet 的驗證,網路上也蠻多工具可以提供更多驗證,像是:

  • errcheck (檢查是否略過錯誤驗證)
  • unused (檢查沒用到的 func, variable or const)
  • structcheck (檢查 struct 內沒有用到的 field)
  • varcheck (拿掉沒有用到的 const 變數)
  • deadcode (沒有用到的程式碼)

但是這麼多驗證工具,要一一導入專案,實在有點麻煩,我自己在公司內部只有驗證 go fmtgo vetmisspell-check (驗證英文單字是否錯誤) 及 vendor-check (驗證開發者是否有去修改過 vendor 而沒有恢復修正)。如果你有在玩開源專案,其實可以不用這麼麻煩,導入兩套工具就可以讓你安心驗證別人發的 PR。底下來介紹一套工具及另外一套雲端服務。

Continue reading “Go 語言專案程式碼品質”

Go 語言的 graphQL-go 套件正式支援 Concurrent Resolvers

GraphQL_Logo.svg

要在 Go 語言寫 graphQL,大家一定對 graphql-go 不陌生,討論度最高的套件,但是我先說,雖然討論度是最高,但是效能是最差的,如果大家很要求效能,可以先參考此專案,裡面有目前 Go 語言的 graphQL 套件比較效能,有機會在寫另外一篇介紹。最近 graphql-go 的作者把 Concurrent Resolvers 的解法寫了一篇 Issue 來討論,最終採用了 Resolver returns a Thunk 方式來解決 Concurrent 問題,這個 PR 沒有用到額外的 goroutines,使用方式也最簡單

"pullRequests": &graphql.Field{
    Type: graphql.NewList(PullRequestType),
    Resolve: func(p graphql.ResolveParams) (interface{}, error) {
        ch := make(chan []PullRequest)
        // Concurrent work via Goroutines.
        go func() {
            // Async work to obtain pullRequests.
            ch <- pullRequests
        }()
        return func() interface{} {
            return <-ch
        }, nil
    },
},

使用方式

先用一個簡單例子來解釋之前的寫法會是什麼形式

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "time"

    "github.com/graphql-go/graphql"
)

type Foo struct {
    Name string
}

var FieldFooType = graphql.NewObject(graphql.ObjectConfig{
    Name: "Foo",
    Fields: graphql.Fields{
        "name": &graphql.Field{Type: graphql.String},
    },
})

type Bar struct {
    Name string
}

var FieldBarType = graphql.NewObject(graphql.ObjectConfig{
    Name: "Bar",
    Fields: graphql.Fields{
        "name": &graphql.Field{Type: graphql.String},
    },
})

// QueryType fields: `concurrentFieldFoo` and `concurrentFieldBar` are resolved
// concurrently because they belong to the same field-level and their `Resolve`
// function returns a function (thunk).
var QueryType = graphql.NewObject(graphql.ObjectConfig{
    Name: "Query",
    Fields: graphql.Fields{
        "concurrentFieldFoo": &graphql.Field{
            Type: FieldFooType,
            Resolve: func(p graphql.ResolveParams) (interface{}, error) {
                type result struct {
                    data interface{}
                    err  error
                }
                ch := make(chan *result, 1)
                go func() {
                    defer close(ch)
                    time.Sleep(1 * time.Second)
                    foo := &Foo{Name: "Foo's name"}
                    ch <- &result{data: foo, err: nil}
                }()
                r := <-ch
                return r.data, r.err
            },
        },
        "concurrentFieldBar": &graphql.Field{
            Type: FieldBarType,
            Resolve: func(p graphql.ResolveParams) (interface{}, error) {
                type result struct {
                    data interface{}
                    err  error
                }
                ch := make(chan *result, 1)
                go func() {
                    defer close(ch)
                    time.Sleep(1 * time.Second)
                    bar := &Bar{Name: "Bar's name"}
                    ch <- &result{data: bar, err: nil}
                }()
                r := <-ch
                return r.data, r.err
            },
        },
    },
})

func main() {
    schema, err := graphql.NewSchema(graphql.SchemaConfig{
        Query: QueryType,
    })
    if err != nil {
        log.Fatal(err)
    }
    query := `
        query {
            concurrentFieldFoo {
                name
            }
            concurrentFieldBar {
                name
            }
        }
    `
    result := graphql.Do(graphql.Params{
        RequestString: query,
        Schema:        schema,
    })
    b, err := json.Marshal(result)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%s", b)
    /*
        {
          "data": {
            "concurrentFieldBar": {
              "name": "Bar's name"
            },
            "concurrentFieldFoo": {
              "name": "Foo's name"
            }
          }
        }
    */
}

接著看看需要多少時間來完成執行

$ time go run examples/concurrent-resolvers/main.go | jq
{
  "data": {
    "concurrentFieldBar": {
      "name": "Bar's name"
    },
    "concurrentFieldFoo": {
      "name": "Foo's name"
    }
  }
}

real    0m4.186s
user    0m0.508s
sys     0m0.925s

總共花費了四秒,原因是每個 resolver 都是依序執行,所以都需要等每個 goroutines 執行完成才能進入到下一個 resolver,上面例子該如何改成 Concurrent 呢,很簡單,只要將 return 的部分換成

return func() (interface{}, error) {
    r := <-ch
    return r.data, r.err
}, nil

執行時間如下

$ time go run examples/concurrent-resolvers/main.go | jq
{
  "data": {
    "concurrentFieldBar": {
      "name": "Bar's name"
    },
    "concurrentFieldFoo": {
      "name": "Foo's name"
    }
  }
}

real    0m1.499s
user    0m0.417s
sys     0m0.242s

從原本的 4 秒多,變成 1.5 秒,原因就是兩個 resolver 的 goroutines 會同時執行,最後才拿結果。

心得

有了這功能後,比較複雜的 GraphQL 語法,就可以用此方式加速執行時間。作者也用 MongoDB + graphql 寫了一個範例,大家可以參考看看。

在 PostgreSQL 時區轉換及計算時間

2000px-Postgresql_elephant.svg 通常在使用資料表時,都會在每一筆紀錄上面寫入當下時間,而這個時間會根據目前系統所在的時區而有所不同,當然我們都會使用 UTC+0 作為標準時區,而欄位我們則會是使用 timestamp 或者是 unix time 格式,兩者最大的差異就是在前者 (timestamp) 會根據目前系統的時區來記錄,而後者 (unix time) 則是紀錄秒數差異 (Jan 01 1970) 而不會隨著系統時區改變而變化。如果是發展開源專案,則會使用後者居多,這樣不會因為使用者時區變化,而產生不同的差異,在 Gitea 開源專案保留了兩者,但是只要計算時間則是用 (unix time) 作轉換。 Continue reading “在 PostgreSQL 時區轉換及計算時間”