3 ms·

come to phoenix/elixir land. Channels are amazing and the new views system allows you to seamlessly sync state to a frontend using websockets with almost no jav

come to phoenix/elixir land. Channels are amazing and the new views system allows you to seamlessly sync state to a frontend using websockets with almost no javascript

mathgladiator 5y ago
Perhaps I will. I'm thinking about how I position Adama for both Jamstack and as a reactive data-store (which could feed phoenix/elixer land). I intend to change my marketing away from the "programming language" aspect and more towards "reactive data store".
callamdelaney 5y ago
Channels are basically websockets and only supported inside Phoenix as far as I can tell..
- cultofmetatron 5y ago
  its more than just webockets. Its a prototcol built on web-sockets that also include keepalive and long-polling fallback. You could in theory replicate the protocol in another stack but its more than that. Elixir is uniquely suited to websocket applications. Since a websocket is persistent, you need a process on your end that handles that. Elixir is excellent at creating lightweight threads for managing these connections. Out of the box, you can easily support a few thousand connections on a single server. I know because we did it at my startup. channels powers our entire realtime sync system and its yet to be a bottleneck. It more or less works out of the box without issue. Its almost boring level reliable.
  - callamdelaney 5y ago
    Elixir inherits those properties from the Beam VM it shares with Erlang - both languages are effectively great for this WS/Channels use case - but Channels seems unhelpful unless you're already using phoenix. I can't see that it can be used in say Erlang.
    - prophesi 5y ago
      May not fit your use-case, but you can create an umbrella project with both an Erlang app and an Elixir/Phoenix app, whereby the latter's capable of calling functions in the former.
    - sb8244 5y ago
      Channels are really just a protocol, but that protocol is implemented in Elixir (Phoenix) and so isn't available elsewhere. I think that the important question is "why does this protocol exist?" Most likely, you'll end up solving similar problems as to why Channels exist in the first place. So from a protocol perspective, it's nice that some problems are solved for you.
  - dnautics 5y ago
    Minor nitpick: Channels are transport-agnostic, you could always do them over longpoll, it's not hard to impl a raw tcp socket channel driver, and hell you could probably figure out how to do it in streaming http 1.1. I might to try to do channels over webrtc.
Zealotux 5y ago
My side-project relies heavily on WS, I'm currently using Node.js and it's alright but learning Elixir is my goal during these holidays. Any resource to share to get started? I don't know much about Elixir except it's perfect for such use-cases.
- cultofmetatron 5y ago
  I was a nodejs programmer for almost 8 years before I hopped to elixir. A lot of it was motivated btw elixir's realtime system and concurrency. One of the issues with nodejs is that you're stuck to one process which is single threaded. IE: you're stuck to one core. Yes there are systems like clustering which relies on a master process spawning slave processes and communicating over a bridge but in my experience, its pretty janky. You're making a great move by trying out elixir. It solves a lot of the issues I ran into working with nodejs. Immutability is standard and if you compare two maps, it automatically does a deep evaluation of all the values in each tree. The killer feature however is liveview. Its what meteor WISHES it could be. realtime server push of html to the dom and teh ability to have the frontend trigger events on the backend in a process thats isolated to that specific user. Its a game changer. Anyways, if you're looking for resources to learn. pragprog has a bunch of great books on elixir. Thats how I got started.
- dqv 5y ago
  I got pretty far in the beginning just by reading the docs on Phoenix channels [0]. I was learning Phoenix and ReactJS at the same time and got a pretty simple Redux thunk that interacted with Phoenix Channels in a few days. I'm not sure if that was the optimal way to do it, but it was really cool interacting with the application from IEx (elixir shell). You might find an interesting (albeit more complex) entry point by interacting with Phoenix Channels from your Node.js app using the Channels Node.js client [1] and within the frontend itself. [0]: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html [1]: https://www.npmjs.com/package/phoenix-channels https://www.npmjs.com/package/phoenix-channels
- b5n 5y ago
  Being already familiar with FP I was able to jump right into elixir after running through learn you some erlang. Erlang and elixir are very similar, and you get the bonus of learning a bit about OTP, BEAM, and the underlying philosophy. There's a ton of resources after that, and the docs are easy to use and understand. https://learnyousomeerlang.com/ https://learnyousomeerlang.com/

