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
TechTalk スキーマファースト開発
Search
DeNA_Tech
July 21, 2020
Technology
1
4.7k
TechTalk スキーマファースト開発
スキーマファースト開発を導入することで、フロントエンド/サーバーサイド エンジニア間でのすり合わせやドキュメントの整備等を減らすことができ、開発効率を上げられる、という話です。
DeNA_Tech
July 21, 2020
Tweet
Share
More Decks by DeNA_Tech
See All by DeNA_Tech
学びが形になる!〜DeNAで6年間プロダクト開発に携わって学んだこと〜
dena_tech
1
950
ペタバイト、30プロダクトを超えて成長を続けるデータ基盤の歴史
dena_tech
1
490
DeNAデータエンジニアの組織・データエンジニアキャリアについて
dena_tech
1
1k
Pocochaにおけるデータマネジメント
dena_tech
1
130
社内データ利活用の推進と技術的負債の解決に向けた取り組み
dena_tech
1
170
Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について
dena_tech
0
140
DeNA SWETでのインターンシップについて【DeNA TechCon 2023】
dena_tech
0
310
T系EC2インスタンスのクレジットが回復しないので困った話【DeNA TechCon 2023】
dena_tech
0
390
画像サーバーを紆余曲折あってS3 に移行した話【DeNA TechCon 2023】
dena_tech
0
300
Other Decks in Technology
See All in Technology
Evolutionary Optimization of Model Merging Recipes
fuyu_quant0
3
520
単回帰分析について数式を追いながら実装してみた
kentaitakura
0
500
プッシュ型子育てサービスを、先行プロジェクト実施自治体において開始します
govtechtokyo
0
250
どう買う?Azure
kuniteru
1
190
サービスメッシュ環境における OpenTelemetry 活用 / OpenTelemetry in Service Mesh
k6s4i53rx
2
830
依存ライブラリはどこに?
takesection
0
110
バッチ処理のSLOをどう設計するか
rynsuke
7
560
期待しすぎずに取り組む両面 TypeScript
shozawa
2
290
TCA入門したてなので、自分が馴染みのある実装と比較しながらキャッチアップしてみる
fumiyasac0921
1
370
XRミーティング 2024-03-20
1ftseabass
PRO
0
100
KTC_DBRE.pdf
_awache
0
290
オブジェクト指向CSSが叶えたかったことと、CSSのいま / The aims of Object-oriented CSS and the current state of CSS usage
shinkufencer
11
3.6k
Featured
See All Featured
Designing the Hi-DPI Web
ddemaree
275
33k
The Invisible Side of Design
smashingmag
293
49k
Become a Pro
speakerdeck
PRO
8
4.4k
The Brand Is Dead. Long Live the Brand.
mthomps
48
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
11
1.4k
Building Adaptive Systems
keathley
29
1.8k
Making Projects Easy
brettharned
106
5.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
242
12k
How To Stay Up To Date on Web Technology
chriscoyier
781
250k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
The World Runs on Bad Software
bkeepers
PRO
60
6.6k
10 Git Anti Patterns You Should be Aware of
lemiorhan
644
57k
Transcript
TechTalk スキーマファースト開発 2020/6/15 海老沼 健一
持ち帰ってほしいこと 2 スキーマファースト開発で コミュニケーションコストを減らして 開発効率を上げよう
よくある開発スタイル (僕が実際に経験した環境) エンジニアがフロントエンドとサーバーサイドに分かれている 機能開発フロー 1. 機能の仕様書を作る 2. サーバーサイドエンジニアがAPI設計 3. サーバーサイドエンジニアがAPI実装
4. フロントエンドエンジニアが作成されたAPIを使ってクライアントを実装 よくある問題 • 仕様書やドキュメントがちゃんと整備されていない • クライアント側はAPIの実装を待たないといけない • エンドポイント毎のエンコード/デコード処理を書くのが面倒 3
よくある問題1 仕様書やドキュメントがちゃんと整備されていない • スケジュールが押してると仕様書やドキュメントを書くのは後回しになりがち • 手動でAPI仕様書を書いているとタイポやミス • ドキュメントがちゃんと整備されていないと、APIの仕様を確認する必要がある • 例えば
• エンドポイントとサンプルのレスポンスが貼ってあるだけ • バグ修正で変更した箇所のドキュメントが修正されていない 4
よくある問題2 クライアント側はAPIの実装を待たなければいけない • クライアント側の通信周りの実装がAPI待ち • 正しいモックデータを用意するのにコミュニケーションコストがかかる • 自前でモックサーバーを用意するにもメンテが必要 5
よくある問題3 エンドポイント毎のエンコード/デコード処理を書くのが面倒 • サーバー/クライアント共にリクエストとレスポンスの構造体やクラスを用意して、エンコード/デコー ド処理を書く必要があり、コード量が多くなりがち • 例えば • Goだと json.NewEncoder().Encode(),
json.Marshal() とか • Dartだと RequestClass.toJson() とか 6
7 スキーマファースト開発
スキーマファースト開発とは まずAPIの仕様(スキーマ)を決めて、それをもとにサーバー/クライアント開発を同時に進めて最後に 結合する開発手法 メリット • スキーマという共通言語でコミュニケーションを取れる • 周辺ツールによる開発効率の向上 • ドキュメント生成、モックサーバー立ち上げ
• ハンドラー、エンコード/デコード周りのコード生成 • バグの発生を減らせる デメリット • スキーマの学習コスト、導入コストかかる 8
スキーマファースト開発 • OpenAPI • gRPC (概要のみ) • JSON Schema (概要のみ)
• GraphQL 9
OpenAPI https://openapis.org REST API をYAML/JSONで記述するフォーマットで、Swagger ( https://swagger.io ) が有名 メリット
• ドキュメントやコードの生成、モックサーバー • 既存のRESTの知識/仕組みをそのまま使える • キャッシュとか デメリット • リソースに対して画面やユースケース毎に微妙に異なるデー タが欲しくなり、エンドポイントが増えていく (REST API のデ メリット) 10
gRPC https://grpc.io HTTP/2を利用したハイパフォーマンスなRPCフレームワーク Protocol Buffers というIDL(インタフェース定義言語)でスキーマを定義する 来週のTechTalkで出てくるので今回は省略 11 JSON Schema
https://json-schema.org JSONファイルの構造(型、範囲など)をJSONで表現する 採用事例が少なそう
GraphQL https://graphql.org APIのためのクエリ言語/実装 GraphQL 独自のSDLを使う クライアント側で取得したいデータをクエリ言語で指定 し、/graphql エンドポイントに送る。APIはそのクエリど おりにデータを返す メリット
• ドキュメントやコード生成、モックサーバー • スキーマを定義しておけばクライアント主導でレス ポンスを変えれる 12
GraphQL デメリット • リソースに対するシンプルなCRUDで十分なサービスには必要ない • サーバーの実装が複雑になりがち • n+1問題を解決するためのバッチ処理 • 認証/認可などミドルウェアの設計
• キャッシュの仕組みなどまだ枯れてない • 基本的に1つの /graphql エンドポイントでリクエストを受けるので、エンドポイント単位で キャッシュしていた場合はRESTの知見をそのままは活かしにくい • FastlyやCloudflareなどのCDNではGraphQLクエリのキャッシュに対応しているが、まだ 採用事例は少なそう 13
14 GraphQL デモ
GraphQL - エブリスタでの採用事例 フルRailsだったサーバーを Rails + graphql-ruby でリプレイス 良かったこと •
APIのドキュメント作成が不要になり工数削減 • API数が900 -> 150クエリに • フロントエンド主導の開発プロセス つらかったこと • 当時はgraphql-rubyが安定していなかった • ベストプラクティスが無かった https://www.slideshare.net/dena_tech/10-132197778 15
持ち帰ってほしいこと (再掲) 16 スキーマファースト開発で コミュニケーションコストを減らして 開発効率を上げよう