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