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
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".
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.
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.
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.
I wrote Real-Time Phoenix and it goes into pretty much everything that I hit when shipping decently large real-time Channel application into production. Like, the basics of "I don't know what a Channel is" into the nuance of how it's a PITA to deploy WS-based applications due to load balancers and long-lived connections.
The new LiveView book is great if you're interested in going fully into Elixir (server/client basically). I use LiveView for my product and it's great.
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.
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.
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.
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.
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.
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.
