結論としては、v3に移行せずv1をforkしてカスタマイズしていく方針を検討中です
（続報あったらまたなんか書きたいと思います）
もし、新規でGoaの導入を検討しているのであればv3を使うことをおすすめします。
今回は、自分のようにv1 -> v3の移行検討してる方の参考になればと思い、なぜ移行しないことにしたのかをまとめました。
移行したかった理由
- v1はgo.modもなく、外部ライブラリも不安定でいつ動かなくなるのか不安
- 上記の理由に含まれるかもしれないが、メンテされることはなさそうなのでGoのバージョンアップに伴い動作しなくなったりしたら運用でカバーすることになりそう
移行を諦めた理由
- v1 -> v3でtestのコード生成がなくなった（これが一番痛い）
- v3からgRPCに対応したのが移行する一番のメリットっぽいが、gRPCでの利用を検討しているのならConnectなどを採用したほうが良いと自分は考えており、ライブラリが安定する以外に移行するメリットを特に感じなかった
- GoaDSL自体のv1 -> v3移行はそこまでコスト高くないと感じたが、middlewareやService周りの移行コストがそれなりに高く感じた。また手作業なので、すべてのAPIで挙動が変わってないことを担保するテストが既に用意されている必要がある
移行の選択肢
- 案1: 愚直に既存のGoa v1依存で書いたテストのGoa依存を剥がしてtestを書き直してから、Goa v3に移行していく
- 案2: Goa v3でv1のtestコード生成と同じようなtestコードの生成を自作して、置き換えたのちにGoa v3に移行していく
- 案3: インフラ側で、新旧両方のコンテナ等を用意（サーバーのコスト2倍を許容）し、移行期間中はロードバランサーでendpointに応じて新旧に振り分ける形で徐々に移行していく（問題があったら古いほうに向けることもできる）
案1は、かなり時間がかかるため新規の開発を止めるような判断も必要になると思います。そのため案3との併用が必要となり、費用面や運用面でもかなり大変になります。
案2は、コード生成がうまくいけばという感じで、そこが失敗するとそもそも移行が頓挫しますのでそれ次第ということになりそう。gRPCのことも考慮するとだいぶ大変なので、おそらくHTTP専用の生成ツールを自作する感じになると思います。
個人的にはテスト周りのコード生成はv1の時点で結構手をいれたかったのもあり、案2で行く気が結構あったんですが、冷静に考えるとこの生成ツール作るコストがGoa v1をforkしてカスタマイズしていくコストより圧倒的に高そうと感じて魅力がなくなりました。
案3は、1〜2年くらいかなり長期スパンになる気がします（現状のAPIの本数次第ですが）新しく実装するものはv3で実装し、少しずつv1 -> v3も移行みたいな感じでやっていくイメージになると思います。 この手の移行は、サービスの障害発生時などの原因切り分けなどの調査速度などにも影響するので素早く移行したいので厳しい。
別のサーバー言語にして採用などにも効かせるような移行やWAFを置き換えることで、開発体験向上が大きく見込めたり、パフォーマンス改善などが見込めるならまだしも、Goa v1 -> v3では特に移行メリットが薄く長期の移行作業はコスパが悪いと考えました。
まとめ
Goa v1 -> v3の移行ですが、できるならやったほうがいいと思います。
v3は、かなり安定したライブラリになってると思います。
v1で生成されたtestのコードを利用せずに自前でendpoint毎の正常系/異常系testをちゃんと書いていれば、1ヶ月くらいガッとやれば移行できるんじゃないかな〜という肌感です。