目次
「郷(Go)に入れば郷(Go)に従え」
今さらですがGoに挑戦していきます。
実際のコードは次回より記載するとして、その考えに至った理由や昨今の環境について思うところを記載します。
バックエンドとフロントエンドで別々に実装、APIを通して結合するケースが増えてきました。
これはスマホアプリ版とウェブ版などを複数のフロントエンドにと連携する際に、共通のAPIを通してバックエンドとやりとりする方が工数の削減ができるという要因が多いと推測します。
APIサーバーを構築する場合も、慣れたフレームワークを使った方が工数的には効率的ですが、せっかくですからAPIサーバーに適した開発言語としてGo言語で実装に挑戦したいと思います。
フレームワークは何を使用するか？
Go言語では、まだフレームワークのデフェクトスタンダードは確定してません。
マイクロフレームワークから、MVCフルスタックフレームワークまで多々あります。
情報量や案件（ビジネスマッチングや求人情報）を見ると、GinかEchoなどのマイクロフレームワークが採用事例が多いようです。
またフレームワークそのものを使用しないケースも多いようです。
＜有名どころのGo言語のフレームワーク＞
マイクロフレームワーク
フルスタックフレームワーク
LaravelやRuby on Rails、PythonのDjangoのようなMVCフルスタックフレームワークが、Go言語であまり主流になっていない理由としては、上にあげたAPIサーバーとして活用されている事例が多いためだと思います。
DBにMySQLなどのRDBではなく、MongoDBといったいわゆるNoSQL系を採用するケースも多く、Viewの機能など使用しないなど、様々な構成で構築するからだと思います。
当面はEchoを採用
最初は一番メジャーと思われるGinのサンプルを試していました。
案件数で言えば歴史あるGinの方が多いようですが、公式ドキュメントがわかりやすく、将来的に使いそうな機能が掲載されており、なおかつ直近の勢いが伸びているEchoを採用することにしました。
ORMは何を使用するか？
例えばフルスタックフレームワークBeegoでしたら最初から独自のORMが実装されています。
しかしGinやEchoはORMを使いたい場合は、別で用意する必要があります。
＜Goで利用できるORM＞
Go言語のORMもまだデフェクトスタンダードは確定しておりません。
情報量としてはGORMが一番だと思いますので、基本的にGORMでいいと思います。
ただGORMの情報はv1(1.x)を元にしたものが多く、v2(2.x)について記載されているものはまだまだ少ないです。v1とv2では一部互換性がないので書き換える必要があります。
そもそもORMを使用するかどうか検討の予知があります。
ORMを使用すること自体に賛否両論あります。
個人的には使ってもいいと思っていますし実際使っていますが、ORMで表現できないときだけ生SQLをゴリゴリ書くハメになるとモヤモヤした気持ちになるのは確かです。
GORMですが当然MySQLなどのRDBにしか対応しておらず、DynamoDBやMongoDBといったいわゆるNoSQL系のDBには対応しておりません。
あと、どういうSQLが発行されるのかきちんと確認して実装しないと、とんでもない事故を起こす可能性があります。
RDBならGORM(v2)を採用
MySQLを使用したサンプルではGORM(v2)を採用していこうと思いますが、今後DynamoDBを使ったサンプルも試したいので、その際はGORMは使用しない形になります。
循環参照とアーキテクチャについて
GinとEchoでいくつか試して何度かハマったのが、「import cycle not allowed」（循環参照）のエラーです。
そもそもこれらマイクロフレームワークは、ディレクトリ構造がMVCのように定義されてません。
自由にできる反面、適当にディレクトリ分けしてimportしていると、循環参照エラーになります。
これはGoに限らないのですが、MVCフレームワークは最初から循環参照にならないように設計されているので、フレームワークのお約束を守れば問題ありません。
Clean Architectureを採用するか検討中
循環参照にならないような設計としてDDD（ドメイン駆動設計）やClean Architectureなどの設計手法があります。
正直これらの設計手法についてはまだ全く理解しきれてません。いろいろ調べてみた結果、ひとまず慣れたMVCではなくClean Architectureを採用しようかと思います。
GinやEchoでClean Architectureの設計思想を元にしたサンプルもあり、参考にさせてもらいました。
これらのほとんどの投稿者の方がメリット・デメリットを書かれているのですが、共通したデメリットとして、コード量とファイル数が大幅に増え、簡単なCRUDではメリットを感じにくいとのことです。
学習の初期にどういう設計思想で進めていくか？という点は結構重要です。サンクコストが積み上がっていくとそれが基準になるためです。Clean Architectureについても勉強していきたいと思ったため、時間工数としては決して効率的とは言えないですが採用することにしました。
ちなみにMVCで構築したいなら、最初からRevelかBeegoでいいかもしれません。
それでは次の記事で環境準備について記載していきます。
