サーバーサイドから見るGraphQL Serverless Meetup #19
•
2 gefällt mir•26,162 views
- そもそもGraphQLはなんで作られたのか、何を解決しようとしているのか - その後生まれて来ているユースケース - GraphQL導入の検討 (発表に含んでいた社内の事例は一旦、見えないようにしてます)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie サーバーサイドから見るGraphQL Serverless Meetup #19
Ähnlich wie サーバーサイドから見るGraphQL Serverless Meetup #19 (20)
Mehr von Yutaka Tachibana
Mehr von Yutaka Tachibana (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
サーバーサイドから見るGraphQL Serverless Meetup #19
- 2. • 有限会社ゑびや / 株式会社 EBILAB • テックリード/アーキテクト @EBILAB • 沖縄移住6年目(出身は福岡) • Azure/Servelss/Apollo/GraphQL/Rails/Laravel/ Python/TypeScript/React/Vue/Next.js/Nuxt.js • 大卒 -> SIer -> Web系(ピクシブ) -> フリーランス -> スタートアップ(EBILAB) • 進化的アーキテクチャがすき(立ち上げから軌道に 乗るまでの0-5年) 自己紹介 @saboyutaka 立花 豊 (さぼ) たちばな ゆたか
- 3. GraphQL and me この1年書いたQiita記事 • GraphQLの特徴を分解する API インターフ ェース・Universal BFF・API Gateway • GraphQLはサーバーサイド実装のベストプラ クティスとなるか • GraphQLの全体像とWebApp開発のこれから
- 5. GraphQLとは いつものまえおき • Facebook発のWebAPI仕様, 2015年にOSS化 • GraphQL自体はspec(仕様) • GraphQL over HTTP が主流 (HTTP/1.1) • アプリケーション層のプロトコル(not トランスポート層) • GraphQL Clientと GraphQL Server間のプロトコル • Client側も含めてデザインされているWebAPIの仕様 通信手法はgRPCに 似てる RESTとの違い
- 6. GraphQL(の前身)が作られた時の問題意識 • モバイルクライアントの急増(iPhone 4 ) • ネットワークトラフィックの増大 • アプリのWebViewからネイティブ化 背景 問題意識 • 様々なユースケース, 多種クライアントに耐えうるAPI設計にしなければいけない • モバイルクライアントのリソース最小化(CPU, メモリ, ネットワーク, バッテリー)したい • 頻繁に起こるクラサバ間での状態の操作と同期を楽にしたい 2010 2012年頃のFacebook RESTでは実現が むずかしい みなさんが Twitterを始めた頃
- 7. GraphQL 最低限の知識 • Query, 読み込み • Mutation, 書き込み • Subscription, Websocket 操作 WebAPI • HTTPでリクエスト出来る • JSONが返ってくる
- 8. GraphQLが解決する課題 • APIインターフェース • クライアントリソースの低減 • クライアント-サーバー間の状態同期
- 10. WebAPI(RESTish)の問題意識 クライアント側の問題意識 • 実装コスト • 増大するエンドポイント • エンドポイント毎の仕様 • クライアント任せなサーバー状態の管理 • 使用リソース • 増大するリクエスト数 • 利用されない受信データ クライアント側 APIインターフェース
- 11. WebAPI(RESTish)の問題意識 サーバーサイドの問題意識 • ユースケース毎のAPIを煩わしさ • クライアント都合でサーバーサイド実装を変える煩わしさ • APIドキュメントの煩わしさ • コミュニケーションコスト増 サーバーサイド側のAPIインターフェース 傾向として (本当はしてあげたい、本 当はしてあげたいけど…フロ ントエンド都合で度々, 実装 に手を入れるのつらい) 😣 サーバーサイド都合なAPIになりがち APIインターフェース
- 15. WebAPI(RESTish)の問題意識 現実問題として • ドメインロジックを実装するときにAPIのユースケースを同時に考えるのは大変 • ドメインロジックのコンテキストは可能な限り狭いほうが良い • 負荷によってはロジックを分離したい • 将来に渡って利用可能なユースケースを実現するのは難しい サーバーサイド側の実装都合 傾向として APIは細分化され増えていく → クライアントにとっては使いづらくなる… エンドポイントが増え る事はサーバーサイドにとって も嬉しいことではない… APIインターフェース
- 16. WebAPI(RESTish)の問題意識 現実問題として • ドメインロジックを実装するときにAPIのユースケースを同時に考えるのは大変 • ドメインロジックのコンテキストは可能な限り狭いほうが良い • 負荷によってはロジックを分離したい • 将来に渡って利用可能なユースケースを実現するのは難しい サーバーサイド側の実装都合 傾向として APIは細分化され増えていく → クライアントにとっては使いづらくなる… エンドポイントが増え る事はサーバーサイドにとって も嬉しいことではない… 🤓 Presentation-Domain Separation しましょう APIインターフェース
- 17. APIのPresentation-Domain Separation BFFとしてのGraphQL API クライアント API サーバー GraphQL クライアント都合のAPI ドメイン都合のAPI クライアントにとってはBFF サーバーにとってはAPI Aggregator APIインターフェース
- 18. GraphQLを入れると クライアント GraphQLで解決するAPIインターフェースの問題 サーバーサイド ☺ • 単一のエンドポイント、単一の仕様 • 利用可能な全ての状態がわかる • ユースケース毎に自分でクエリを作成する • ドメインAPIから微細なユースケースの対応を減らせる • クライアント都合の変更が減る, API仕様を伝えるコミュニケーションが減る • Schemaがドキュメントになるためドキュメント作業がなくなる • サーバーサイド都合で自由にAPIを作成・統合・撤廃出来る APIインターフェース
- 19. 情報アーキテクチャ的な観点 • 利用可能なデータが発見しやすい・利用しやすい • クライアントに提供しているデータが一元化される • ユーザーにとって見せるか見せるべきではないかの監査を1箇所で行う事で監 査可しやすい RESTishなAPIでは全 てのエンドポイントで同一レベ ルの監査が必要だった APIインターフェース
- 20. クライアントリソースの軽減
- 21. クライアントの問題意識 問題意識 • ネットワークやバッテリーの使用を可能な限り抑えたい • 劣悪な環境にあるクライアントでもサービスを利用してもらいたい • ユーザー規模が多くなると通信コストだけで莫大なコストが掛かる 特にモバイルクライアント 課題 • アプリケーションから発生するリクエストを可能な限り減らす • 利用されない無駄なデータを減らす クライアントリソースの軽減
- 22. GraphQLのアプローチ アプローチ クライアントリソースの問題 解決方法 • 1リクエストで取得出来るデータを増やす • レスポンスデータの有効率を上げる • クライアントに必要なデータを宣言させる(宣言的データフェッチ) • 利用可能なデータは全て先に知らせる(Schema Introspection) Overfetch, Underfetch問題 クライアントリソースの軽減
- 23. GraphQLのAPIデザイン Query 結果 ☺ • 1リクエストで多くの情報を取得出来るように設計されている • 1リクエストに複数のクエリを含めることが出来る(Batch Query) • 1リクエストで段階的にレスポンスを受け取るRFCが進行中(@defer, @stream) • リクエスト数を減らしながら利用したいデータを効率よく取得出来るようになった • サービス全体で見ると無駄なデータ通信が減らす事が出来た クライアントリソースの軽減
- 24. クライアント-サーバーの状態同期
- 25. クラサバの状態同期の問題意識 前提 • RESTishなAPIはクライアントとの状態同期に関しては特に指定がない • クライアント-サーバー間の状態同期クライアント任せ • 特にネイティブクライアント, SPAアプリはクラサバ状態同期の実装が大変 • フロントエンドでFlux系の状態管理ツールが出てきたりで頑張ってきた RESTだと大変 サービスが大きくなると 状態管理のコードが肥大化し管理不能になるとフロントエンドの開発効率が急激に落ちる 状態とは, 時間経過に伴い変化するデータ
- 26. Reduxで見る状態管理 • 状態を持つ信頼できる唯一リソース (Single Source of Truth) • Immutable State • 操作は必ずActionから • (これまでの用途は主にサーバーから 取得したデータのキャッシュ管理だ った?) Flux系の状態管理手法 ユースケース 出典: Redux Essentials, Part 1: Redux Overview and Concepts
- 27. • 状態管理の考え方はFlux系と同じ • クライアント-サーバー間の状態同期 に特化 (Server State) • 操作はQuery, Mutationで行う • GraphQL Clientが状態をキャッシ ュとして保持している GraphQL Clientによる状態管理 ユースケース 出典: Redux Essentials, Part 1: Redux Overview and Concepts Query Mutation
- 28. GraphQLはクライアントも含めてデザインされている GraphQL Clientの実装 • GraphQLクライアントが状態を管理している • 主要なGraphQLクライアントは正規化されたキャッシュを自動で行う機構を持つ (Normalized Cache) • 異なる経路から取得されたデータでも同一のkey, デフォルトではidと__typename, であれば キャッシュが更新される • データの更新時(Mutation)の場合も、同一のkeyを持つオブジェクトを返す事で 変更操作を伴う場合、 MutationもGraphQLで実装する 必要がある 結果 状態管理の多くの作業をGraphQLクライアントが自動化してくれる
- 29. ユースケース
- 30. • マルチクライアントのための Universal BFF • マルチバックエンドのためのAPI Aggregator • クライアントを追加しやすい • バックエンドを追加しやすい マルチクライアント ユースケース
- 31. マルチクライアント • 異種クライアントを追加しやすい • ユーザー毎のUI(新レイアウト, 玄人向け, 高齢者向け)を作りやすい • 同じサービスでも異なったUIを複数展開しやすい • GraphQL APIを提供するところまでがサービス提供、UIは自分で作ってね ユースケース GraphQLを提供することで考えられるアイディア アイディア 発想💡 APIがユースケースを持たないからこそ様々なユースケースを考えられる
- 32. API層のAnti-Corruption Layerとして導入する 大規模アーキテクチャ変更のお供に • かつて(！)はUIの大きな改修(リニューアル)が入る場合、同時にバックエンド を全面改修することがあった (よく見る) • 全面リニューアルしましょう！ • しばしばバックエンドの改修も同時に行われる… • プロジェクトの超長期化、実現難易度のスパイク、止まる新規機能リリース、焦るビジネスサイド、プレッシャー をかけられるエンジニア陣、リリースしないとわからないバグ、乖離するFeature Branch、出来ない動作検証、 疲弊する現場…🤮 ユースケース 歴史 ビッグバンリニューアル
- 34. https://amzn.to/3cE1XPc API層のAnti-Corruption Layerとして導入する 大規模アーキテクチャ変更のお供に ユースケース • インクリメンタルな変更 • 適度な結合 • 適応度関数 進化的アーキテクチャ • 最も簡単なことを最初に • 最も価値のあるものを最初に どこから始めるか
- 35. API層のAnti-Corruption Layerとして導入する 大規模アーキテクチャ変更のお供に • 往々にして機能要件(デザイン, UI, 新機能)をリニューアルと言っている ユースケース ビジネス 開発 • 実装のしやすさ、メンテのしやすさを気にしている 達成すべきこと • 機能要件を最速で実現しながらアーキテクチャも段階的に変更する リニューアルしたい
- 36. API層のAnti-Corruption Layerとして導入する 大規模アーキテクチャ変更のお供に ユースケース 1. レガシーな単一のバックエンド 2. API層としてGraphQLを導入, 次いでクライアントを実装 可能であればコン ポーネント単位、ページ 単位で順次リリース ✨ ✨ ✨ 4. 必要に応じて(!), 順次新バックエンドに切り替え ✨ 3. 完全にフロントが切り替わったタイミングで 旧フロントを廃止 3, 4は平行作業可能
- 37. • GraphQLをAPI層として入れる事でフロントとバックの結合を分離出来る • それぞれ異なったタイミングでのリリースを可能にする • まずは機能要件から優先、バックエンドの整備や切り替えは後から • 特に中規模になってきたアプリケーションの改修時に重宝する ユースケース API層のAnti-Corruption Layerとして導入する 大規模アーキテクチャ変更のお供に
- 38. CQRS 読み込み系と書き込み系のAPIを分けるデザインパターン • そもそもGraphQLはQuery, MutationとCQRSでデザインされている • エンタープライズなデータ仮想化基盤と相性が良い • Denodo(データ仮想化技術)がGraphQL APIを対応してきている • 非同期リクエスト-レスポンスパターンの実装例 • Shopify BulkOperation(従来のstatusを返すURLを返すパターン) • 3 Factor App(Subscriptionでサーバープッシュで返すパターン) ユースケース
- 39. Subscriptionで状態をサーバープッシュで受け取る • Clubhouseのようなアプリを作りや すい • ユーザーのログイン状態, 入室して いるRoom, 最終ログイン時刻, チャ ット, リアクション • ユーザー自身の操作よりもサーバー 側での状態変更が多い場合に有用 • Firestoreを使うようなユースケース Realtime API with Subscription Clubhouse ユースケース
- 40. 巨人の肩に乗る イノベーションが起きている技術を率先して使う • 活発に議論されている場所は課題への解決策が出てくる可能性が高い • 後発の技術はすでにある技術の課題を解決している可能性が高い 活発に議論されている場所 • フロントエンド: Web基準, React.js/Vue.js, SPA, etc… • GraphQL • クラウド, Serverless EBILABの事例
- 42. フロントエンド視点 • クラサバ間での状態同期が必要かどうか • 特にクライアントからの状態更新(Mutation)がある • モバイルクライアントで利用されるかどうか • 複数種類のクライアントがある, または作る予定がある • エンドポイントが多すぎて開発体験が悪い GraphQLの導入するタイミング
- 43. サーバーサイド視点 • APIデザイン都合 • クライアントのユースケースによるAPI変更が多い • Microservicesを採用している • (API ドキュメントを書きたくない) • 大規模なアーキテクチャ変更が必要 GraphQLの導入するタイミング
- 44. プロダクトの規模 • 見てきたように最初期から中期、エンタープライズ規模までどの規模でも利用可 能 • 最初期はフロントエンドの状態管理都合が多い • 中期はアーキテクチャ変更のお供に • エンタープライズ規模ではCQRS, Microservicesのエンドポイントとして • 段階的な導入が望ましい • TwitterやAirbnb, GitHubでも全体の数％から適用中 GraphQLの導入するタイミング
- 45. GraphQLに向かない事 • WebAPIであること, HTTPの制約を受ける • 巨大なデータ転送には向いてない • オブジェクト型の構造データが向いている • 非構造型データ、テーブル型のデータは向いてない GraphQLの導入するタイミング