Yeah, it's interesting, I've had the same experience. There's not so much magic lurking beneath the surface. Things are relatively easy to track down when you do need to figure things out; otherwise, things are pretty intuitive.
And when it comes to performance, threads and queueing, not having to deal with duct-tape and gum solutions like Resque (Ruby's "One Ring" (I love it and I hate it)) makes such a big difference.
The best tools are the ones you don’t even notice, and Elixir is an absolute pleasure. You get to focus on the problem with little ceremony. Chat is a really interesting application of Channels, too.
It’s especially interesting to me as my team and I are working on a hosted API called Chatkit that makes it equally easy to add real-time chat to your applications, no matter what technology you’re using: https://pusher.com/chatkit
In addition to basic chat data, we also manage, “Who’s online”, typing indicators, rich media... And more
I highlight those features in particular because I am especially curious what that would look like with Elixir and Pheonix? Managing chat data, especially at scale is quite a hairy problem.
By the way, it simple/clean to subscribe to Elixir Channels on other platforms like Android and iOS, for example? One place we think we can add a lot of value is X-platform client SDKs (JavaScript, Kotlin, Swift, etc.)
You should read Discord’s experience with Elixir if you haven’t already [1]. They didn’t use Phoenix channels though AFAIK.
Also the Phoenix channel implementation uses CRDTs behind the scenes from what I gather. They make problems like user presence much more tractable [2].
I cried in pain when I got to securing my app (uberauth, guardian etc). There's too much to grasp and I ended-up just copy pasting code in frustration.
Elixir & phoenix are fun though. I really like how much easier it is to test an elixir app (functional language).
I've been coding Elixir professionally for a few years, and working in security for longer, and I recommend against using Coherence for anything but toy apps. It's a fairly full-featured Devise-substitute, but the code quality isn't great, and a lot of the less-used features haven't had any sort of real-world testing. There's been a few trivial, high-severity security vulnerabilities in it, and I wouldn't be surprised if more are hiding.
For example, when I last read through the codebase it was common to find features that simply wouldn't work, because the code referenced hardcoded parts of the sample application.
You'll also going to run into a lot of issues trying to migrate off of Coherence if you ever need to support anything other than form based username / password login.
I think it really is worth the effort to go with Ueberauth [0]. You'll need to do more work upfront, but the maintainability gains will quickly pay off. You can even use :ueberauth_identy [1] to provide username / password based auth without too much trouble.
I agree about Coherence. It's good for starter apps, but becomes a liability for anything more serious. Like you say, too much stuff is hardcoded, and moving away from it is painful.
I don't agree about ueberauth though. It assumes too much knowledge on the part of the developer, and is insufficient if one is looking for a "plug and play" authentication solution. I used it with Guardian but in the end moved away from it because using JWTs for authentication is just not a good idea.
I agree about using JWTs for authentication being a poor idea :)
Ueberauth definitely isn't a turnkey solution, but I'm not convinced that turnkey solutions for authentication are possible for real use cases. It's only going to be so long before you run into a customer that needs to integrate you into their SSO provider, and even Devise isn't going to help you then.
What Ueberauth needs, in my opinion, is a hex, built on ueberauth_identity, that adds support for everything people have grown accustomed to from Devise, like password resets, out of the box. You'll still need to do the manual work of mapping credentials to your user resource, but at least you'll be leaving yourself open to eventually supporting other authentication methods, without too much carrying cost in the meantime.
I’ve been writing an API in Phoenix for a high message volume high user count application and it’s pretty amazing how little code I have been writing thus far.
Some concepts are a bit weird like GenServer but it completely decouples your application from your state.
Writing tests was intuitive and one of the few times I’ve been doing TDD that really felt faster than manual testing.
Elixir turns from wonderful to magical once you grasp the GenServer concept and learn about its extensions, namenly GenStage. The producer/consumer pattern and the back-pressure logic will allow you to build incredibly scalable, resilient systems. When I first saw it in action, I was mesmerized.
Just finished reading "Functional Web Development with Elixir, OTP, and Phoenix" and I really like it. It gave me a better understanding of GenServer/OTP:
The build-X-in-low-Y-minutes trope implies that something is trivial to implement (usually by importing middleware that does the heavy lifting). A 30 line class is not trivial.
> The build-X-in-low-Y-minutes trope implies that something is trivial to implement
I think it just implies that the reader can do it without prior knowledge, and that Y minutes is surprisingly small.
You wouldn't write "build a blog in 80,000 minutes" even if it could be done with one line of code. And you wouldn't write "build [complicated thing] 3 minutes" and then show an expert rapidly typing a pre-determined program into an editor.
If a newbie can do it in Y minutes following the tutorial, it seems valid to me.
Has anyone used gen stage / flow for their jobs / small - medium projects ? What are some examples where this could be used ? Game server ? I found an example on YouTube about using it in an automation warehouse but that seems too niche to implement
We use Elixir at Tinfoil Security for our API Security Scanner, and it uses GenStage quite a bit under the hood. It's a big simplification, but we basically have a producer that emits a stream of "scan tasks" to be performed (things like "scan this endpoint for SQL injection"), and then those are consumed by individual worker processes.
It lets us super easily manage things like rate limiting and throttling, while providing backpressure so that an influx of scans (or scans on large APIs) won't overload our infrastructure.
Flow - used it at work for an odd use case where had to merge data from 3 database sources (given to me in csv format) against other data to migrate it. It involved 100s of millions of rows and lots of unknowns so flow was perfect for processing and adaptability whereas spark or many similar solutions felt a bit heavy for the use case.
GenStage specifically: we needed an internal load tester and GenStage plus easy concurrency allowed to quickly build an effective and reliable tool with rate control
Peter Hastie, of sports-news site Bleacher Report, gave a talk at Erlang & Elixir Factory (2017) about GenStage (and Flow) -- there's a description of the talk and an embedded YouTube video at the bottom:
I have a lot of prior Rails / Flask experience and minimal Elixir experience but you can still figure things out for the most part.
It's kind of funny but, even at this Elixir newbie stage I feel more confident reading and tracing most Elixir code vs Ruby.