Fly.io is doing amazing things. I'm really impressed with their work. If any of the Fly.io people read this, my hat's off to you.
How we got to LiveView
131–140 of 293 posts
Re: How we got to LiveView
#132I will read your article more thoroughly because it does sound interesting, but I'm curious how well this server-side state works from a scalability/robustness point of view.
It being stateless is normally a feature, as it doesn't matter which server the request hits, we can elastically scale them up and down.
With a "session" being server-side statefull, you now have session affinity and are you persisting/hyrdating that session somewhere? Is it kept in memory and lost of the server goes down? How long does that session persist? Lots of questions...
Re: How we got to LiveView
#133Earlier quoted context omitted.
Hi Chris - this is superb, really pleased to see LiveView getting so much attention, and thanks for all your hard work. Can you talk a little about the current story with deployments and managing state across/during those? Obviously Erlang/OTP supports hot upgrades, but those are hard to design correctly and not supported by container/VM environments like Heroku and (I presume?) Fly.io.
If LiveView is backed by PubSub, then I think you can offload persistence to Redis.
LiveView in its standard configuration does not use Redis, it uses built-in Erlang distribution. But you can use Redis if you want to or if direct connections between nodes aren't possible.
Re: How we got to LiveView
#134Earlier quoted context omitted.
The sweet spots for me are: 1. It is much easier to trace things through the entire Phoenix stack than it is in Rails. It is also much easier to add things to the Phoenix stack using plugs. 2. Elixir is concurrent, whereas Ruby is not, so when performing long-running processes, you can just do them in Elixir/Phoenix without having to rely on workarounds like Sidekiq, Resque, RabbitMQ, etc. 3. Writing multi-threaded a…
Looking more at things like #2. Sidekiq isn't terrible though, and if you get big enough, you're going to want some more management than just spawning a BEAM process to do something. What have people settled on for that with Elixir/Erlang?
Sidekiq is great, but it is a thing you have to think about (in particular, how you're shuttling state from workers to a place where front-end can see it). The big win with Phoenix as I understand is not having to think about it at all: it has a natural expression in the language and the platform, and that expression is performant.
Re: How we got to LiveView
#135Earlier quoted context omitted.
Is microseconds correct? Even with a good connection in online games I’ve only seen ping latencies of 3ms or so, and a more common range on an average connection is 20ms-50ms.
Should be, though milage may vary, of course. I'm having trouble finding a better example but https://elixir-console-wye.herokuapp.com/ is made in LiveView. You can try it out and see what you get (I have no idea where it's deployed, it's a phoenixphrenzy.com winner and plenty more there to browse through). Its payloads are a bit larger than some typical responses I have in my personal apps and I'm seeing 1-2ms respo…
ms is milliseconds
Re: How we got to LiveView
#136Earlier quoted context omitted.
Almost every time I see a discussion about LiveView there’s someone complaining about the issue of latency/lag, and how it makes LiveView unsuitable for real-world applications. From what I understand, the issue is that every event that happens on the client (say, a click) has to make a roundtrip to the server before the UI can be updated. If latency is high, this can make for a poor user experience, the argument goe…
Lots of answers here including one from Chris McCord himself, but I'll offer my take based on my professional experience developing web apps (though I've never used Phoenix professionally): A large majority of businesses out there start off targeting one region/area/country. The latency from LiveView in this scenario is imperceptible (it's micro seconds). If these businesses are so lucky as to expand internationally,…
One light-microsecond is about 300 meters, this must be milliseconds.
Edit: Just saw that this was already pointed out. Apologies, didn’t mean to pile on.
Re: How we got to LiveView
#137Since I'm a persistence person and not a UI person, I am more interested in what is on the other side of the Phoenix/Elixir/BEAM VM server cluster: the database/persistence. I understand that currently apps mostly talk to PostgreSQL, like a Rails/Django app would? Then, if something modifies the data in the database not by using the Phoenix app, the Phoenix app would not find out until it loaded the values from the d…
What's the difference between "the data is in the server memory" and "no one has write access to postgres outside the application servers"?
Re: How we got to LiveView
#138Earlier quoted context omitted.
Should be, though milage may vary, of course. I'm having trouble finding a better example but https://elixir-console-wye.herokuapp.com/ is made in LiveView. You can try it out and see what you get (I have no idea where it's deployed, it's a phoenixphrenzy.com winner and plenty more there to browse through). Its payloads are a bit larger than some typical responses I have in my personal apps and I'm seeing 1-2ms respo…
ms is milliseconds
Yep, which is what I meant in my comment you're replying to (as per my statement that devtools only report to the 0.001). But as pointed out by jclem, I'm probably wrong about microsecond response times anyway. I'm very likely thinking about the MICROseconds I see in dev, which of course doesn't count :) But with the heroku link above, I am seeing as low as 1-3 MILLIseconds in Toronto, Canada.
Re: How we got to LiveView
#139We used Liveview in a production app but have sense re-written it all in favor of React. The biggest issue with LV was the fact that users with poor connection were experiencing a channel timeout causing the page to completely refresh. This was unacceptable UX, and there was nothing we could do about it. Really a shame, because I was enjoying liveview.
Re: How we got to LiveView
#140Earlier quoted context omitted.
Lots of answers here including one from Chris McCord himself, but I'll offer my take based on my professional experience developing web apps (though I've never used Phoenix professionally): A large majority of businesses out there start off targeting one region/area/country. The latency from LiveView in this scenario is imperceptible (it's micro seconds). If these businesses are so lucky as to expand internationally,…
One light-microsecond is about 300 meters, this must be milliseconds. Edit: Just saw that this was already pointed out. Apologies, didn’t mean to pile on.
I pointed out below that I actually DID mean microseconds but likely skewed by times I was seeing in dev. Hopefully it does not take away from my point that response times are still imperceptible when in roughly the same region (I'm seeing 1-3 milliseconds in the heroku-hosted LiveView app I linked below).