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!

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.

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!

    //js
    Hooks.Ping = {
      mounted(){
        this.handleEvent("pong", () => {
          let rtt = Date.now() - this.nowMs
          this.el.innerText = `ping: ${rtt}ms`
          this.timer = setTimeout(() => this.ping(rtt), 1000)
        })
        this.ping(null)
      },
      destroyed(){ clearTimeout(this.timer) },
      ping(rtt){
        this.nowMs = Date.now()
        this.pushEvent("ping", {rtt: rtt})
      }
    }

    //liveview
    defp handle_event("ping", %{"rtt" => rtt}, socket) do
      {:halt,
       socket
       |> rate_limited_ping_broadcast(socket.assigns.current_user, rtt)
       |> push_event("pong", %{})}
    end

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!

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

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.

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