4 ms·
Does anyone use Live Preview / Live Views in Phoenix, but in production with a B2C product? I'm a bit skeptical of Rails performance with the method the author
by shay_ker 6y ago
Does anyone use Live Preview / Live Views in Phoenix, but in production with a B2C product?
I'm a bit skeptical of Rails performance with the method the author details here, given that Ruby is much, much slower than Elixir.
I'm curious if even Elixir folks deploy Live Views in consumer-facing apps. But I can totally see it being used for admin interfaces or internal applications, for sure.
- vmsp 6y agoI wouldn't say "much slower" https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/hipe-ruby.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- strzibny 6y agoI believe both are used for customer facing applications. However, I am not sure about b2c at scale. You could argue that Hey.com is b2c. In this case, the main advantage is that scaling is stateless, so your application servers just have to be able to deal with more traffic. There is nothing more to it. As for Phoenix LiveView, it has both advantage and disadvantage of being stateful (something as using Action Cable). You now have to be scaling web sockets, but you save on authenticating the request (the request is lighter). Even if LiveView is stateful, it's done on the platform which is optimized exactly for this purpose. In both approaches, you also have to take into account that server latency might be a deal breaker for you.
- Sodman 6y agoSome anecdata as a hey.com user myself: It feels like they've optimized a lot for initial load of the main homepage (The "Imbox"). Obviously this is super important for an e-mail app... but once you start trying to load anything older than the most recent ~20 e-mails (Eg scrolling "The Feed"), then the load times can be horrifically slow (>10s, followed by a janky pop-in of HTML suddenly loaded). I'm not sure if this is caused by this technology in particular or if there's some kind of cache miss happening here, but coming from and comparing to gmail - which hey's makers like to dump on regularly - the performance is miserable. Sure, the number of transferred bytes is small and there's not a lot of JS to load - both of which I'm a big fan of, but the actual load time that I feel as a user is pretty bad for these AJAX calls. Overall I'm a fan of what they're trying to do with Hey.com, but this particular use case feels like a big UX miss to me.
- nickjj 6y ago> I'm a bit skeptical of Rails performance with the method the author details here The method used in the blog post is making an ajax request to the server and then displaying the results in a div. For comparison, GitHub is running Rails and when you type into its search box it's making an ajax request to the server and displaying the results in a div. Just wanted to bring that up here because this is different than what Live View does or what using Turbo Streams would do to broadcast changes over a websocket connection if you were using Rails. I don't know of anyone running a large scale app using Live View as a primary focus but I did chat with someone on my podcast about how they used Phoenix and Live View to build https://textdb.dev https://textdb.dev. That episode is at https://runninginproduction.com/podcast/68-textdb-is-a-simple-way-to-share-small-amounts-of-data https://runninginproduction.com/podcast/68-textdb-is-a-simpl.... TextDB trended here on HN a few months ago at https://news.ycombinator.com/item?id=23948234 https://news.ycombinator.com/item?id=23948234. It handled the HN front page load without issues, but it's also not doing a ton.