golangのお勉強11+goa

公式の説明を見る（goagen）

goagen：goa のツール · goa :: Design-first API Generation
https://goa.design/ja/implement/goagen/

bootstrap

bootstrap: app、main、client、swagger の各ジェネレータを呼び出します。

お、JavascriptAPIとかは生成しないので必要なら別で生成ね。

regen

goagen main でサービスを立ち上げて、新しいリソースやアクションがデザインに追加されたら、goagen main --regen を走らせて、既存のコントローラを保持しながら新しい空のコントローラ実装を追加する、というのが典型的なワークフローになるでしょう。
注: --regen を機能させるために、コントローラの実装は 必ず コメントの間に置かなければなりません。
再生成コードは、これらのコメントを頼りにして、保持すべき非 Scaffold なコードを見つけます。

なるほど。コメントの間に書くの大事。

goagen js

mzabriskie/axios: Promise based HTTP client for the browser and node.js
https://github.com/mzabriskie/axios

ブラウザでもNodeJSでも対応で、ブラウザ対応も手厚い、コールバックじゃなくプロミスのAjaxライブラリ。かな。
vue.js界隈でも使われているみたい。

schema

goa サービスにマウントして /schema.json の下でそれを提供できるように JSON とコントローラの両方を生成します。

へー。外部サービスとの連携とかにつかうのかしら。隠蔽すべきものは隠蔽されてるかな。

公式の説明(goagen以外で気になるところ)

goa のサービスを実装する · goa :: Design-first API Generation

全体的にどういう使い方を想定しているかのイメージが湧いて大事かも。

エラーハンドリング · goa :: Design-first API Generation

コントローラアクションは、デザインで定義された約定を実装する責任があることに注意してください。 つまり、アクション定義にリストされていない HTTP ステータスコードを使用するエラークラスを定義するべきではありません。

goa プラグインジェネレータ · goa :: Design-first API Generation

アルファベット順にソートされた API リソースの名前を含む names.txt というひとつのファイルを作成するジェネレータを実装してみましょう。

なるほど。そういうことができるのね。

ロギング · goa :: Design-first API Generation

ロギング周りの自由度は高くなっているみたい。
サービスでの使用とミドルウェアでの使用の分類があり、
DBなどからはgoaとの結合を疎にした別の関数経由でロギングしたらいいじゃない的なことが書いてあるけどまだよくわからん。

インスタンス化されるとすぐに、これらのアダプターの1つを利用して、サービスのロガーを goa に注入する必要があります。

セキュリティ · goa :: Design-first API Generation

goaには、Basic認証、APIキー（共有秘密鍵）、JWT、OAuth2など、複数のセキュリティスキームが組み込まれています。

アクションごとに認証を上書きもできるらしい。

gorma プラグイン · goa :: Design-first API Generation

gormを使えるプラグインらしい。。使いたいけどまだドキュメントも少ないって書いてるな。。
コントローラーでの独自でのDB操作の邪魔にならないなら使ったらいいのではないか。。

goのgoaでAPIをデザインしよう（Model編） - ぺい
http://tikasan.hatenablog.com/entry/2017/05/15/172535

カスタマイズ出来る
gormaってよくわかんないやつ嫌だなーと最初は思ってたんですけど、実はこいつはgormというORMのコードを自動生成してくれてるだけなので、gormの使い方を理解していればカスタマイズはいくらでも出来ます。

読んだところよさげ。

goのgoaでAPIをデザインしよう（Model編②） - ぺい
http://tikasan.hatenablog.com/entry/2017/05/22/214938

gormaを使えばよくあるクエリへの対応などは問題なく出来ます。ですが、どうしても無理な場面もあるので、やっている案件に発生するクエリの複雑さによって採用するかしないか決めるべきだと思います。

どうしても無理な場面ってどういうときだろう。

実際にモデルを作る

記事にあるサンプルをみないとわからなかった。。
apiのファイルとは別でmodel.goを作った。別名でもできた。

リレーションをしないとヘルパーは空になるので意義がわからない。
とりあえずサンプルを実行するのが良さそう。

tikasan/goa-simple-sample
https://github.com/tikasan/goa-simple-sample