/ kyokomi note / blog

Goa v1 -> v3の移行について検討してみた

January 22, 2023 [Go]

結論としては、v3に移行せずv1をforkしてカスタマイズしていく方針を検討中です

(続報あったらまたなんか書きたいと思います)

もし、新規でGoaの導入を検討しているのであればv3を使うことをおすすめします。

今回は、自分のようにv1 -> v3の移行検討してる方の参考になればと思い、なぜ移行しないことにしたのかをまとめました。

移行したかった理由

移行を諦めた理由

移行の選択肢

案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ヶ月くらいガッとやれば移行できるんじゃないかな〜という肌感です。

last modified January 22, 2023