第6回 座談会 5/11 19時-
- tenntennさん、vvakameさん、もささん、sonatard
トピック
GraphQLの辛い点
- RESTに依存したエコシステム
- Cloud Logging
- Cloud Trace
- CDN
Optional、非Optional
- ゼロ値とnullを区別しいたいからOptional
- サービスの可用性のためのOptional
エラーハンドリング
- errors
- Unionのerror
ページネションとキャッシュ
APIバージョンと互換性
- deprecated
パフォーマンスとGraphQL
- 未来にはdeferとstream 仕様策定段階
- https://www.youtube.com/watch?v=icv_Pq06aOY
第5回 座談会 4/21 19時-
- tenntennさん、vvakameさん、もささん、sonatard
トピック
GraphQLエコシステムがJSに依存問題
最近は各言語でエコシステムの開発が進んでいる
- apollo-ios (https://github.com/apollographql/apollo-ios/projects/2) 、apollo-android (https://github.com/apollographql/apollo-android/projects/1) もSwift、Kotlilnでパーサやgenを実装
- NetflixがJVM向けにFederationライブラリを開発 (DGS)
GoとGraphQLのエコシステム
アプリ開発
- apollo-ios、apollo-android
テスト
- バックエンドのresolverのテストどうしている？
- わかめさん、そな太書いてない
- わかめさんは、クエリーごとに前回の結果との比較テスト
- そな太は、E2Eテスト
- gqlgenc https://github.com/Yamashou/gqlgenc yamashou
GraphQLとアーキテクチャ
- DBは？
- バックエンドの言語は？
- バックエンドのアーキテクチャは？
GraphQLは誰におすすめできる？
- 開発規模
- アーキテクチャ
- プロダクト特性
- これから作る人全員！
トーク関連リンク
第4回 座談会 4/8 19時-
- tenntennさん、vvakameさん、sonatard、もささん
トピック
GraphQLのツールとしての利便性
スキーマ駆動開発
- スキーマを定義して、各言語の実装はジェネレーターを用いて生成する
- OpenAPIやgRPCのProtocol Buffersと同様
- 上記と比較したメリット
- introspection、OpenAPIやgRPCで問題になるスキーマ管理の問題で悩まない
- directive validationを書くのがとても容易、Pluginとして作る必要がない
- Union型?
フロント
- Redux middlewareと比較してuseQueryは便利
- data、loading、errorが返ってくる、スコープがクエリー実行単位に閉じる
- ReduxでもmiddlewareではなくuseAsyncなどを使って結果だけをdispatchすれば同じ体験は得られる
- 1クエリーですべての情報が手に入るのでシンプルにコードが減る
- Fragment colocation
- コンポーネントのPropに対応したFragmentを定義
バックエンド - スキーマ設計
viewer, node
- REST風にしない
directiveの活用
- Appify
- 権限周り role、permission
- わかめさんPermissionだけでは足りないことろがあり、そこは実行側が役割を与えたい
- バリデーション validate
- 指定ミスが起きないか？
- バックエンドの実装抜けより検出が容易、静的解析もできる
- directiveだとクライアント開発者に仕様を表明できる
- inputの文字数制限など
GraphQL Cursor Connections Specification
- Union型の活用
gqlgenとコード生成
- GraphQLに対応したファイルに生成スキーマの変数名など変わればGoのコードも自動変更
上記が揃うと運用コストは低い
- フロントエンドエンジニアの開発フロー
- バックエンドエンジニアの開発フロー
1. コンポーネントで使う値をFragmetとして定義
2. コンポーネントはそのFragmentをPropとして利用する。そのPropを利用してViewを実装。
3. Fetchしたい箇所でQueryを実行。1で定義したFragmentを取得。
4. 取得したフラグメントをコンポーネントに渡す。
従来のREST+Reduxと比較して、middlewareでFSAを実装して、複数のAPIを叩いて、DomainやViewModelに変換して、正規化を設計して、actionを実装して、dispatchでStoreに保存して、StoreからSelectorで受け取って、という実装が不要になる。
アーキテクチャができあがっていれば、日常的な開発の追加コストはない？
1. GraphQLスキーマを設計する
2. スキーマにあわせてresolverごとにDBから引く
3. フィールドのroleを決定してスキーマに追加する
4. オブジェクトのPermissionを決定してスキーマに追加する
5. Queryを書いてクライアントのコード生成をしてE2Eテストを書く
OpenAPI+RESTと比較してアーキテクチャができあがっていれば、日常的な開発の追加コストはGraphQL特有のスキーマ設計コストだけ？
第3回 パネルディスカッション 3/29 19時-
- tenntennさん、vvakameさん、sonatard、もささん、(syumai)
トピック
自己紹介、GraphQL歴について
- 全員Go+gqlgen
そな太
- Appify Shopify、BASE、CAMPFIRE CommuniityのアプリをNoCodeで作れるサービス
- 宣言的UI (React、SwiftUI、Jetpack Compose)
- 宣言的データフェッチング (GraphQL)
vvakame (わかめ)
- Merpay, Inc. Solutions team
- 技術書典Web開発担当
tenntenn
- Merpay, Inc. Experts team
- Appify Technologiesでお手伝い中
mosa_siru
- LayerX インボイス作ってるよ！
- 最近GraphQLはじめました
syumai
- 最近GraphQLを始めました
- 最近は gqldoc を作った Code-Hex さんと一緒に仕事してます
改めてGraphQLどう？
良いところ
- もささん - バックエンド視点
- RESTでは複合的なレスポンスを返す時に組み立てるのが大変
- over fetching、under fetchingの解消によるパフォーマンスの向上
- dataloader
- LayerXでは既存サービスがREST、別サービスがGraphQL
- これらを統合するGatewayとしてFederationを検討中
- GitHubがGoでMicroservicesを作成
- Netflix DGS
- https://netflix.github.io/dgs/
- https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
- Uber
- https://eng.uber.com/microservice-architecture/ GraphQLと直接関係はないけど
- https://eng.uber.com/graphql-data-hydration-customer-care/
- TwitterもバックエンドはGraphQL
- ユーザのためにGraphQLをラップしたREST APIを公開
- そな太、わかめさん
- 画面ごとのユースケースに合わせて1つのQueryを投げれば良い
- 複数のAPIを叩く必要はない
- 今までは複数のAPIを叩くのを回避するためにRestfullではなくRestishなAPIを用意するか、BFFを用意する必要があった
- BFFは機種ごと+画面ごとにAPIを用意するのが大変
- Queryでキャッシュ、Mutationのレスポンスでキャッシュの更新
- 我々がしていたのは状態管理というよりFetchのキャッシュだったという気づき
- 多くのボイラーテンプレートを書いていた
- GraphQLからRESTにReact Query、vercelのSWR、Redux ToolKitのRTK Queryなどが逆輸入
- 編集する系はそのオブジェクトを返せば良さそう
- 新規追加する場合
- その新規追加されたオブジェクトを返す？
- クライアント側（Apollo）でCacheをいじるのがいかにもバグりそうな感じ
- その新規追加されたオブジェクトが含まれるリストを返す？
- Relayみたいなページングしてる場合はどうするのが良い？
- そな太
- MVC、MVVM、Redux、Clean Architectureなど考えないで済む
- 考えるのはView視点でのコンポーネント分割だけ
- あとはコンポーネントにあわせてFragmentを定義する
resolver
Federation
他社事例 - MicroservicesとGraphQL
フロント - SPA作る上での開発スピードの向上
over fetching under fetchingの解消
キャッシュのおかげでFetchに関するクライアントサイドでの状態管理は不要になった
Query、mutationのresponse活用
Mutationのレスポンスのベストプラクティス
フロントアーキテクチャの簡素化
学習コストが高い問題
学ぶ必要があること
- GraphQL spec
- Query、Mutation、Subscription、union、directive、Enum
- Relay Server Specification
- Connection、node interface
- GraphQLサーバフレームワーク
- resolver、directive、model binding
- GraphQLサーバ設計
- スキーマ設計
- viewer
- エラーハンドリング
- Optional or 非Optional
- GraphQLクライアントフレームワーク
- キャッシュ
- Fragment colocation
role、permission
- 便利と思うまでの道のりが遠い
- レールが必要
- やってみないと利便性を感じ辛い
- チームメンバーに普及するために伝えることも難しい
- 基本的な学習をして、それをすべて反映するまでの時間がかかる
- 誤用して便利さを体感せずに終わってしまう危険性
RelayとApollo
- Relayの方が細かいところまで開発体験が良い
- けどユーザコミュニティはApolloの方が強い
- Relayの方が制約強そうで怖い...?
- Relay Server Specification