I am looking at the possibility of using LiveView in my application. Just wanted to understand the impact of LiveView (in terms of cost) for adopting in a cloud environment. In general the cloud vendors (i am looking at AWS) charge the network IO based on number of network calls and the amount of data transferred. In such a case, where Liveview constantly performs network IO from server to client, I am trying to understand if my monthly bill grows multiple folds.
While I cannot directly address your question I can point to this tweet, that I came across this morning:
# AWS APIGateway & # lambda service that was costing us about $16000 / month in # elixir . Its running in 3 nodes that cost us about $150 / month. 12 million requests / hour with sub-second latency, ~300GB of throughput / day.
This is only sort of accurate. Live view performs network IO when there are changes to be made, and it pushes only those changes.
More importantly though, network IO is routinely one of the absolute cheapest parts of your cloud infrastructure, at least if the majority of your traffic is HTML. If you’re moving terabytes of data, then yeah, it can start getting expensive, but you could multiply most people’s bandwidth by a factor of 10 and it still wouldn’t be an issue.
Thank you @Exadra37 for sharing the information. it was helpful for me. The tweet has information related to not only API gateway but also running elixir cluster in aws. i will try to find more information along the path. thanks for your time.
@benwilson512 i am currently planning on streaming HTML changes to client over phoenix channels.
Fully agree with @benwilson512 here. Rather than looking at egress charges of LiveView updates versus ‘traditional’ REST endpoints, I would compare if a LiveView solution needs more compute resources (VM) compared to a REST approach. From what I understood, LiveView can host quite some users concurrently.
So in the end, it’s certainly more about maintainability of the code for your team, instead of cloud costs.