Key concepts to remember from real time phoenix book.

RealTimePhoenixGist.md

• Scalability triangle
  • Performance, maintenance, cost
• WS lifecycle
  • inspect ws inside browser dev tools
  • Initial call is made using HTTP and then 101 protocol switch response is received and the connection is upgraded to ws
  • Optional heartbeat messages are used in check connection.
  • Phoenix pings server every 30 seconds.
  • Server will close connection if it doesn't receive ping within 60 seconds.
  • use wss:// for security.
  • ws doesn't follow CORS policy.
  • We have to manually add CSRF and domain checking capability.
• Long polling vs ws
  • Each time header is processed.
  • It's not realtime if the long polling time is heigher.
  • Easier to loadbalance.
• Socket forms the basis for a persistent connection.
  • connect and id are the major functions to care.
• Channels help in grouping of topics.
  • join, handle_in, handle_info, handle_out
• Each channel is represented as a process. So split according to the load.
  • Accept or reject a request to join.
  • Handle messages from the client.
  • Handle messages from the PubSub.
  • Push messages to the client.
• Phoenix Pub.Sub is used to route messages to and from channels. broadcast, broadcast_from, subscribe, unsubscribe are the main methods. node_name, direct_broadcast are other methods.
• Channel topics can end with "*" which is a wild card symbol.
• Phoenix message structure.
  • [ join ref, message ref, topic, event, payload]
• PubSub can broadcast message to clients directly.
• If we want to customize broadcast we can have handle_out handler. we need to have intercept['message_name'] at the top of the channel module.
• Official javascript client support socket connection, channel connection
  • socket.connect, channel.join, channel.on, channel.push are frequently used.
• use Phoenix.Token.sign, Phoenix.Token.verify for initail socket connection(Domain checking)
• Phoenix support at most once delivery.
• We can send recurring message(push) using Process.send_after and handle_info
• We can use handle_out and Process.send_after to buffer messages.
• We can test sockets using ChannelCase.
  • connect is used to connect a socket.
  • socket is used to get socket instance and subscribe_and_join to join channel
  • capture_log is used to capture Logger output
  • assert_reply is used to check reply from server
  • assert_push to check push
• Use statsD for metrics
• Use socket ref to make asynchronous reply.
  • ref = socket_ref(socket)
  • Phoenix.Channel.reply(ref, {:ok, %{ping: "pong"}}) inside task or other process.
• For handling data pipelines use GenStage
• put_resp_header("Cache-Control", "no-store, must-revalidate") to rerender on forward and backwork browser navigation.
• Use Hound for browser testing.
• Use Phoenix.Tracker to track channels
  • use track, handle_diff and list functions.
• Presence is provided by phoenix javascript client to listen for handle_diff. presence_diff message is sent to client on each handle_diff call back. presence.onSync is called in client side.
• Use mix or distillery release.
• Use rolling or blue green deployments.
• Use libcluster for clustering.
• We can provide origin checking as config, other configs include compress etc.
• generational vs full sweep garbage collection.
• :erlang.process_info(pid, :memory)
• :erlang.garbage_collect(pid)
• Process hibernation prevents long term storage.
• we can pass hibernate_after parameter to GenServers.
• env ERL_FULLSWEEP_AFTER 20
• use observer_cli
• Phoenix liveview
• Use noUI components to wrap components with socket and channel in React kind of front ends.