Stack Inc.
Stack Inc.
🏢

六本木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

https://relay.dev/graphql/connections.htm

  • 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どう？
‣
良いところ
  • もささん - バックエンド視点
      • ‣
      resolver
      • RESTでは複合的なレスポンスを返す時に組み立てるのが大変
      • over fetching、under fetchingの解消によるパフォーマンスの向上
    1. dataloader
      2. ‣
      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