Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Swagger (OpenAPI 2.0) を使ったAPI仕様Drivenな開発 / API-...
Search
Spring_MT
October 18, 2018
Technology
9
3.4k
Swagger (OpenAPI 2.0) を使ったAPI仕様Drivenな開発 / API-Spec-Driven development with Swagger
Spring_MT
October 18, 2018
Tweet
Share
More Decks by Spring_MT
See All by Spring_MT
Deep Environment Parity CDNT 2019
spring_mt
5
3.3k
環境の一致について考えてみる / Environment Parity
spring_mt
4
7.2k
1人でできる Docker Kubernetes(GKE)を 使った新規サービス立ち上げ / Docker and Kubernetes(GKE) for new services
spring_mt
19
7.6k
CI CD Test on ReRep
spring_mt
3
3.3k
Rails on GKEで運用する Webアプリケーションの紹介/Rails on GKE
spring_mt
0
460
新規事業立ち上げからマイクロサービスについて考えてみる
spring_mt
1
1.1k
hpbn_3
spring_mt
0
110
backbone.jsの使用例 その1
spring_mt
0
340
chef-soloの簡単な使い方
spring_mt
4
970
Other Decks in Technology
See All in Technology
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
830
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership, regardless of position
madoxten
25
16k
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
220
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
250
手を動かしてレベルアップしよう!
maruto
0
260
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
190
リクルートのエンジニア組織を下支えする 新卒の育成の仕組み
recruitengineers
PRO
2
190
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
550
フォーイット_エンジニア向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
1
1.7k
アジリティを高めるテストマネジメント #QiitaQualityForward
makky_tyuyan
1
470
Snowflake ML モデルを dbt データパイプラインに組み込む
estie
0
120
完璧を捨てろ! “攻め”のQAがもたらすスピードと革新/20250306 Hiroki Hachisuka
shift_evolve
0
140
Featured
See All Featured
Gamification - CAS2011
davidbonilla
80
5.2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
580
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
4 Signs Your Business is Dying
shpigford
183
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Making Projects Easy
brettharned
116
6k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Transcript
Swagger(OpenAPI 2.0)を使った API仕様Drivenな開発 春⼭ 誠 Makoto Haruyama 銀座Rails #2
2008 - DeNA⼊社 2010 - エンジニアに転向 2011 - DeNA退社 →
福岡で新規サービス⽴ち上げ 2013 - DeNAに出戻り 2016 - ゲーム事業本部 2017 - コマース&インキュベーション事業本部 SpringMT Spring_MT 春⼭ 誠 Makoto Haruyama
サービス&チームについて API仕様Drivenな開発 • Swaggerを取り⼊れた開発フローについて 振り返り • 開発スケジュール/不具合はどうだったか/QAからのフィードバック • 今後の課題 まとめ
⽬次
サービス&チームについて
None
メンバー構成 全体で5名 開発メンバーは2名 • サーバー∕インフラ担当 — 1名 • クライアント担当 —---------1名
サービスの構成 APIサーバー • Rails クライアント • 設計段階からWeb, iOS, Androidに対応することを想定 •
少⼈数で対応することを考えて初期からReact Nativeの採⽤を検討 • Web(JS)はReactベースのSPA (APIサーバーとは独⽴)
開発タイムライン
できるだけ早くかつ 何度も検証プロセスを回したい
開発タイムライン
開発スピードをあげるには どうするのが最適?
クライアントとサーバーの開発を なるべく並列で進められるようにする
よくあるパターン
今回はこうしたい
こうしてみました APIの仕様を開発時に利⽤しやすい形で整備する • メンテナンスがしやすいツールを導⼊ • 開発時に参照しやすいようドキュメント化する • 実装と仕様書が乖離しないよう仕組み化して対応 最初にMock APIを作って開発を並列で⾏えるようにする
• クライアントがすぐに作業に着⼿できるように 最初は簡単なmock APIを提供 • 早くfeedbackをもらうことでサーバーサイドの⼿戻りを最⼩限に
API仕様Drivenな開発
APIの仕様をどうやって 開発時に利⽤しやすい形でまとめるか?
APIの仕様として最初に決める必要があるもの リクエスト情報 • path, method, content type, path parameter, body
レスポンス情報 • content type, body
APIの仕様をどうまとめるか ツールを利⽤ • Swagger(今回採⽤) • graphQL • gRPC
YAMLで仕様をかける ドキュメント⽣成 RESTベース クライアント⽣成 データに対して、JSON Schema⽣成できる Railsへ組み込むgem(committee)あり APIのmockが作りやすい 検討したツール Swagger
今だと⼀番候補になりそうですが、 開発始めたときはそこまでたころは情報が少なかった 今回、インフラやクライアントで挑戦していることも多く RESTから移⾏するための余裕がなかった 同じリソースの内容を画⾯によってで出し分けるのであれば、 graphQLがよさそう 検討したツール graphQL
Webクライアント(JS)で Protocol Bufferの扱い⽅が難しい grpc-webがでているが試してはいない 検討したツール gRPC
Swaggerを利⽤するための⼯夫
可読性を⾼めてAPIの仕様をまとめる yamlで書ける まとめて1つのファイルに書く と可読性が悪いので…
multi-file-swagger yamlファイルを分割し、最終的に⼀つのschema.yamlにまとめることができる
multi-file-swagger yamlファイルの構成例 paths • エンドポイントごとの定義を書く shared • 共通のmodelなどを格納
APIの仕様からドキュメントを⽣成する swagger-codegenを使って ドキュメントを⽣成 github上でも確認できる ようにする
RubyMineのSwagger plugin ⼊れることでRubyMine上で ドキュメントを⾒ながら開発できる
APIの仕様をまとめるときに 出てくる問題
仕様と実装の乖離 • 仕様上にはあったが 実装がもれている • hotfixによる実装だけ⾏って 仕様を更新していない
Swaggerで定義した仕様と APIサーバーの実装を 結合させることで 実装と仕様書のズレが 起こらないようにしたい
SwaggerとAPIサーバの連携
APIサーバーと連携する committeeを使ってRailsに組み込む •https://github.com/interagent/committee
committeeを利⽤してできること リクエストのバリデーション • リクエストの内容をSwaggerで⽣成されるJSON Schemaを使ってバリ デーション レスポンスの⽣成とバリデーション • View作らずに、Swaggerの定義通りにレスポンスを⽣成する •
Jbuilderとかは使わない • レスポンスの内容をSwaggerで⽣成されるJSON Schemaを使ってバリ デーション
レスポンスの⽣成 schemaのプロパティを 使って⾃動⽣成 • レスポンスのパラメータ追 加ならコード変更はいらな い
これらをプロセスに組み込んだ 開発フロー
開発フロー 1. 画⾯仕様の決定 2. SwaggerでAPIの仕様を起こす 3. サーバー側でルーティングを⾜してテストを書きテストを落とす 4. Swaggerのモックレスポンスをcontrollerにコピーしてテストを通す 5.
マージしてsandbox環境でデプロイする 6. クライアントとサーバーの開発開始 1 2 3 4 5 6
開発フロー ʙ࣌ؒ͘Β͍ͰରԠ͢Δ 1. 画⾯仕様の決定 2. SwaggerでAPIの仕様を起こす 3. サーバー側でルーティングを⾜してテストを書きテストを落とす 4. Swaggerのモックレスポンスをcontrollerにコピーしてテストを通す
5. マージしてsandbox環境でデプロイする 6. クライアントとサーバーの開発開始 1 2 3 4 5 6
画⾯仕様の決定 Product Requirementか らAPIの設計をす る 1
SwaggerでAPIの仕様を起こす Swaggerの書き⽅に 準じて書くだけ 2
サーバー側でRoutingを⾜してテストを書きテストを落とす 最⼩限の実装 3
サーバー側でRoutingを⾜してテストを書きテストを落とす 実装ないので落ちる 最⼩限のテスト 3
サーバー側でRoutingを⾜してテストを書きテストを落とす 3
Swaggerのモックレスポンスをcontrollerにコピーしテストを通す Swagger Editorから コピーできる 4
Swaggerのモックレスポンスをcontrollerにコピーしテストを通す 4
Swaggerのモックレスポンスをcontrollerにコピーしテストを通す 4
mergeしてsandbox環境でデプロイする Sandbox deploy • Sandbox環境へはローカルからdeployできる 5
サーバーとクライアントの実装開始 ここからちゃんとした実装開始 • サーバーはDBの設計とかロジックを書いていく • クライアントはダミーのレスポンスをもとに画⾯を作っていく 6
振り返り
開発ボリューム 管理画⾯ページ数 60 APIエンドポイント数 30 フロント画⾯数(SPA) 40
β版リリースまでのスケジュール βリリース後も機能追加や本リリース向けの対応を⾏っている
不具合
QAチームとの振り返り DeNAの中で⽐較すると全体的に品質が⾼いと⾼評価 • APIの不具合はほとんどなし • 上がってきたものはQAで拾う想定だった⽂⾔やレイアウトの問題
クライアント側との振り返り 今の所特に不満なし • ドキュメントが整備されていて実装しやすい 今後はクライアント側のコードの ⾃動⽣成までサポートしてほしい • axios使っているのでそれに即したコードの⽣成
今後の課題 Swaggerのファイル分割をスマートに • https://github.com/chuross/swaglow を検討する OpenAPI 3.0への対応 • 3.0で対応される新しい仕様への対応(nullable等、今は⾃前で拡張)
まとめ
まとめ Swaggerを使ったAPI仕様ファーストで開発スピードを向 上できた さらにSwaggerとサーバーを組み合わせることで、開発ス ピードの向上と不具合の減少に寄与することができた
We are hiring!
と⾔いたいのですが 弊チームの計画上これ以上は。。
https://dena.com/jp/recruit/career/engineer/ DeNA is hiring!