第6回 座談会 5/11 19時-
- tenntennさん、vvakameさん、もささん、sonatard
トピック
‣
- RESTに依存したエコシステム
- Cloud Logging
- Cloud Trace
- CDN
‣
- ゼロ値とnullを区別しいたいからOptional
- サービスの可用性のためのOptional
‣
- errors
- Unionのerror
‣
‣
- deprecated
‣
- 未来にはdeferとstream 仕様策定段階
- https://www.youtube.com/watch?v=icv_Pq06aOY
第5回 座談会 4/21 19時-
- tenntennさん、vvakameさん、もささん、sonatard
トピック
‣
‣
- 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)
‣
‣
- apollo-ios、apollo-android
‣
- バックエンドのresolverのテストどうしている?
- わかめさん、そな太書いてない
- わかめさんは、クエリーごとに前回の結果との比較テスト
- そな太は、E2Eテスト
- gqlgenc https://github.com/Yamashou/gqlgenc @yamashou
‣
- DBは?
- バックエンドの言語は?
- バックエンドのアーキテクチャは?
‣
- 開発規模
- アーキテクチャ
- プロダクト特性
- これから作る人全員!
‣
第4回 座談会 4/8 19時-
- tenntennさん、vvakameさん、sonatard、もささん
トピック
‣
‣
- スキーマを定義して、各言語の実装はジェネレーターを用いて生成する
- 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を定義
‣
‣
- REST風にしない
‣
- Appify
- 権限周り role、permission
- わかめさんPermissionだけでは足りないことろがあり、そこは実行側が役割を与えたい
- バリデーション validate
- 指定ミスが起きないか?
- バックエンドの実装抜けより検出が容易、静的解析もできる
- directiveだとクライアント開発者に仕様を表明できる
- inputの文字数制限など
‣
- Union型の活用
‣
- 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)
トピック
‣
- 全員Go+gqlgen
‣
- Appify Shopify、BASE、CAMPFIRE CommuniityのアプリをNoCodeで作れるサービス
- 宣言的UI (React、SwiftUI、Jetpack Compose)
- 宣言的データフェッチング (GraphQL)
‣
- Merpay, Inc. Solutions team
- 技術書典Web開発担当
‣
- Merpay, Inc. Experts team
- Appify Technologiesでお手伝い中
‣
- LayerX インボイス作ってるよ!
- 最近GraphQLはじめました
‣
- 最近GraphQLを始めました
- 最近は gqldoc を作った Code-Hex さんと一緒に仕事してます
‣
‣
- もささん - バックエンド視点
- 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を定義する
‣
‣
‣
‣
‣
‣
‣
‣
‣
‣
‣
- 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
‣
- 便利と思うまでの道のりが遠い
- レールが必要
- やってみないと利便性を感じ辛い
- チームメンバーに普及するために伝えることも難しい
- 基本的な学習をして、それをすべて反映するまでの時間がかかる
- 誤用して便利さを体感せずに終わってしまう危険性
‣
- Relayの方が細かいところまで開発体験が良い
- けどユーザコミュニティはApolloの方が強い
- Relayの方が制約強そうで怖い...?
- Relay Server Specification