Phoenix / LiveBeats author here – happy to answer any questions about Phoenix, LiveBeats, or Fly.io. We had a ton of fun building this. It's way more fun to see where folks are connecting to and what kind of pings they get than I would have thought. I also just put out a screencast showing how easy it is to deploy a new phoenix instance on another continent and watch it cluster together with the rest automatically:
https://www.youtube.com/watch?v=JrqBudJd2YM&feature=youtu.be
That video is really cool, it's so impressive how the Elixir/Phoenix/Fly combination works together. Just for context could you give an idea of what that app would cost to run at the scale you're demoing there per month? I think it's 7 DB instances + 7 DB volumes + 5 app instances + 5 app volumes at the end of that video, but not sure what instance sizes etc. you're looking at for this.
Also totally random question - how come the flag for the chrismccord user is different for the two users at 9:25 https://youtu.be/JrqBudJd2YM?t=565? Is that just something in your app, or is there something in Fly reporting at a different granularity? I'm not familiar with the flag in the left window so might be missing something obvious!
You can run LiveBeats on the smallest instances. You end up needing 2 small VMs and 2 10GB disks per region. So it costs about $6.80 per region to get started. ~$150/mo to run in all our regions with the small VMs. Most apps only need 3-6 regions to get really great performance.
The interesting thing about adding regions is that it also scales capacity horizontally. The way we route traffic means we can max out a region then spillover to the next one. And the way LiveBeats uses disks, each new region adds 10GB of song storage too.
Chris gets this stuff for free so he put way bigger CPUs and disks on the databases than they really need.
---Edit---
I did that wrong. It's ~$6.80 per region. Not ~$13.60 per region.
LiveBeats is hotlinking https://fly.io/ui/images/<region>.svg and Kurt updated a few of the US region images to be more specific vs blanket flag. The browser on the right is chrome, with the cached old image, and left is safari with the new one :)
I watched your presentation some years ago when you first demoed Phoenix LiveView. I think I and all my work buddies put our personal projects on hold waiting for a beta to come out so we could play with it! It's been fun to see this project mature so well.
Are the things happening with this little project here or with LiveBook what you had in mind when you made LiveView? Or have projects more manifested themselves as you've been able to prove out the capabilities of LiveView?
Anyway, thanks for making web development fun again!
Hey Chris. Great demo. It got me interested enough in Elixir to order a book. Does LiveView work well bi-directionally? For example, is there a demo of implementing Google Docs in it? Curious about the whole class of issues there vs. broadcasting changes from a single publisher -> many consumers.
Livebook, which is an elixir code notebook built with LiveView includes collaborative editing with presence, so it absolutely can be used in that domain. LiveView is built on phoenix channels, so it's all bidirectional communication. The client can send events from JavaScript. We use js hooks for the pings in LiveBeats for example:
Check out livebook.dev, it's pretty mindblowing! It's like Jupyter but for Elixir, and fully collaborative. It's about as close to Google Docs as I've seen.
Have been looking at the fly/Phoenix combo for a while
The one thing I can't wrap my head around is scaling, and the cost of scaling.
If this app magically exploded to 10,000 users at one time:
1. How do I scale with Fly.io? Can I autoscale, but somehow cap at a cost?
2. What parts of the stack would I have to pay attention to? Erlang/Elixir seem to handle a lot of the complication?
3. Are there (hidden?) costs that would concern me at fly.io with 10,000 simultaneous users? Or is there a clear way to estimate the costs at different points?
thank you - this looks very promising and (more importantly) fun!
This is true but you also need to account for memory usage.
With Live View it's kind of easy to shoot yourself in the foot and end up going out of memory very quickly unless you already know the pitfalls beforehand and know how to counter them all.
For example, if you were storing 1MB of data for each connection and you had 10,000 users suddenly your server is going to require 10gb of memory or your server is going to crash. If you went even more viral and had 100k users now you need 100gb of memory. If you scale things back to 100kb per connection that's still 10gb of memory for 100k users.
You can use a LV feature called temporary assigns to help counter this for certain things but this requires knowing about that beforehand and also coding around using that feature.
You need to constantly make decisions like, well I want access to the user-agent of the person on the site but if I save that on the socket then that alone might be around 1k of data. If I have 50,000 users on my site, just having access to the user-agent means your server is using ~50mb.
Basically once you start dealing with storing state for each connected user in its own process you have a whole category of things to think about vs developing a more traditional app that's stateless. That doesn't mean LV is bad, but it's a much different animal than having a stateless web app serving 100k requests on a tiny server and putting a CDN / caching layer in front of it.
"a stateless web app serving 100k requests on a tiny server and putting a CDN / caching layer in front of it"
That's a great question. For "live" stuff, it seems to me that Pheonix brings so much joy and simplicity, I'd happy pay for memory and hopefully scale in a sustainable way. This is all theoretical until we get a successful app, but it's good to see the future paths :)
It's very useful but I also think (and this is strongly a personal opinion) that too much live components break the core ethos of the web.
For example, personally I don't want everything changing on my screen in real-time, I want to consume content on my own terms. When I want the content to refresh I will reload the page. Otherwise it creates too much distractions with the screen bouncing around and content changing under your feet that's out of your control.
I think you can tastefully update areas of a page where it provides very high value but that's IMO the exception not the norm. Of course if you want to build another Discord or a live chat (or something like LiveBeats) then sure that's great.
This idea of using WebSockets for everything (even transitioning pages) amplifies the issue even more, but I think it's ideal for things like notifications and what LiveBeats does for keeping the audio player in sync across clients. That's why I really like Hotwire as an alternative to Live View, it uses stateless HTTP for everything and you can still do partial page updates for the person who rendered the page. Then you can optionally opt-into using WebSockets when broadcasting events to more than the person who rendered the page. It's also back-end agnostic. You get the best of both worlds, being able to use HTTP for just about everything and then sprinkle in WebSockets for the real-time broadcasted events. This lets you continue using a tiny server + CDN without worrying about memory being hold onto for each process and you can opt into event broadcast functionality as needed.
Some small sugesstions
When a file upload finish is not very clear that It finished, maybe you can change the color of the bar(or add an icon) to signal that it finished
also, I don't know if it was just me but the upload popup didn't work only the drag and drop one.
apart from that very cool project I also am an elixir developer but haven't had the chance to test liveview but it looks very good
Good suggestions. There is indeed a bug on chrome when clicking on the file link vs drag and drop. Something about dispatchEvent("click") vs .click(). Will fix in a bit!
The problem I have with a JS hook is that if you do a "socket |> push_event() |> push_redirect()" the hook is actually destroyed before writing the cookie.
Currently I'm using "Process.send_after(self())" to delay the redirect, it's not that ideal.
Man, how cool is this. I don't think people really understand just yet what fly.io is doing with Phoenix/Elixir and how it is changing deployment and scaling for multi-region, real-time apps. At this point, I'm just trying to figure out something worth building to take advantage of this technology!
A couple links have been mentioned already, but I'll add two more that got me really excited about Phoenix + Fly:
Very cool stuff, I haven’t properly looked into it since it was more a programmable proxy type produce a few years ago. But I’m planning on moving a smaller client’s backend off Heroku and onto fly since it would be about a third of the price to run and likely way faster but just as easy for a not-really-backend person like me.
I have been using LiveView for over a year now in production applications, and I must say...it has been a breath of fresh air when developing web applications. The amount of product that you can deliver per unit time is unmatchable (in my opinion of course). The ceiling for what you can accomplish with a single tech stack (Elixir in this case) has definitely been lifted considerably.
Demo applications such as this show exactly what is possible in this tech stack and should make you question whether you need to make that leap to an SPA. At some point you will possibly need to lean on an SPA tool like Vue or React, but I think that point is now further away with tools like LiveView (Elixir), Hotwire (Ruby), and Livewire (PHP).
This is great! Thank you for building a more complete reference app.
I went to visit some friends before Christmas and one night we used a website to play poker at a bar without bringing betting chips to the bar (site gives you a unique URL for a room, people can join the room & choose a name, then lets you bet from your chip count & withdraw from the total pool if you win, & displays that info "live" to everyone, super simple & convenient!). The site was cool, but buggy as hell and laggy as hell and didn't really do what I thought it should do to make it easy to play poker, and I'm gonna build one for my friends and I to use that works the way I think it should. Phoenix w/ LiveView (especially running on fly) is the _perfect_ set of tools to use to build it, and this ref app will be really helpful for me. Appreciate it!
Oh, great, I'm glad to have the LiveBeats app source available to browse now! LiveView is so interesting, but also so different from what I'm used to, that I often find myself feeling like a novice again wondering where to put files and how things are supposed to work. I've been using LiveBook as a resource, but it's kind of a crazy app that might not be reflective of normal use.
With esbuild and tailwind as easy to install hex libraries, and phoenix_live_view 0.17's new JS module, you can get pretty far without having to get into npm at all! And of course, if you need to use, e.g., react, you can always start using it and the full npm ecosystem like the "bad old days", but it's nice to not have to reach for it immediately.
edit: Having just now watched the video, I'm pretty blown away! Very cool, and very impressive that you can do this without a full-on SPA.
Chris McCord, who built this app (and author of Phoenix) talked about it on the Thinking Elixir podcast. Excited to learn that many of the learnings that he got when building this app will make its way into Phoenix LiveView.
If I were tasked with building an app with a similar feature set in another language or runtime Id have to bring in a whole set of technologies and infrastructure that would make it challenging. The killer feature of Elixir (and Phoenix/LiveView) is not just that you can do all this in the same app writing backend code, its that the scalabilty characteristics of the runtime mean that you can push it really far once you are live.
Im excited to read through some of the codebase as a good example of a LiveView app.
Love the effort fly.io is putting into supporting Phoenix. Reminds me of the early Heroku days when they were focused on making Rails as easy to deploy as possible. Betting on Phoenix is definitely the right call.
It's great for us, because Elixir and Phoenix do such a good job of exercising all the features of the platform. But just to be clear, there's nothing really Elixir-specific about Fly.io! You can run pretty much anything here.
Before LiveView came around, I didn't realise how much I hated building a SPA for very little dynamic interaction in the UI. One can of course sprinkle jQuery/Web Components and get stuff done, but for a server rendered app, LiveView has just enough magic to make sense of it as a server rendered component.
And the blog posts that the Fly team puts out on Elixir/Phoenix is just awesome. All that remains is just finding a project to try it out!
Coincidentally I also released recently a LiveView side project (that got zero traction on Show HN ;) that involves uploading audio files.
People are often afraid about the latency but I must say although visitors from all over the world used it I got no feedback about any lag.
I'm looking into their code how the flash is displayed as a toast notification that auto close after a while, as I kind of couldn't think of a simple solution to do that.
In my previous position at a fintech, I built out our customer support toolkit in LiveView, and it worked extremely well. It's not as structured as some frameworks, so you need to spend some time deciding on your own internal architecture, but once I got going, I was very productive.
Am I the only one who is not impressed by the LiveView?
2 things that bother me:
1) It seems most of these walk-throughs omit the process of actually designing the application architecture ("structure") so copy-pasting what had already been well-thought over feels organic;
2) Once you're faced with a more complex (production mission critical) task, the automagic starts to fade and you're back to the good ol' business logic and ui programming.
I just built my first LiveView app in anger last month. I don't really what you mean, though.
If it helps, I built my app the same way I would have built a Rails app:
1. Create a migration and some files to map DB tables back to my app
2. Create views and wire them up to the database
The automagic was 80% of the automagic in Rails. LiveView isn't giving me automagic, exactly, it gives me a way to interact with the browser.
One reason I may not understand what you're saying is: I didn't design my application architecture. I started with a small part and just built the rest incrementally.
The reason they "omit" the process of designing the app architecture is that running `mix phx.new` does that for you. Or `mix phx.gen.live` for an existing Phoenix project. Coding a LiveView Phoenix project is identical to coding a non-LiveView Phoenix project, except the module that handles rendering your pages now has additional functionality out-of-the-box.
