sodapopcan
One concern that comes up a lot is how LiveView stores and runs a lot of data server-side.
I’ve always seen this a good thing.
First off, I really appreciate sites/apps that are nice to my phone’s battery as well as my laptop’s memory. Even users who don’t actively care about this passively care without realizing it. Next, if you have intellectual property to protect then it’s obviously better to have as much of it server-side as possible. I once saw some Hack News folk carrying on about how they hate people who reverse engineer obfuscated JS. “Well stop putting sensitive stuff in client-side JS, you ding dongs” was my thought, but I digress*
As far as costs go, If I’m running a dedicated server anyway then I’ve already paid for my memory so go ahead and max it out. If I need to scale up or out, then I have more users who are theoretically offsetting the extra costs exponentially.
Of course, I don’t have actual experience with this. I did briefly work for a company that ran a LiveView widget in production, but I never dug into the financials with them (our servers seemed fine, though!)
So my very open-ended question to small-to-medium business folk running LiveView: what’s your experience been like with this?
Thanks to any willing to share!
(*) I do realize that there are certain classes of web applications that must be heavily client-side. I’m just being cheeky, ok?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Hisako1337
It’s incredibly cheap given you have „ordinary“ liveviews and don’t do extremely challenging computation in your event handlers.
A single (multicore, few gigs RAM) instance can be able to run even a large business. Without breaking a sweat. Even if you do encounter exceptionally high load, the very nature of the beam will prioritize short functions (like user interactions, page loads, …) over heavy background jobs, so the overall system remains snappy until severe overloaded.
(Background: did. this in the past with bigger companies and Black Friday was boring for us technicians!)
tj0
Small app between 150-200 concurrent connections which uses about 3.5 GB of ram over 6 instances.