Slide 1

Slide 1 text

gRPCとフロントエンド ~Connectを添えて~ 2023/10/17 UV Study : フロントエンド LT会 @sugar235711

Slide 2

Slide 2 text

2 Sugar(@sugar235711) 株式会社AI Shift サーバーサイドエンジニア 普段はGoを書いてます。 フロントエンドはAngularが好きです。 登壇者紹介

Slide 3

Slide 3 text

3 Agenda 1. スキーマ駆動開発 1.1. スキーマ駆動開発とは 1.2. IDL 2. gRPC on Web 2.1. gRPCとは 2.2. gRPCをWebブラウザで使う 3. Connect 3.1. 概要 4. Connect-Web 4.1. コード生成 4.2. React/Next.jsにおけるデータフェッチ(Client) 4.3. React/Next.jsにおけるデータフェッチ(Server)

Slide 4

Slide 4 text

4 スキーマ(仕様書)を最初に定義し、その定義をもとに開発を同時に進めるという開発手法 ● クライアントとサーバーを非同期で開発可能 ● 型やインターフェースの自動生成が可能 1.1 スキーマ駆動開発とは 1.スキーマ駆動開発 1. スキーマの定義/認識合わせ 2. スタブの生成 3. 実装・単体テスト 4. 結合テスト 5. リリース

Slide 5

Slide 5 text

5 2023年現在使用される代表的なIDL 1.2 IDL(インターフェース記述言語) 1.スキーマ駆動開発 設計指針 RPC Protocol Buffers REST OpenAPI 記述形式 Protobuf JSON/Yaml コード生成 Protoc Compoler Connect OpenAPI Generator Swagger Codegen - GraphQL クエリ言語(環境による) Graphql Code Generator

Slide 6

Slide 6 text

6 2023年現在使用される代表的なIDL 1.2 IDL(インターフェース記述言語) 1.スキーマ駆動開発 設計指針 RPC Protocol Buffers REST OpenAPI 記述形式 Protobuf JSON/Yaml コード生成 Protoc Compoler Connect OpenAPI Generator Swagger Codegen - GraphQL クエリ言語(環境による) Graphql Code Generator ➢ クライアント - サーバ間通信は大部分が REST

Slide 7

Slide 7 text

7 2023年現在使用される代表的なIDL 1.2 IDL(インターフェース記述言語) 1.スキーマ駆動開発 設計指針 RPC Protocol Buffers REST OpenAPI 記述形式 Protobuf JSON/Yaml コード生成 Protoc Compoler Connect OpenAPI Generator Swagger Codegen - GraphQL クエリ言語(環境による) Graphql Code Generator ➢ クライアント - サーバ間通信は大部分が REST ○ REST✖スキーマ駆動で開発を進めると YAMLを書くことになる。 ■ 単純に読みづらい。肥大化しやすい。つらい。

Slide 8

Slide 8 text

8 2023年現在使用される代表的なIDL 1.2 IDL(インターフェース記述言語) 1.スキーマ駆動開発 設計指針 RPC Protocol Buffers REST OpenAPI 記述形式 Protobuf JSON/Yaml コード生成 Protoc Compoler Connect OpenAPI Generator Swagger Codegen - GraphQL クエリ言語(環境による) Graphql Code Generator ➢ クライアント - サーバ間通信は大部分が REST ○ REST✖スキーマ駆動で開発を進めると Yamlを書くことになる。 ■ 単純に読みづらい。肥大化しやすい。つらい。 →シンプルにスキーマを定義できる ProtobufでgRPCを定義したい

Slide 9

Slide 9 text

9 2.1 gRPCとは 2.gRPC on Web ● HTTP/2, バイナリベースのRPCフレームワーク(Google産) ● シリアライズによってサーバー間の通信量を削減可能 ● 幅広な言語のサポート(Go, Java, Node…) ● IDLの定義に沿って言語ごとのコード生成ができる ○ 生成されたコードは型安全 ● 4つの通信方式が利用可能 ○ Unary RPC ○ Server streaming RPC ○ Client streaming RPC ○ Bidirectional streaming RPC https://grpc.io/

Slide 10

Slide 10 text

10 2.1 gRPCとは 2.gRPC on Web ● HTTP/2, バイナリベースのRPCフレームワーク(Google産) ● シリアライズによってサーバー間の通信量を削減可能 ● 幅広な言語のサポート(Go, Java, Node…) ● IDLの定義に沿って言語ごとのコード生成ができる ○ 生成されたコードは型安全 ● 4つの通信方式が利用可能 ○ Unary RPC ○ Server streaming RPC ○ Client streaming RPC ○ Bidirectional streaming RPC ➢ Webブラウザでも使えるの?🧐

Slide 11

Slide 11 text

11 2.1 gRPCとは 2.gRPC on Web ● HTTP/2, バイナリベースのRPCフレームワーク(Google産) ● シリアライズによってサーバー間の通信量を削減可能 ● 幅広な言語のサポート(Go, Java, Node…) ● IDLの定義に沿って言語ごとのコード生成ができる ○ 生成されたコードは型安全 ● 4つの通信方式が利用可能 ○ Unary RPC ○ Server streaming RPC ○ Client streaming RPC ○ Bidirectional streaming RPC ➢ Webブラウザでも使えるの?🧐 機能を制限すれば使える

Slide 12

Slide 12 text

12 2.2 gRPCをWebブラウザで使う 2.gRPC on Web 代表的なライブラリの実装方針 : 1. gRPC Webに対応させる 2. 何らかの手段で、HTTP APIにマッピングする

