経緯
僕、普段はPythonとDjangoを使って 引きこもりしつつ飛び上がり自殺を考えながら 独自にwebアプリを書いているのですが、最近ではRailsでもSinatraでもFlaskでもDjangoでもPyramidでもなく、Goとそのフレームワークを使ってバックエンドコードを書いている(ように見える)ウェブアプリが見られます。
Goは並列処理がお得意な言語ということでよく知られていますが、今回、実際にGoでコードを書いてみて分かった事をまとめてみました。
書いたコード
使ったフレームワーク
分かったこと
Go言語そのものについて
Go言語それ自体は並列処理が言語機能の一つとして実装されているという点を除けば、非同期処理を得意とする他の言語（NodeJSなど)とほぼ同じような感じ？の印象を受けました。しかし、コンパイル型かつ並列・非同期処理が得意な言語という事で、Pythonなどと比べてウェブアプリを実装する時に飛躍的なスループットの向上が見込めるように思えます。(小並感
フレームワークについて
- 標準ライブラリ(
net/httpなど)はやっぱりWeb開発用途を意識されているようです。でも、DjangoのMiddleware的な概念はchiなど他のライブラリを使わないと面倒でした(小並感 - GinはRESTful APIを書く時には使えると思いました。が、Restful APIを書くんだったらOpenAPI Generatorを使うよね、うん。
- GormはPythonで言うところのSQLAlchemy、Djangoで言うところのModel的な存在です。そして、ORMとしてのGormは至極普通でした。が、AutoMigration機能がDjangoのそれとは劣ります。(GormのAutoMigrationとDjangoのMigrationの比較参照)
-
GQLGenでResolverを書く時に
ResponseWriterを参照できない。つまり、Backendとして認証機能を実装する場合はフロントエンド側でひと手間掛ける必要がある？(例: セッションのJWTをフロントエンドへペイロードとして渡してフロントエンド側でこいつをCookieなりヘッダなりにぶちこむ) - 認証機能はモノリシックに作るのではなく、別にライブラリとして提供したほうが良さそう。
GormのAutoMigrationとDjangoのMigrationの比較
| 機能 | Gorm | Django |
|---|---|---|
| Tableの自動追加 | ✔ | ✔ |
| Tableの自動削除 | ❌ | ✔ |
| Tableの自動リネーム | ❌ | ✔ |
| カラム自動追加 | ✔ | ✔ |
| カラム自動削除 | ❌ | ✔ |
| カラム自動変更 | ❌ | ✔ |
| マイグレーションのバージョニング | ❌(但しサードパーティー製ライブラリで対処可能？) | ✔ |
| マイグレーションの自動生成 | ❌(その概念がない？) | ✔ |
| マイグレーションの手動記述 | ✔ | ✔ |
...GormのAutoMigrationは実用に値しない？ORMの機能だけ頂いてMigration Manager的な代物を書いたほうが良さそう。
まとめ
GolangはAPIの開発には良さげだと思われますが、現状ではWebアプリのバックエンドとしての利用は難しい？ように思えました。また、Djangoではモデルデータの管理の為の画面(django.contrib.admin)があり、Golangも同様の機能が提供されている(QOR)ようですが筆者がこれを利用しようとしたところ、GQLGenの仕様？によってうまく使えませんでした。
と、いうわけで、Golangはセッション、SQLのスキーママイグレーション、モデル管理を解決できればメインで使える言語に出来るんじゃないかと思いました まる