スキーマファーストがなぜアツいと思っているのか

最近、自分のなかでアツいのはスキーマファーストの開発です。

まず、発端になった理由としては、前職も含めて会社ではswaggerを使用した自動生成を行っていましたが、個人での開発では使用していなかったので使用してみたかったから。
そして、自動生成のメリットだけを考えていたところ、Ginza.js#4でgRPC-WEBを触った話をLTでするために色々調べていたところ、スキーマファーストの考え方に出会いました。
- 登壇時の資料

その考えを知る前は、サーバサイドのControllerだけを自動生成するイメージでした。
システムのIFを先に定義することで、自システムのサーバサイド、フロントエンドだけでなく、対向システムもすぐにテストに取り掛かれるというのは素晴らしいメリットだと思います。
アジャイルジャパンでも、IFだけを先に定義しておいて、実装部分は各チームに任せたら素晴らしい功績を残せたという資料が展開されていました。
- アジャイルジャパンの30,31P

こじつけかもしれませんが、ソースの使い方を考えて開発をする。
という点を考えたら、インターフェースのTDDと言えるのではないでしょうか？

実際にスキーマファーストを意識してopenAPIを使った開発をしたものの、こうしておけばよかった、という点を以下に記載していきます。

結論　

最後までリリースしてから作りこもう今回はAWSのAPI gatewayを突破してから作りこむのが得策だった。

経緯

ローカルとサーバの自動生成できるyamlを作成する
ローカルでフロントとサーバを自動生成ソースで接続確認する
サーバをAWS EC2にデプロイする
ローカルのフロントとEC2のサーバを接続確認する
openAPIの$refを使って、yamlを細分化した。
フロントをFirebaseにデプロイする
FirebaseとEC2の接続確認をしようとしたが、httpsからhttpへの接続ができない
クラウドフロント、ロードバランサ―、API gatewayがサーバ側のhttps化の候補に挙がる
AWS API gatewayを採用
が、yamlを細分化したために、直接AWSへアップロードできず。
結局、yamlを結合するしてからAWSにアップロードする必要があった。