Web DB Press 108号 の特集1スキーマ駆動 Web API 開発を読んだので自分なりのツールを紹介したりする

今やっている案件でドンピシャで OpenAPIを使ってのスキーマ定義駆動開発をやっていたので気になって今回の Web DB Press を購入した

 

WEB+DB PRESS Vol.108

 

ということで特集第１のスキーマ駆動についての感想というか個人的なまとめ？的なものである

 

 

気づいてみれば現在の会社に入社してからすぐにAPI の定義から先に作っていく開発手法を実践しているがSwaggerは使っていなかった

 

 最近始めた案件では Swaggerを使ったら更に高速に開発できるのではないかと試している

 

 手応えは上々で、いまのところいい感じにやっていけそうである

 

 

正直最初はかなり辛かった 

 

辛かった点

 

• 周辺ツールがいっぱいありすぎて何を選択したらいいのかがわからない 
• 基本とされている ペットショップの schema では参考にならない
• OpenAPI Version 2 の情報はあるけれどもバージョン3の情報はなかなか存在しない

 

 

 

1、2ヶ月してやっとツールの選択が 整ってくると投資した分の効率化は行えそうな手応えを感じている

 

ということで私の選択していった周辺ツールを紹介していきたいと思う

 

 

周辺ツールの話

書くときはローカルのエディターで行うのが一番良い

 

本書でも紹介されてるが、SwaggerEditor は分割されたファイルを使えないので、巨大な API を作る時にはかなり辛いように思う

 

 

分割されたyamlファイルは、最終的に結合しないと使えない場合がある(後述)

 

なので、OpenAPI generator のテンプレートであるopenapi-yamlを選択してビルドしている

 

なお、OpenAPI generator はDockerの環境で動かしている

 

 

 閲覧は色々試してみたのだが Swagger UI が一番見やすい

 

Swagger UI を動かす方法としてはDockerもあるのだが、実は静的にビルドされたファイルだけでも十分だったりする

 

https://github.com/swagger-api/swagger-ui/tree/master/dist

 

なので CI後に閲覧だけする環境としては静的なページの方を選択している

 

 

モックサーバはAPI Sproutを使ってみている

 

と言うかここら辺の内容は主にこちらの記事を参照させていただいている 

 

https://qiita.com/matsuda_chikara/items/a4119a972535a4b69201

 

 

ただし APISprouteは足りないと思われる機能がいくつかある

 

• CORSが効いていないこと
• Example に書いた内容がスタブサーバで出力できないこと 

 

実はこれは プルリクエストが飛んでいる内容なのだが一向にマージされる気配がない

 

どうやら作者が興味を失っているのではないかと思ってしまう 

 

それなので 自分でこの二つの重要な機能をマージしてリポジトリをフォークして使っている

 

そうするとswagger-all-in-one-docker-containerでのnginxでのプロクシの部分とかが要らなくなる

 

 

 

環境まとめ

 

ということで私は

 

エディター	ローカルのエディター (Intelli J IDEA)
ビューワー	Swagger UI
ビルド	OpenAPI Generator
モックサーバー	apisprout(フォーク改造版)

という構成でやっている

 

なお API スプラウトで読み込める辞めるファイルには制限があり、分割されたyamlファイルは受け付けられたことがない

 

結合しないと使えない場合というのはこの話だ

 

この点にはさわり始めた頃に大きくハマったので注意してもらいたい

 

 

 

他の章について軽く触れる

 

第3章 

のサーバ開発時のバリデーションについてなどは どうやるんだろうと思って疑問に思っていたことだったので、ここで見れてすごいちょうど良い機会だった

 

流石にスタブサーバは現在のサーバと乖離してるよなーと思っていたので、テストだけ定義とあっているか確認できるのは良いなと感じた

 

 

第4章

のGraphQL については フロント側としては非常に使いやすいのは分かる

 

だが、バックエンドの開発で本当に流行るのかという懐疑的なものはちょっとまだ胸に抱いている

 

• 実装例の少なさ 
• ちょっと実相を間違えると大量に負荷がかかりそう 
• など気がかりに思っている 

 

など、どうやっているのか実際に見てみたいなーと思う

 

 

しかしまぁGraphQL はフロントエンドの開発者としては非常に魅力的に感じる 

 

そこで個人的な興味からマネージドGraphQL サービスの AWS App Syncについて調査をしてみた

 

物自体は非常に良さそうなのだが dynamo DB が分からなすぎて辛かった

 

 

Aurora ServerlessをAppsyncのバックエンドとして使えるようになったので、試してみたいという気持ちはある

 

だが如何せんAurora Serverlessはちょっとお値段がかかりすぎるので、気軽に試せずにいる

 

WEB+DB PRESS Vol.108