Building a chat app in 8 minutes with Phoenix | Hacker News Reader

Building a chat app in 8 minutes with Phoenix

elixircasts.io

271 pointsalekx34 comments

I'm in the very early stages of building what will be a pretty large web app with Phoenix and so far I really like it.

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.

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.

Great screencast, Alex!

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.)

Libraries exist for Swift and JavaScript for sure but honestly the implementation in vanilla JS wasn’t that hard.

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].

1: https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b 2: https://github.com/phoenixframework/phoenix/blob/master/guid...

Thanks! I'm glad you liked it.

You likely want to read this, and my comment there:

https://opkode.com/blog/slacks-bait-and-switch/#comment-3799...

Phoenix has Phoenix Presence for managing the "Who's online" feature. We use replicated CRDTs to transparently manage the presence state across the cluster: https://dockyard.com/blog/2016/03/25/what-makes-phoenix-pres...

As far as native platform clients, we have all major channel clients covered across community libs – Swift/objc/Java/C#

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 agree. Django and Rails still have an advantage here.

I'll be releasing some episodes on this in the coming weeks/months to help shine a light on this topic for others.

You can use Coherence. It's basically Devise for Elixir:

https://github.com/smpallen99/coherence

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.

[0] https://github.com/ueberauth/ueberauth

[1] https://github.com/ueberauth/ueberauth_identity

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.

Elixir will get there eventually though :)

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:

https://pragprog.com/book/lhelph/functional-web-development-...

Here is another write-up that builds the same thing (and reads a bit nicer):

https://medium.com/@Stephanbv/elixir-phoenix-build-a-simple-...

You can't do a build-X-in-low-Y-minutes trope when X involves implementing 30+ line classes.

EDIT: This comment was not appropriate, I apologize.

Why not?

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.

> implies that something is trivial to implement

I don't think it does. It shows something implemented quickly, suggesting that it's a tutorial you can sit down and follow in one go.

Build implies something other than cut-paste or git clone ./make

This title is misleading.

Install a chap app in 8 minutes would be more appropriate, although really it's just sensationalism.

> 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.

I'll agree the "surprisingly small" interpretation is more charitable.

Seems more like a succinct tutorial vs a "look how easy and fast this is". There are definitely alternatives with less code.

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

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:

http://www.erlang-factory.com/sfbay2017/peter-hastie.html

https://www.youtube.com/watch?v=Aa--NDjL9SI

In the talk by Chris Bell, (29:15) they use Flow to migrate millions of records.

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

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.

Nice work, Alex!

Thanks!

Reply on news.ycombinator.com