Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TechTalk スキーマファースト開発

TechTalk スキーマファースト開発

スキーマファースト開発を導入することで、フロントエンド/サーバーサイド エンジニア間でのすり合わせやドキュメントの整備等を減らすことができ、開発効率を上げられる、という話です。

DeNA_Tech

July 21, 2020
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. よくある開発スタイル (僕が実際に経験した環境) エンジニアがフロントエンドとサーバーサイドに分かれている 機能開発フロー 1. 機能の仕様書を作る 2. サーバーサイドエンジニアがAPI設計 3. サーバーサイドエンジニアがAPI実装

    4. フロントエンドエンジニアが作成されたAPIを使ってクライアントを実装 よくある問題 • 仕様書やドキュメントがちゃんと整備されていない • クライアント側はAPIの実装を待たないといけない • エンドポイント毎のエンコード/デコード処理を書くのが面倒 3
  2. OpenAPI https://openapis.org REST API をYAML/JSONで記述するフォーマットで、Swagger ( https://swagger.io ) が有名 メリット

    • ドキュメントやコードの生成、モックサーバー • 既存のRESTの知識/仕組みをそのまま使える • キャッシュとか デメリット • リソースに対して画面やユースケース毎に微妙に異なるデー タが欲しくなり、エンドポイントが増えていく (REST API のデ メリット) 10
  3. GraphQL デメリット • リソースに対するシンプルなCRUDで十分なサービスには必要ない • サーバーの実装が複雑になりがち • n+1問題を解決するためのバッチ処理 • 認証/認可などミドルウェアの設計

    • キャッシュの仕組みなどまだ枯れてない • 基本的に1つの /graphql エンドポイントでリクエストを受けるので、エンドポイント単位で キャッシュしていた場合はRESTの知見をそのままは活かしにくい • FastlyやCloudflareなどのCDNではGraphQLクエリのキャッシュに対応しているが、まだ 採用事例は少なそう 13
  4. GraphQL - エブリスタでの採用事例 フルRailsだったサーバーを Rails + graphql-ruby でリプレイス 良かったこと •

    APIのドキュメント作成が不要になり工数削減 • API数が900 -> 150クエリに • フロントエンド主導の開発プロセス つらかったこと • 当時はgraphql-rubyが安定していなかった • ベストプラクティスが無かった https://www.slideshare.net/dena_tech/10-132197778 15