Ruby: ロングポーリングについて

Question

ロングポーリングについて知っている知識
リクエストがサーバに送信する。(ajax or fetch)
サーバはメッセージがあるまで接続を閉じないで待つ(ruby: ここの部分の実装が分からない)
メッセージが現れたら、サーバはそのデータでリクエストに応答する(ruby: renderで返す感じ？（よく分からない))
ブラウザはすぐに新しいリクエストを作る

現状のコード

Post時の該当ソース

 //divの要素です（擬似インプット)
 #input.area contenteditable="true"
 input.btn type="submit" value="post" onclick="send()"

  function send() {
    var text = document.getElementById("input").textContent;
    $.ajax({
        url: `/dm`,
        type: "POST",
        data: {message: {dm: text}},
        dataType: "json",
        }).done(function(data){
          console.log(data);
          console.log(data.dm);
        }).fail(function(data){
          console.log("fail");
    });
  }

class DmController < ApplicationController

  def create
    dm = Dm.new(params)
    respond_to do |format|
      if dm.save
        format.js
        format.json { render json: dm }
      else
        redirect_to root_path
      end
    end
  end

  private

  def params
    params.require(:message).permit(:dm).merge(user_info: current_user)
  end
end

実現したいこと

リアルタイムに近い通信サービスを作りたく、その手段としてロングポーリングを使って実現したいと考えています。（ショートポーリングの実装はできます)
リアルタイム通信処理をやりたいというと、websokect通信もあると思いますが今回はあくまでもロングポーリングを使った方法を知りたいと考えています。

困っていること

ショートポーリングの実装は、ajaxを定期的に呼び出すことで簡単に実装することができたのですが、ロングポーリングにいては、何をどうしたらよいかが分からない状態でいます。
特にバックエンド側の、メッセージを受け取るまで閉じずに待つという処理が分からないです。（概念は理解できているのですがコードの書き方が分からないです。)
そのため、バックエンド側のコードを交えてご教示いただけると幸いです。

試したこと
動かないですが、私の中でイメージしているロングポーリングの処理です。

class DmController < ApplicationController

  def ajax
    # {message {cnt:9}} パラメーターです。cntはviewに表示されているメッセージの数です。
    # 例)DBにはメッセージが10こあるとします。
    dm = Dm.all
    num = dm.count - params[:message][:cnt].to_i
    # => 1
    dm.last(num)
    respond_to do |format|
      if dm.present?
        format.js
        format.json { render json: dm }
      else
        wait
      end
    end
  end

  def wait dm = nil
    sleep(60) if dm.blank? # sleepをkillしてjsonを返す
    respond_to do |format|
      format.js
      format.json { render json: dm }
    end
  end

  def create
    dm = Dm.new(params)
    respond_to do |format|
      if dm.save
        wait(dm)
      else
        redirect_to root_path
      end
    end
  end

  private

  def params
    params.require(:message).permit(:dm).merge(user_info: current_user)
  end
end

更新をバックエンドで待ち続ける時

#dmは取得したレコード
loop do
break if dm.present?
sleep 0.1
end

Answer 1

ActionCable(WebSocket)を使う事はできますが、ロングポーリングについては対応しているという話を聞きません。

Railsでは、イベントがあるまでsleepするしかないように思います。

もし実装する必要に駆られたならば、Railsとは別のロングポーリング対応のサーバーを開発・使用すると思います。

---

追記

試してはいませんが、こんな感じですかね
(複数人同時に接続するとリソース食い過ぎで酷いことになると思います。)

def wait_message(cnt)
  dm = Dm.where("id > ?", cnt)
  i = 0
  sleep(1) until dm.exists? || (i+=1) > 60
  return dm
end

def ajax
  dm = wait_message(params[:message][:cnt].to_i)
  respond_to do |format|
    format.js
    format.json{ render json: dm }
  end
end

Comments

[nanase21]

actioncableは試しました。ローカルで遊ぶ分にはいいのですが、サービスに応用すると一気にハードルが高くなるので極力XHRで対応で実装したいと考えています。(今回の実装も遊びですが...)
私も、sleepを使用するつもりではいます。
>もし実装する必要に駆られたならば、Railsとは別のロングポーリング対応のサーバーを開発・使用すると思います。
そんなに大規模なサービスを作ろうと考えていないのでポーリング対応のサーバーを開発・使用などは考えてないです。（作るにしてもポートフォリオ的になノリでしか作る予定がないので...)

[nanase21]

すごく安易な発想ですが、データの中身が更新されるまで無限ループするのはまずいでしょうか？（サーバーの負荷的な問題)

[asm]

sleep(0.1) until 更新されているか? || タイムアウト判定
みたいに待つのが普通じゃないですかね

[nanase21]

> sleep(0.1) until 更新されているか? || タイムアウト判定
私の理解不足で申し訳ございません。
> 更新されているか?
については、object.present?見たいな感じで大丈夫かなと思うのですが
> タイムアウト判定
については、どのように書けばいいのでしょうか？
それと、sleepを使った場合は、常にDBにアクセスされているのでしょうか？
もしそうではない場合は、loopなどの処理を入れないとsleep期間が終わったら空のオブジェクトを返すことになるのでしょうか？
ご迷惑をお掛けしますが、もう少しだけご教示いただけると幸いです。
それと、質問欄に試したことを追記したので見て頂きたいです。

