🏢

六本木GraphQL

第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

第5回 座談会 4/21 19時-

  • tenntennさん、vvakameさん、もささん、sonatard

トピック

GraphQLエコシステムがJSに依存問題
最近は各言語でエコシステムの開発が進んでいる
GoとGraphQLのエコシステム
アプリ開発
  • apollo-ios、apollo-android
テスト
  • バックエンドのresolverのテストどうしている?
    • わかめさん、そな太書いてない
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どう?
良いところ
  • もささん - バックエンド視点
    1. resolver
      • RESTでは複合的なレスポンスを返す時に組み立てるのが大変
      • over fetching、under fetchingの解消によるパフォーマンスの向上
    2. dataloader
    3. Federation
      • LayerXでは既存サービスがREST、別サービスがGraphQL
        • これらを統合するGatewayとしてFederationを検討中
      他社事例 - MicroservicesとGraphQL
  • そな太、わかめさん
  • フロント - SPA作る上での開発スピードの向上
    over fetching under fetchingの解消
    • 画面ごとのユースケースに合わせて1つのQueryを投げれば良い
    • 複数のAPIを叩く必要はない
      • 今までは複数のAPIを叩くのを回避するためにRestfullではなくRestishなAPIを用意するか、BFFを用意する必要があった
        • BFFは機種ごと+画面ごとにAPIを用意するのが大変
    キャッシュのおかげでFetchに関するクライアントサイドでの状態管理は不要になった
    Query、mutationのresponse活用
    • Queryでキャッシュ、Mutationのレスポンスでキャッシュの更新
    • 我々がしていたのは状態管理というよりFetchのキャッシュだったという気づき
    • 多くのボイラーテンプレートを書いていた
      • GraphQLからRESTにReact Query、vercelのSWR、Redux ToolKitのRTK Queryなどが逆輸入
    Mutationのレスポンスのベストプラクティス
    • 編集する系はそのオブジェクトを返せば良さそう
    • 新規追加する場合
      • その新規追加されたオブジェクトを返す?
        • クライアント側(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
      role、permission
    • エラーハンドリング
    • Optional or 非Optional
  • GraphQLクライアントフレームワーク
    • キャッシュ
    • Fragment colocation
  • 便利と思うまでの道のりが遠い
    • レールが必要
  • やってみないと利便性を感じ辛い
  • チームメンバーに普及するために伝えることも難しい
  • 基本的な学習をして、それをすべて反映するまでの時間がかかる
  • 誤用して便利さを体感せずに終わってしまう危険性
RelayとApollo
  • Relayの方が細かいところまで開発体験が良い
  • けどユーザコミュニティはApolloの方が強い
    • Relayの方が制約強そうで怖い...?
  • Relay Server Specification