Go http framework所感
golangのhttp framework評をみて思うところがあったので個人的な意見を書く｡
そこそこの期間メンテナンスするようなものを想定｡
結論から言うと net/http でがんばる派｡
中長期のメンテナンスを考えるとフレームワークに振り回されるのはあまり得策でないと思う｡
ただ､利便性を考えるとユーティリティの作り込まれたフレームワークを採用するのは悪くないとも思う｡
結局は用途によるのでこのフレームワーク最高みたいなのは無い｡
スピード
まず､frameworkのスピードはさほど重要ではないと思う｡
なぜならボトルネックはframeworkの外(つまり自分のコード)だから｡
マイクロベンチがどれだけ早かろうがあなたの書くコードがそれを台無しにする｡
なので利便性とメンテナンス性に重きを置くのが良いと思う｡
利便性
例えばURLのパスからパラメータを取り出したり､柔軟なルーティングは標準ライブラリに無い｡
本当に必要ならルーティングだけ行うライブラリを使うという手もある｡
標準ライブラリに足りないものだけ個別ライブラリを足すというのもありだと思う｡
一方で個別ライブラリが山のように必要になるならフレームワークを使う感じかなと考えている｡
中長期のメンテ
一昔前はmartiniが有名だったが､もう誰も使わないと思う｡
結局サードパーティライブラリは入れ替わりが激しいので廃れてからメンテするのが大変｡
echo/gin は今この瞬間使うには非常に良いと思うが､将来を考えるとなんとも言えない｡
あとirisは権利問題もそうだしオーナーが信頼できないので...まず使うことはない｡まさに宗教上で､という感じ｡
fasthttpみたいな変化球もずっとメンテされるのかよくわからない｡
特定プロジェクトがいろいろな意味で良さそうかどうかを判断するのは難しい､数が多ければなおさら｡
メンテナンスだけで見れば標準ライブラリに分があるのは間違いないと思う｡
まとめ
現状､goにはrubyにおけるrailsのように､ - dbからhtml生成までフルスタックで面倒を見てくれる - 地位を確立しており将来的なメンテナンス性もある程度安心できる
ようなフレームワークはない｡
こういったものがあればガッツリ依存していくのも一つの選択肢かと思う｡
beegoが割と近いイメージなのかなと思うが､実際にはあまり使われてなさそう｡
そもそもgo使う人がこういうの好まないイメージ(偏見)
最終的にはケースバイケースなので各自で用途をベースに考えるのが重要だと思うという前置きをした上で､
net/httpに必要なものを足せばだいたいバランスが良くなるかなと思う｡
