GoでオススメのWebフレームワークを聞かれることが多い

June 27, 2021

なぜWebフレームワークが必要とするのか

Webフレームワークを使った開発が当たり前であるプログラミング言語はたくさんあります。GoはどちらかというとWebフレームワークはいらないんじゃない?と言われることが多く、そう言われると初学者はいきなり難しいことをさせるなと思うかもしれません。

確かにフレームワークがあることでWebアプリが作りやすくなることがあるかもしれません。テンプレート通りに作れば作りたいものができるという体験はプログラミング言語を学び始めたばかりであれば重要です。フレームワークの枠に収まる開発であれば効果を発揮します。

しかし、「GoでオススメのWebフレームワークはありますか?」って聞かれる場合の多くは、Webアプリはフレームワークがないと開発できない、またはそうするのが当然だと思って質問している場合も多く見かけます。○○env系のツールと同様に、特に理由は無いけどそういうものでしょという感覚で探してるのかなと思います。

複雑さの増大

Goの学習が目的であれば、なおさらWebフレームワークを用いずにnet/httpパッケージを用いて開発するほうがよいでしょう。net/httpパッケージ用いて開発し、そこで足りないものを補う形でフレームワークやライブラリを導入する方が効果的です。

net/httpパッケージだけであっても十分大規模なものは作れます。その上でルーティングが不便だな、セッションの管理が面倒だな、などを感じればそれを補う必要十分なライブラリを導入すれば良いでしょう。スキーマ駆動で開発したければ、gRPCやGraphQLを用いて開発するのも手でしょう。

外部モジュールへの依存は、自分のモジュールの複雑さを増大させます。筆者は、Webフレームワークの利点は、複雑さの増加を容認し、それと引き換えにEasyさを手に入れることにあると考えます。そのため、Webフレームワークを利用していても、提供されている枠を超えるような使い方をすれば、本来の目的であるEasyさを逸脱してしまいます。しかし、残念ながら筆者の経験では、プロダクションコードでその枠に収まりきることは稀ではないかと思います。

Goコミュニティはシンプルさを大切にしています。シンプルであれば学びやすく、スケールしやすく、変更しやすいでしょう。ライブラリやフレームワークを導入することで少なからず複雑さは増大します。複雑さの増大と利便性を天秤にかけて、利便性の方が高い場合は導入するとよいでしょう。

筆者も形から入るタイプなので、キャンプを始めるのにキャンプ道具から揃えがちですが、一旦立ち止まってキャンプはナイフ1本、Webアプリはnet/httpパッケージから始めてもいいんじゃないでしょうか。不便さを感じたらポチッと道具を増やしていけばいいと思います。

そんなことを言いながらネットでマキタの保冷庫(CW180DZ)を物色しています。