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.2k
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
420
新規事業立ち上げからマイクロサービスについて考えてみる
spring_mt
1
1.1k
hpbn_3
spring_mt
0
92
backbone.jsの使用例 その1
spring_mt
0
320
chef-soloの簡単な使い方
spring_mt
4
930
Other Decks in Technology
See All in Technology
話題のGraphRAG、その可能性と課題を理解する
hide212131
4
1.4k
CI/CDやテスト自動化の開発プロジェクトへの適用
megascus
3
740
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
「最高のチューニング」をしないために / hack@delta 24.10
fujiwara3
21
3.4k
Fargateを使った研修の話
takesection
0
110
端末が簡単にリモートから操作されるデモを通じて ソフトウェアサプライチェーン攻撃対策の重要性を理解しよう
kitaji0306
0
170
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
140
ガバメントクラウド単独利用方式におけるIaC活用
techniczna
3
260
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
430
Vueで Webコンポーネントを作って Reactで使う / 20241030-cloudsign-vuefes_after_night
bengo4com
4
2.5k
IaC運用を楽にするためにCDK Pipelinesを導入したけど、思い通りにいかなかった話
smt7174
1
110
初心者に Vue.js を 教えるには
tsukuha
5
390
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
136
6.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Happy Clients
brianwarren
97
6.7k
Embracing the Ebb and Flow
colly
84
4.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
A Modern Web Designer's Workflow
chriscoyier
692
190k
For a Future-Friendly Web
brad_frost
175
9.4k
A Tale of Four Properties
chriscoyier
156
23k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Agile that works and the tools we love
rasmusluckow
327
21k
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!