GoのWeb Application Framework, ミドルウェア, Contextについて

小野マトペ @ono_matope

@sona_tar アプリケーション内での共通処理が認証だけの場合はこの例のようになると思います(MustAuthとAuthは同一型のフラグで振り分けてもいいかもですが)。自分の場合はログ、エラーレスポンス送信なども共通化したいので多機能なBaseを作る感じになります。

小野マトペ @ono_matope

@sona_tar 「多機能なBaseパターン」で「ハンドラごとに認証の要不要がある」の場合、走り書きですがこんな感じでしょうか(認証エラーをログに落とせないなどいろいろ問題ありますが)。 play.golang.org/p/7qBZz1n7bE

sonata@private @sona_tar

@ono_matope ありがとうございます！　私もちょうど書いていました😃　この方が素直ですね　play.golang.org/p/nthd64Ovx0　先ほどの認証ハンドラを分ける方式だと、共通処理がある場合に3つの認証ハンドラに同じ処理を書くことになるのでむしろ冗長ですね

小野マトペ @ono_matope

@sona_tar おお、ですです。だいたいこの形に落ち着くのがいいんじゃないかというのが自分の見解ですね。

sonata@private @sona_tar

golangのwebアプリ開発でなんでもmiddlewareにしたくなってしまうのは、GoFを勉強してなんでもデザインパターンを適用したくなるのと似ている　使いどころ考えないとなー

sonata@private @sona_tar

@ono_matope 勉強になりました！　やっと自分の中で整理がつきつつあります　日本だとみんな気軽にWFA使っていて、ここら辺を議論している人が見つからなかったので大変助かりました　どのWFAが良いのかの前にいろいろ考えることがあると思うんですよねー

小野マトペ @ono_matope

@sona_tar 僕も日頃考えていた事が整理でき、かつ分かってもらえて良かったです！3rd party WAFに乗るとライフタイムも標準ライブラリより短いし、未知のコードも増えるし、net/httpでやりきるのがGo Wayっぽいなーと思う次第です。

sonata@private @sona_tar

@ono_matope Go Wayは常に意識してコードを書いていきたい！ WAFの未知が気になってコードを読むと必要ないと思う処理が多いので、参考に留めて自分なりに実装していきたいですね あとOSSとしてリリースするなら第三者にあまりフレームワークを強要したくないですね

sonata@private @sona_tar

Go1.7で追加されたWithContextを使うことでmiddleware間でパラメータ渡しができるようになったという話　medium.com/@matryer/conte…　しかしそれはやめるべきだという話　peter.bourgon.org/blog/2016/07/1…

sonata@private @sona_tar

今回の.@ono_matope さんとの議論では「Go1.7で追加されたWithContextはmiddleware間のパラメータ渡しで使っても良いか」と「そもそもMiddlewareはどのように使うべきか」の話があるので混同しないようにお気をつけください