3

I'm building a Javascript client app that has live communication with a Phoenix server, and wants to know if a message pushed to the server has been received. It looks like Phoenix's socket.js wants me to use something like:

channel.push("mymessage", {data: 123})
  .receive("ok", function(){ console.log("Message pushed successfully"); });

However, I can't get this event handler to fire unless I change my return value on the Phoenix app to be {:reply, :ok, socket}, like so:

  def handle_in("mymessage", %{"data" => data} = payload, socket) do
    {:reply, :ok, socket}
    # not {:noreply, socket}
  end

I guess it makes sense that {:noreply, socket} doesn't actually send a message in response to the client, but in what case would you want to send a message to the server and not have it let you know that it worked? Or am I misunderstanding something? I feel like with normal HTTP requests, you always check if the request was successful from the client.

you786
  • 3,659
  • 5
  • 48
  • 74

1 Answers1

1

You're right: {:reply, :ok, socket} will send a reply message with "ok", and {:noreply, socket} won't send anything in response. You should use the former if you want to ensure that the message was sent, but often that's impractical or unnecessary (think of broadcasting a chat message to thousands of connected users--it's impractical to track "ack" messages for all of them).

I feel like with normal HTTP requests, you always check if the request was successful from the client.

WebSockets exist for situations that normal HTTP requests don't work well, and one-way communication is one of those cases.

shosti
  • 7,332
  • 4
  • 37
  • 42
  • But in that example, the ack would be only to the person who sends the chat (which would be useful), not to the recipients of the broadcast. – you786 Jul 30 '17 at 16:03
  • Sure, in your example it would be fine. I'm just saying that in general, one-way communication is common with WebSockets (hence the "noreply" option). – shosti Jul 31 '17 at 17:01