[nanase21]

ご教示いただきありがとうございました。
一点だけお聞きしたいことがあります。
> dm = Dm.where("id > ?", cnt)
についてなんですが、whereの中の"id > ?"は何をしているのでしょうか？
プログラミング初学者のためご教示いただけると幸いです。(whereの中身が何をやっているか分からない...)
私のDMを取得するイメージとしては、ajaxでviewに表示されているレコード数とroom_idをajaxで送ってきて
get_dm = DM.where(room_id: params[room_id]).count
res = get_dm - params[:cnt]
res.last(num)
のような形で最新のdmを取得しようとしているのですが、@asmさんの.where("id > ?", cnt)で対応できるのでしょうか？

[asm]

https://railsguides.jp/active_record_querying.html#配列で表された条件
ここでは、レコードのidがデフォルト設定では単調増加になる事を利用しております。
新しいDMは常に古い(=既に受信済みの)DMよりも大きいidになるので、
js側で受信済みの中で最新のid保持し送信することで

get_dm = DM.where("room_id = ? AND id > ?", params[:room_id], params[:old_id])

で取れる筈です。

また、別のアイデアとしてはcreated_atを利用して最終更新時刻から新しいものを取る方法もあります。

このへんの話は https://qiita.com/jnchito/items/8bbbf3e803e56b97a498
がちょっと詳しいです

[nanase21]

ご教示いただきありがとうございます。
なるほど。
私の考えていた方法では、メッセージの方法ではメッセージを一回全て取得する必要がありましたが
、@asmさんの方では、id(例) params[id:5])の場合、6以上のidのメッセージがあるかどうかだけを判定している感じなんですね。（思いつきませんでした。created_atも良さそうですね。)
とても勉強になりました。????????‍♂️
このようなソートをする場合は、ソート対象のカラムに対してindexを貼ったほうがいいのでしょうか？（メッセージ量が多くなるとソートに時間がかかるため）

[asm]

貼った方が無難です。
ただ、５人程度で違いが出るほどログ埋められるかというと疑問ですので
気分以上の効果はないと思いますが

idだとそのへん貼ってあるので楽ってのもあります。

[nanase21]

承知いたしました。

この度は、何度も質問をしてしまいご迷惑をおかけしてしまい申し訳ございませんでした。
@asmさんのおかげでとても勉強になりました。

[nanase21]

最後に一点だけお聞きしたのですが、タイムアウトの時間を６０秒にしたのには何か意図があるのでしょうか？
それと、ロングポーリングを実装する場合、ブラウザのタイムアウトも考慮する必要があるのでしょうか？（セッション時間が長いとタイムアウトで途切れるため)

[asm]

残念ながら適当ですし
やったことないからよくわからん　と言うのが正直なところです

[nanase21]

承知いたしました。
ご教示いただきありがとうございました。

Answer 2

サーバー側プログラムとしては、

メッセージが現れたら、

まで、待てばいいとおもいます。
具体的に何をトリガーに「メッセージが現れた」と判断できるのでしょうか？

ロングポーリングということだと、サーバー側でクライアント数だけのプロセスが動き続けることになりますが、リソース的に大丈夫なんでしょうか？
数人ならともかく、クライアントが多い場合、別のフレームワークを検討した方が良いと思います。

Comments

[nanase21]

クライアント数は5人程度を見込んでいます。（グルチャをイメージしています）
あくまでも練習の一環で作っているだけなので、サービス開発に応用するといった想定はしていないです。
なので今現在はロングポーリングのバックエンド側の処理についてご教示いただきたく思っています。
＞具体的に何をトリガーに「メッセージが現れた」と判断できるのでしょうか？
これに関しては、私も分からないです。（Webで調べた程度の知識なので）
なので、ajaxでサーバーにアクセスした時に、どう待てばよいかが分からないです。（sleepメソッドがrubyにはあるので処理を遅延させることはできそうですが待っている間、メッセージの受信をどうしたらよいかが分からずにいます。)

[otn]

他のクライアントからのAjaxでのリクエストをトリガーにしたい
ということですね。
一般論で言えば、
・DBを経由する
・プロセス間通信をする方法をなんとか考える
などを思いつきますが、

Rails関連のgemを使ったいい解法があるかもしれないので、
・グループチャットをイメージしている
・クライアントからのAjaxでのメッセージ投稿をトリガーに他のクライアントにレスポンスを返したい
というあたりを質問に追記して、他の方の回答をお待ちください。

[nanase21]

DBのレコードが増えるまで、サーバー側で無限ループさせるのはサーバーに負荷がかかりますでしょうか？（10秒or20秒毎にレコードの数を取得して増えていなければ繰り返す感じです。)

[otn]

5クライアントくらいならいいんじゃないでしょうか。
5クライアントが10秒ごとだと、平均で2秒に1回なので、「レコードが増えるまで」のチェックを軽いSQLで行えば問題ないと思います。

また、クライアント側の応答待ちがタイムアウトになる可能性がある場合には、データが無くてもタイムアウトするまでにレスポンスを返す必要があります。