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.3k
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.2k
環境の一致について考えてみる / Environment Parity
spring_mt
4
7k
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.2k
Rails on GKEで運用する Webアプリケーションの紹介/Rails on GKE
spring_mt
0
430
新規事業立ち上げからマイクロサービスについて考えてみる
spring_mt
1
1.1k
hpbn_3
spring_mt
0
94
backbone.jsの使用例 その1
spring_mt
0
320
chef-soloの簡単な使い方
spring_mt
4
940
Other Decks in Technology
See All in Technology
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
SDNという名のデータプレーンプログラミングの歴史
ebiken
PRO
2
130
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
430
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
150
あなたの知らない Function.prototype.toString() の世界
mizdra
PRO
2
390
『Firebase Dynamic Links終了に備える』 FlutterアプリでのAdjust導入とDeeplink最適化
techiro
0
170
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
190
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
350
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
380
The Pragmatic Product Professional
lauravandoore
31
6.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Optimizing for Happiness
mojombo
376
70k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
How STYLIGHT went responsive
nonsquared
95
5.2k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
4 Signs Your Business is Dying
shpigford
180
21k
A designer walks into a library…
pauljervisheath
204
24k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
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!