Slide 13

Slide 13 text

13 2.2 gRPCをWebブラウザで使う 2.gRPC on Web 代表的なライブラリの実装方針 : 1. gRPC Webに対応させる ○ プロキシ(Envoy等)経由でgRPCが使える様になる → gRPC-Web 2. 何らかの手段で、HTTP APIにマッピングする


Slide 14

Slide 14 text

14 2.2 gRPCをWebブラウザで使う 2.gRPC on Web 代表的なライブラリの実装方針 : 1. gRPC Webに対応させる ○ プロキシ(Envoy等)経由でgRPCが使える様になる → gRPC-Web 2. 何らかの手段で、HTTP APIにマッピングする ○ RPC定義から自動マッピングする → Connect ○ 自力でマッピングする →gRPC-Gateway


Slide 15

Slide 15 text

15 2.2 gRPCをWebブラウザで使う 2.gRPC on Web 代表的なライブラリの実装方針 : 1. gRPC Webに対応させる ○ プロキシ(Envoy等)経由でgRPCが使える様になる → gRPC-Web 2. 何らかの手段で、HTTP APIにマッピングする ○ RPC定義から自動マッピングする → Connect ○ 自力でマッピングする →gRPC-Gateway


Slide 16

Slide 16 text

16 3.1 概要 3.Connect ブラウザとgRPC互換のAPIを構築するためのライブラリ群 HTTP/1.1 または HTTP/2 で動作するシンプルな POST プロトコルをサポート 
 https://connectrpc.com/

Slide 17

Slide 17 text

17 3.1 概要 3.Connect 各言語のプラグインが用意されており、 Protoベースでコードを生成できる 


Slide 18

Slide 18 text

18 3.1 概要 3.Connect ● gRPC, Connect, gRPC-Webの3つのプロトコルをサポート ● Webから使用する場合にProxyが不必要 ● オリジナルgRPCに比べてコードベースが小さい 詳しくは https://connectrpc.com/docs/introduction/ 


Slide 19

Slide 19 text

19 4.1 コード生成 4.Connect-Web スキーマを定義し、各種プラグインを組み合わせることで、リクエストやレスポンスの型やAPI Clientを生 成できる。(ProtoからFE/BE共にコードを自動生成し型安全な開発が可能) 


Slide 20

Slide 20 text

20 4.2 React/Next.jsにおけるデータフェッチ(Client) 4.Connect React等を利用したClientSide fetchの環境では、 API ClientをfethcerとしてTanStack QueryやSWRと組み合わせることで、データのキャッシュも簡単 に行える(公式にTanStack Queryに対するPluginが開発されている) ● Connect WebではAPI Clientの扱いや各種Optionなども詳細にDocumentに記載されている ○ Ex) API Clientを生成する際は再定義を防ぐために useMemoを使うことが推奨されている

Slide 21

Slide 21 text

21 4.2 React/Next.jsにおけるデータフェッチ(Client) 4.Connect TanStack Queryの場合: Connect-Query hookを使用することでシンプルに実装可能 (Connect-Query v.1.0までに変更がある可能性あり ) SWRの場合: 生成されたservice名をキーとしてfethcerにAPI Clientをセットする

Slide 22

Slide 22 text

22 4.3 React/Next.jsにおけるデータフェッチ(Server) 4.Connect RSCの利用を前提としたAppRouter環境ではデータフェッチの戦略が大きく変わった ● 標準のfetch APIの利用が前提となっている

Slide 23

Slide 23 text

23 4.3 React/Next.jsにおけるデータフェッチ(Server) 4.Connect RSCの利用を前提としたAppRouter環境ではデータフェッチの戦略が大きく変わった ● 標準のfetch APIの利用が前提となっている ● NativeのfetchAPIをサポートしていないサードパティ製の APIクライアントはAppRouter環境の ServerComponent内で扱いづらくなった ○ キャッシュと再検証のタイミングの制御が難しい

Slide 24

Slide 24 text

24 4.3 React/Next.jsにおけるデータフェッチ(Server) 4.Connect RSCの利用を前提としたAppRouter環境ではデータフェッチの戦略が大きく変わった ● 標準のfetch APIの利用が前提となっている ● NativeのfetchAPIをサポートしていないサードパティ製の APIクライアントはAppRouter環境の ServerComponent内で扱いづらくなった ○ キャッシュと再検証のタイミングの制御が難しい ➔ fetch経由でConnect エンドポイントをURLベースのRESTっぽく叩きたい

Slide 25

Slide 25 text

25 4.3 React/Next.jsにおけるデータフェッチ(Server) 4.Connect fetch を使用しConnect エンドポイントを叩く ● methodをPOSTとすることでパスベースのRESTと同じ形式でfetchが可能※ ※nextで拡張されたrevalidate option等を利用可能 POSTにおける制約を受ける場合がある ■ fetchリクエストはPOSTメソッドを使用する場合でも自動的にキャッシュされる ■ RouteHandler内に対して実装した場合はキャッシュされない

Slide 26

Slide 26 text

26 まとめ ● ConnectはgRPCをHTTP APIにマッピングしてくれるライブラリ ● 対応言語と主要ライブラリのプラグインが充実しておりお手軽に試せる ● AppRouter環境でもRESTfulなAPIとして一応使える ● フロントエンドのスキーマ駆動開発の一つの選択肢としてgRPCもアリかも?