今となって後悔しているkamiのこと #Go

クリスマス期間になると喜ぶ人もいれば悲しむ人もいる。そんな極端な季節の中で、自分が作ったguregu/kamiというWAFについて真面目に考えた。contextの正しい使い方や、kamiのAPIで後悔していることを晒そう。

kamiを作ったきっかけ

まずはkamiの歴史について簡単に説明する。GunosyでアプリのAPIサーバーをRailsからGoに少しずつ書き直していたが、モノリシックだったmodelsとhandlersパッケージが大きくなりすぎて分かりにくくなってしまった。大きいパッケージを複数の小さなパッケージに分けようと思った。しかしユーザーのセッション情報などは様々なパッケージにどう共有したらいいでしょう？

当時使っていたGojiというWAFでは、リクエストごとにEnvというmap[string]interface{}が付いていた。これを使えば、どんなパッケジーにHTTPハンドラーやミドルウェアを入れてもEnvにあるデータの共有ができた。しかし文字列のキーは被りやすいし、各ハンドラーでinterface{}から無理やり変換するのも気持ち悪いと思った。

Go 1.5が出た頃にx/net/contextというパッケージが登場した。今は標準化されてcontextになっている。contextはgoroutineのキャンセル処理を管理する機能と、”リクエストスコープ”のデータをmapのように扱う機能が付いている。contextのデータ共有機能を使ったら、GojiのEnvの問題を解決できる。

このcontextパターンでinterface{}の気持ち悪さから逃れる。

package user

import "context"

// 共有したいデータ。これをcontextに入れる。
type User struct {
    ID int 
    // ...
}

// userKeyは小文字なので他のパッケージはuserKeyを使えない。
// つまり、このパッケージだけはcontextの中のUserがいじられる。
// 他のパッケージと被ることもない。
type userKey struct{}

// contextに入れる
func NewContext(ctx context.Context, u User) context.Context {
    return context.WithValue(ctx, userKey{}, u)
}

// contextから出す
func FromContext(ctx context.Context) (User, bool) {
    u, ok := ctx.Value(userKey{}).(User)
    return u, ok
}

Gojiの一部にcontextや違うルーターやURLベースのミドルウェアの仕組みを適当に足して、kamiが生まれた。

後悔その１・標準ライブラリとの互換性を破った

早速本題に入ろう。標準ライブラリのHTTPハンドラーはこうなっている。

type HandlerFunc func(ResponseWriter, *Request)

しかしGo 1.7までは*http.Requestにcontext.Contextが入っていなかった。

kamiのハンドラーはこうなっている。

type HandlerFunc func(context.Context, http.ResponseWriter, *http.Request)

これでcontextは使いやすくなるが、kamiのために書いたハンドラーとミドルウェアは他のWAFで使えなくなってしまう。

当時は破るしかなかったと思うが、Go 1.7が出た瞬間にkamiがレガシーソフトになってしまった。Go 1.7が出るまでにkami 2.0を作って標準に従えばよかった。後悔している。

後悔その２・contextの許せないアンチパターンを提供した

kami.Contextか*kami.Mux.Contextを変えることによって、全てのリクエストのベースコンテキストを設定できる。つまり、リクエストスコープじゃないデータを簡単にcontextに入れられる。*sql.DBとかモデルのレポジトリを入れるために用意してしまった。今やこのcontextの使い方はアンチパターンとして認識されている。やっぱりリクエストの事前にcontextをいじるのはアウトだ。後悔している。

後悔その３・contextを自動的にcancelしなかった

Go 1.7以来、*http.Requestにあるcontext.Contextは自動的にcancelされる。しかしkamiのデフォルトではcancelされない。リクエストが終わったらcancelするという仕組みはとても便利。たとえば途中で切れたリクエストで無駄なDBクエリーをしないためなどに使える。フラグにしなきゃよかった。後悔している。

後悔その４・APIに`interface{}`の乱用

これはGojiを真似てやったが、kamiのHandle系API（kami.Get, kami.Postなど）はkami.HandlerTypeの引数を受け取る。kami.HandlerTypeは実はinterface{}で、実行時に無理やりkami.HandlerFuncに変換される。http.HandlerFuncやhttp.Handlerとか色々な型を渡せる。変換できない場合は起動時にパニック。

Goはせっかく型があるので正しく使おう。net/http.Handlerのように、全てを一つのインターフェスにまとめればよかった。後悔している。

後悔その５・Gojiに依存しすぎた

kamiのLogHandlerとAfterwareはそのままgithub.com/zenazn/goji/web/mutil.WriterProxyを使っている。その長いパスをわざわざインポートしないといけないユーザーは可哀想に思うようになった。kami.WriterProxyにすればよかった。申し訳ない。後悔している。

後悔その６・新しいバージョンの提供が難しかった

kamiを作った当時はバージョン管理が大変だった。ビルドするたびにGitHubからHEADをダウンロードするユーザーが多かった。互換性のないv2をプッシュしたら、たくさんの人に迷惑かけてしまうことになると思った。ビルドを壊せないために、イマイチなAPIを残すしかなかった。結局は進化出来ないライブラリになった。後悔している。

最後に

かなり暗い記事になったが、私は後悔＝学習体験だと思っている。今でもkamiを使っているし、作ってよかったと思う。ただしアンチパターンを使わないように気をつけてほしい。
kamiで失敗したことを全て熟考して、近いうちに新しいkamiを出したい。
皆さんの意見を待っています！

今となって後悔しているkamiのこと