学習バンザイITエンジニアの精神安穏日記

ITエンジニアというより、IT系雑務者

英語苦手な人がGraphQL-RubyのSubscriptionを読解した思考過程2(OverViewの詳細)

概要

↓の続き。 zorin.hateblo.jp

今回は、OverViewの下の方を更に読みます。

Subscription Type

queryやmutationと同様の概念ということで合っていた。

ということで、mutationなどと同じで、以下のように書けるという想像ができる。 yatta

class SubscriptionType < Schemaなんたら
  field xxxx, null , aaa

  def xxxx
  end
end

Subscription Classes

上の理解が正しければ、mutationTypeなどと同じような 

DeletePostのような感覚になることでしょう。

Triggers

After an event occurs in our application, triggers begin the update process by sending a name and payload to GraphQL.

  • (アプリケーションがクライアントサイド・サーバーサイドどっちを指すのかわからないが)
  • イベントが発生した後、更新処理を開始する
  • payloadと名前をGraphQLに送信することによって、

  • iOSアプリでチャットメッセージが発生しました。

  • TriggersはGraphQL(モデル?)に対して、識別名とpayloadを送って、更新処理を開始します。

GraphQLというのが、なぜsubscriptionや何やら出ないのかが不明かもしれん

※要読み込み

疑問ポイント Triggerというのは、サーバーサイド側に常駐するやつなのかが疑問?

Implementation

Besides the GraphQL component, your application must provide some subscription-related plumbing, for example:

GraphQL コンポーネントの他にもサーバーサイドでsubscriptionのための関連処理を実装する必要があるよね。

例 - サブスクリプション開始の管理: だれが何をsubscribeしてるか追跡する - どうやってサーバー側からpayloadsをクライアントに運ぶか - どうやってサーバー側から再送信処理を実行するか

現状イメージついていないが、 これが、ActionCableやPusher, Ablyなどの部分になるそうである

Broadcasts

DeepLに頼った

デフォルトでは、上記のサブスクリプション実装は、各サブスクリプションを完全に分離して処理します。

しかし、ブロードキャストを設定することで、この動作を最適化することができます。