概要
↓の続き。 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に頼った
デフォルトでは、上記のサブスクリプション実装は、各サブスクリプションを完全に分離して処理します。
しかし、ブロードキャストを設定することで、この動作を最適化することができます。
