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
5.3k
TechTalk スキーマファースト開発
スキーマファースト開発を導入することで、フロントエンド/サーバーサイド エンジニア間でのすり合わせやドキュメントの整備等を減らすことができ、開発効率を上げられる、という話です。
DeNA_Tech
July 21, 2020
Tweet
Share
More Decks by DeNA_Tech
See All by DeNA_Tech
学びが形になる!〜DeNAで6年間プロダクト開発に携わって学んだこと〜
dena_tech
6
1.3k
ペタバイト、30プロダクトを超えて成長を続けるデータ基盤の歴史
dena_tech
3
790
DeNAデータエンジニアの組織・データエンジニアキャリアについて
dena_tech
6
1.9k
Pocochaにおけるデータマネジメント
dena_tech
3
1.2k
社内データ利活用の推進と技術的負債の解決に向けた取り組み
dena_tech
5
390
Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について
dena_tech
6
340
DeNA SWETでのインターンシップについて【DeNA TechCon 2023】
dena_tech
0
590
T系EC2インスタンスのクレジットが回復しないので困った話【DeNA TechCon 2023】
dena_tech
4
880
画像サーバーを紆余曲折あってS3 に移行した話【DeNA TechCon 2023】
dena_tech
0
670
Other Decks in Technology
See All in Technology
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
2
110
今日からあなたもGeminiを好きになる
subaruhello
1
640
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
240
低レイヤソフトウェア技術者が YouTuberとして食っていこうとした話
sat
PRO
7
5.9k
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
6
300
20250719_JAWS_kobe
takuyay0ne
1
170
AIエージェントを支える設計
tkikuchi1002
11
1.9k
Power Automate のパフォーマンス改善レシピ / Power Automate Performance Improvement Recipes
karamem0
0
240
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
160
Turn Your Community into a Fundraising Catalyst for Black Philanthropy Month
auctria
PRO
0
160
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
270
AI工学特論: MLOps・継続的評価
asei
10
1.9k
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
For a Future-Friendly Web
brad_frost
179
9.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Practical Orchestrator
shlominoach
189
11k
Producing Creativity
orderedlist
PRO
346
40k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Being A Developer After 40
akosma
90
590k
Documentation Writing (for coders)
carmenintech
72
4.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
How STYLIGHT went responsive
nonsquared
100
5.7k
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 スキーマファースト開発で コミュニケーションコストを減らして 開発効率を上げよう