Go APIサーバーの設計について、golang.tokyo#9で話しました。

どうも、Gunosyの新規事業開発室エンジニア、高橋（@__timakin__）です。先日行われたgolang.tokyo#9にて、GoのAPIサーバーの設計についてトークをする機会を頂いたので、いってきました。スライドはこちらです。全編英語となっておりますが、ご覧頂けると幸いです。

アジェンダの前の序文にも書いてあるのですが、GoのAPIが大企業で試験的に導入するというフェーズを超え、スタートアップなどでも「Goって最近トレンドだよね」という声が聞こえ、小規模のチームでも積極的に登用されるようになってきたように感じます。

あくまで個人の観測範囲での話なのでバイアスがあるとは思いますが、「試してみた」というトークが界隈でも最近少なくなったように思います。

そんな中、参考例となるGoのAPIのOSSは非常に少ないため、新規に始めるハードルは、学習コストの面で少し高いように思います。

ましてやフレームワークを使わずに標準パッケージ(net/http)で書くのがベターとされておりますし、ネット上に転がるサンプルもpingしてみた系が多いので、自分で書くときは結構困りました。

そこで、標準パッケージに極力寄せつつどうやって書くかに加えて、ディレクトリ構成に神経質にならなければならないGoで、どういうレイヤー化を行えばいいか、というのを自分なりに試行錯誤したのが上記のスライドの内容になります。

今回はgodddというGoのDDDのサンプル実装（DDD界隈の人からしたらちょっと毛色が違うらしいのですが）を参考例に、自分でAPIを書いて見たときのベストプラクティスを発表しました。

ただ、DDDというとinfrastructureに該当するものがまだ明確に定まってなかったり、より一層スケールしたときの話を仕切れなかった部分がありました。

また、せっかく英語でスライドを書いたので、海外のサイトに投稿したら、「これはDDDというより一種のレイヤー化に過ぎないのでは？」というツッコミをもらいました。

自分でも「いくらgoddd inspiredとはいえ、無理にDDDって言わなくてもいいな」、という立ち位置を自覚する機会を得ました。

ただ、パッケージの粒度的には書いててスムーズに行けたので、今後もこれをベースに、ブラッシュアップしていく形でAPIの設計を考えていきたいと思います。

他にもDDDっぽい書き方を採用している方が何人かいらっしゃるのを知っているので、「ぼくのかんがえたさいきょうのGo API せっけい」でバトルするのも面白いかもしれません。

Goが本番で採用され、ある程度枯れ始め、Go2の展望も伺える中、ベストプラクティスというのはまだまだコミュニティでも公になっていません。

たとえバッドノウハウでも自分の設計を世に出して、レビューいただくことで、今は磨き上げるしかないのです。

ただ、コミュニティの方が「今Goの界隈に足りないもの」をどんどん発信していることも実感しているので、Goの将来は明るいなと楽観視しています。

少し時間が経てば僕のノウハウもバッドになるかもしれませんが、今できるだけを発表したので、同じくGoのAPIを書かれる方々の一助になれば幸いです。

Gunosyでは現在、「ぼくのかんがえたさいきょうのGo API せっけい」を一緒に考えつつ、Goで新規プロダクトをバリバリ開発してくれる方を募集しています。

もしちょっとでもご興味あれば、ぜひオフィスまで遊びにいらしてください！

Twitterでメンションしていただければ、気軽にランチなど行けるので、それもぜひ！

Gunosy Tech Blog