This video is interesting. It explains how you can build - mimic - a Phoenix REST API backend using WS-Channels (stateful) .
Instead of running a one shot HTTP requests (eg the client makes a fetch in JS to the Phoenix API endpoints), the client will establish a websocket, and run a channel.push("endpoint:event", msg). Thanks to pattern matching, the server handles this in somehandle_in("endpoint:event", data, socket) and can broadcast back a response. Thanks to pattern matching, we have a correct routing of the action. This imitates a REST api but the connection is bi-directional, "pseudo-real-time" and stateful.
Note: to communicate from the server but outside of the channel module, you can broadcast on a topic to which the channel subscribed, or use the Registry (cf https://elixirschool.com/blog/live-view-with-channels), and the channel will receive it in a handle_info. Form there, you can push to the client.
The story around the parsing is not completely clear.
This video is interesting. It explains how you can build - mimic - a Phoenix REST API backend using WS-Channels (stateful) .
Instead of running a one shot HTTP requests (eg the client makes a
fetch
in JS to the Phoenix API endpoints), the client will establish a websocket, and run achannel.push("endpoint:event", msg)
. Thanks to pattern matching, the server handles this in somehandle_in("endpoint:event", data, socket)
and canbroadcast
back a response. Thanks to pattern matching, we have a correct routing of the action. This imitates a REST api but the connection is bi-directional, "pseudo-real-time" and stateful.The story around the parsing is not completely clear.
This guy wrote this package channel_handler. To try!
https://www.youtube.com/watch?v=ZBG9VXTycpI