come to phoenix/elixir land. Channels are amazing and the new views system allows you to seamlessly sync state to a frontend using websockets with almost no javascript

mathgladiator 5y ago

Perhaps I will. I'm thinking about how I position Adama for both Jamstack and as a reactive data-store (which could feed phoenix/elixer land). I intend to change my marketing away from the "programming language" aspect and more towards "reactive data store".

callamdelaney 5y ago

Channels are basically websockets and only supported inside Phoenix as far as I can tell..

cultofmetatron 5y ago
its more than just webockets. Its a prototcol built on web-sockets that also include keepalive and long-polling fallback. You could in theory replicate the protocol in another stack but its more than that. Elixir is uniquely suited to websocket applications. Since a websocket is persistent, you need a process on your end that handles that. Elixir is excellent at creating lightweight threads for managing these connections. Out of the box, you can easily support a few thousand connections on a single server. I know because we did it at my startup. channels powers our entire realtime sync system and its yet to be a bottleneck. It more or less works out of the box without issue. Its almost boring level reliable.
- callamdelaney 5y ago
  Elixir inherits those properties from the Beam VM it shares with Erlang - both languages are effectively great for this WS/Channels use case - but Channels seems unhelpful unless you're already using phoenix. I can't see that it can be used in say Erlang.
  - prophesi 5y ago
    May not fit your use-case, but you can create an umbrella project with both an Erlang app and an Elixir/Phoenix app, whereby the latter's capable of calling functions in the former.
  - sb8244 5y ago
    Channels are really just a protocol, but that protocol is implemented in Elixir (Phoenix) and so isn't available elsewhere. I think that the important question is "why does this protocol exist?" Most likely, you'll end up solving similar problems as to why Channels exist in the first place. So from a protocol perspective, it's nice that some problems are solved for you.
- dnautics 5y ago
  Minor nitpick: Channels are transport-agnostic, you could always do them over longpoll, it's not hard to impl a raw tcp socket channel driver, and hell you could probably figure out how to do it in streaming http 1.1. I might to try to do channels over webrtc.

Zealotux 5y ago

My side-project relies heavily on WS, I'm currently using Node.js and it's alright but learning Elixir is my goal during these holidays. Any resource to share to get started? I don't know much about Elixir except it's perfect for such use-cases.

cultofmetatron 5y ago
I was a nodejs programmer for almost 8 years before I hopped to elixir. A lot of it was motivated btw elixir's realtime system and concurrency. One of the issues with nodejs is that you're stuck to one process which is single threaded. IE: you're stuck to one core. Yes there are systems like clustering which relies on a master process spawning slave processes and communicating over a bridge but in my experience, its pretty janky. You're making a great move by trying out elixir. It solves a lot of the issues I ran into working with nodejs. Immutability is standard and if you compare two maps, it automatically does a deep evaluation of all the values in each tree. The killer feature however is liveview. Its what meteor WISHES it could be. realtime server push of html to the dom and teh ability to have the frontend trigger events on the backend in a process thats isolated to that specific user. Its a game changer. Anyways, if you're looking for resources to learn. pragprog has a bunch of great books on elixir. Thats how I got started.
dqv 5y ago
I got pretty far in the beginning just by reading the docs on Phoenix channels [0]. I was learning Phoenix and ReactJS at the same time and got a pretty simple Redux thunk that interacted with Phoenix Channels in a few days. I'm not sure if that was the optimal way to do it, but it was really cool interacting with the application from IEx (elixir shell). You might find an interesting (albeit more complex) entry point by interacting with Phoenix Channels from your Node.js app using the Channels Node.js client [1] and within the frontend itself. [0]: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html [1]: https://www.npmjs.com/package/phoenix-channels https://www.npmjs.com/package/phoenix-channels
b5n 5y ago
Being already familiar with FP I was able to jump right into elixir after running through learn you some erlang. Erlang and elixir are very similar, and you get the bonus of learning a bit about OTP, BEAM, and the underlying philosophy. There's a ton of resources after that, and the docs are easy to use and understand. https://learnyousomeerlang.com/ https://learnyousomeerlang.com/