†home#indexの処理を見た際など、いくつかのコード中にストリーミングに関する処理がありました。今回はそれらについて見ていき、Mastodonでどのようにストリーミング処理が行われているのかを確認しましょう。†home#indexを見た際、ストリーミングに利用するURLが以下のように設定されていました。endRails.configuration.xってなんだろ。アプリ独自の設定書くときに使っていいのかな。indexのレンダリングが行われ、クライアントにはinitial-stateとしてストリーミングAPIのURLが渡されることになります。開発環境だと以下のようになります。"access_token":"8920c1d8279002fa0f6b74f96bf7c971f997318755a35f5a26b511229a2786b7",ここで重要なのは、ストリーミングで使われるサーバがMastodon本体とは別、ということです。†サーバが別ということが確認できましたが、まずはサーバの前にクライアントの確認をしましょう。クライアント処理はReactのMastodonクラスに書かれています。}createStreamで接続、引数で渡しているハンドラオブジェクト?っていうのかな?のreceivedでサーバからデータを受信したときにタイムラインの更新を行っている雰囲気です。†createStreamを確認しましょう。ws;};というわけで、「/api/v1/streaming/」というURLにアクセスが行われるようです。「/api/v1/streaming/」で探してみると、streamingディレクトリにindex.jsがあるのに気づきます。ストリーミング処理はJavascript(Node)で書かれているようです。最後の方から見ると以下の記述があります。})accountFromTokenは名前の通り、アクセストークンからアカウントのIDを取得しています。streamFromです。}listenerを定義しています。listenerではmessageが送られてきたらそれをoutputオブジェクトに書き込むということをしています。これにより、接続先のクライアントに情報が送られるということになります。†というわけで今度はsubscribe。}よくあるイベントリスナー的なコードです。redisClient.psubscribe('timeline:*')Redisに接続し、Redisからメッセージが飛んで来たら対応するcallback(listener)が呼び出されるようになっています。Redisへの書き込みが行われることでストリーミングサーバが反応→クライアントにプッシュが行われるようです。subscribeの略のようです。†というわけで後はRedisに書き込んでいる場所を探せばいいことになります。実はすでに一回出てきていました。ここからRallsになります。endいろいろなWorkerが呼ばれていますが、DistributionWorkerを見てみる。endendさらにFanOutOnWriteService。†FeedManagerのpushメソッド。endなかなかしぶとい(笑)。PushUpdateWorkerです。endend「timeline:アカウントID」への書き込みがありました。これで、Redisに書き込みが行われ、最終的にクライアントに届くということになります。フォロワーにトゥートが届く仕組みもほぼ同じです。リモートインスタンスにいるフォロワーの場合は仕組みがかなり複雑になっていますが、ひとつずつ確認していけば理解できると思います。今回はストリーミングの処理を見てきました。ストリーミングは次の3つから構成されています。クライアント側の接続、サーバから送られてきたら表示処理サーバ側その1。クライアントへデータを送る部分(Node)サーバ側その2。送るデータの書き込み部分(Rails)サーバ内での情報の受け渡しにはRedisが使われていました。ここまでで、初期画面表示、トゥート作成、フォロー、リモートフォロー、ストリーミングと一通りの処理を見てきたことになります。実はそろそろ1.4が出そうですが、これにて「Mastodonを読む」完結としたいと思います。