[deleted]
Phoenix 1.6, RC0 released
41–50 of 62 posts
Re: Phoenix 1.6, RC0 released
#42Phoenix creator here – I'm happy to answer any questions about elixir, phoenix, or this release!
Hey Chris! Is there a LiveView future where one can forego javascript frameworks altogether in creating higher-fidelity UIs?
I rewrote a large Rails+React+GraphQL with LiveView. LiveView replaced most of React. I still use React for rich text editors and complex browser based UI. LiveView plays well with this. I am happy not using GraphQL at all. It also consolidated all MVC code in one place. Phoenix made a few other things possible: in place chat, live updates (via websockets. No more polling).
Re: Phoenix 1.6, RC0 released
#43Phoenix creator here – I'm happy to answer any questions about elixir, phoenix, or this release!
Hi Chris Excited to see in this thread you joining fly.io Can talk about what (if) any plans exist to make deploying Phoenix apps at fly easier. Said another way, I’d love to click a button to deploy my app to be (a) globally distributed, (b) managed global database, (c) managed operating systems, (d) managed dns. Basically heroku for Phoenix (and more)
Yes! What you're describing is important, and roughly matches what we want for all apps. Managing apps + databases across multiple regions should be as simple as `fly region add syd`. This takes like 5 steps right now, it should take one.
We're also improving the Phoenix deploy process. I don't like it when people have to see Dockerfiles. Modern app deployment needs frameworks and infrastructure to work together. Our Elixir deployment doc (https://fly.io/docs/getting-started/elixir/) will someday be replaced with, hopefully, "mix phx.deploy".
Re: Phoenix 1.6, RC0 released
#44Earlier quoted context omitted.
Ruby companies like AirBNB, Stripe ended up edging out their competitors using the relatively glacial Java or C++ frameworks. We will need to see a new generation of Phoenix winners before Elixir is taken seriously. It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.
I am really confused by this comment. "Companies leveraging a quick to develop in, batteries included framework, with really poor performance, beat out companies using highly performant but less quick to develop in languages/frameworks, is reason why I'm suspect about a quick to develop in, batteries included framework that also prioritizes real time communication, with quite solid performance, and really predictable…
Guessing a significant chunk is due to talent base.
Re: Phoenix 1.6, RC0 released
#45Earlier quoted context omitted.
We're already there. We have huge companies using elixir and phoenix, with phoenix powering the web platform for the majority of them. Several great case studies exist on elixir-lang.org if you're interested, ie: Pepsi: https://elixir-lang.org/blog/2021/04/02/marketing-and-sales-... Heroku: https://elixir-lang.org/blog/2020/09/24/paas-with-elixir-at-... Change.org https://elixir-lang.org/blog/2020/10/27/delivering-so…
What's the other 15% of your time? :)
Everyone at Fly.io spends 15% of their time listening to me ask for blog posts.
Re: Phoenix 1.6, RC0 released
#46Earlier quoted context omitted.
That's really the goal, and for a large class of applications we are already there. Higher-fidelity UIs is pretty vague and there is absolutely a limit to where you necessarily need a bunch of code running on the client. Google maps & docs? Millions of lines of JS is inescapable, but dashboards, feeds, chats? LiveView excels here. We don't yet know where the limit is, but if you look at Livebook, we have a collaborat…
Have you done any comprehensive profiling of Livebook? It would be really interesting to see how it runs on low end or average cloud hosting providers under load. I'd love to see how many thousands of concurrent users could be interactively using and collaborating on a Livebook that's running on something like a $15 / month server. You could show off the memory, CPU usage and the latency of responses with varied amou…
We have a multi-region Liveview demo here: https://liveview-counter.fly.dev/
The total cost to run this is on Fly.io is $38/mo (~$2/mo per region). We've seen as many as 10k concurrent users pushing 30k "clicks" per second. People are fond of writing JavaScript in their browser console to simulate very fast clicks, so it turned into a funny stress test.
My browser slowed down, the Elixir processes never did.
Re: Phoenix 1.6, RC0 released
#47Earlier quoted context omitted.
Ruby companies like AirBNB, Stripe ended up edging out their competitors using the relatively glacial Java or C++ frameworks. We will need to see a new generation of Phoenix winners before Elixir is taken seriously. It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.
Just a small nit-pick here. If we're talking REST/graphql stateless APIs, sure the scalability gains may be a harder sell vs throwing hardware at the problem, but the value-add depends on what's being built. I built Phoenix first and foremost for real-time, stateful web applications. So anything that requires websockets, frequent updates, PubSub, presence, etc, you will be extremely hard to match what our stack provi…
I am an Elixir evangelist, to be clear, but it's one thing to have believers and another to change the world. I think you are right that Phoenix will eventually win the day in regards to real-time, stateful Web applications. "Traditional" REST APIs may be a harder sell, and perhaps Elixir doesn't need to eat the entire Web to considered successful. There are still many Java developers at work after all.
I am flattered to be critiqued by you!
Re: Phoenix 1.6, RC0 released
#48Earlier quoted context omitted.
I am really confused by this comment. "Companies leveraging a quick to develop in, batteries included framework, with really poor performance, beat out companies using highly performant but less quick to develop in languages/frameworks, is reason why I'm suspect about a quick to develop in, batteries included framework that also prioritizes real time communication, with quite solid performance, and really predictable…
Guessing a significant chunk is due to talent base.
The typical reaction to Elixir on my resume is still "we have a crazy Elixir person on our team too!"
Re: Phoenix 1.6, RC0 released
#49Earlier quoted context omitted.
Ruby companies like AirBNB, Stripe ended up edging out their competitors using the relatively glacial Java or C++ frameworks. We will need to see a new generation of Phoenix winners before Elixir is taken seriously. It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.
Sorry but i can't help myself, "marginal"? Bleacher Report replaced 150 Ruby servers with 8 running Elixir.
Technically "marginal" refers to the gains made by an incremental improvement, in this case the adoption of Phoenix over Rails, and not the use of Phoenix over nothing at all. So we still refer to the gains from Phoenix as marginal, even though they are substantial in many cases.
Re: Phoenix 1.6, RC0 released
#50Earlier quoted context omitted.
Have you done any comprehensive profiling of Livebook? It would be really interesting to see how it runs on low end or average cloud hosting providers under load. I'd love to see how many thousands of concurrent users could be interactively using and collaborating on a Livebook that's running on something like a $15 / month server. You could show off the memory, CPU usage and the latency of responses with varied amou…
We have a multi-region Liveview demo here: https://liveview-counter.fly.dev/ The total cost to run this is on Fly.io is $38/mo (~$2/mo per region). We've seen as many as 10k concurrent users pushing 30k "clicks" per second. People are fond of writing JavaScript in their browser console to simulate very fast clicks, so it turned into a funny stress test. My browser slowed down, the Elixir processes never did.
Thanks, I remember seeing that one a few months ago.
I hope this doesn't come off too harshly but that demo feels like it's meant to showcase high requests per second, not be a representation of how a real application would perform. It's broadcasting a counter over a websocket connection. It feels very similar to the old 2 million websocket connection demo. In other words I can't use your demo to make a meaningful conclusion on how LV would perform in my app. Also according to dev tools your demo page takes 300ms for me to load it from NY but I get 10-15ms response times on many other sites in the north east region of the US. A 300ms page response is usually what I would get hitting a server in Australia. The initial page load feels very delayed to load, although the counter increment was lightning fast.
I like the idea of using Livebook as a test case because it's an actual application, it's something relatable to what you might build instead of something that feels like it was created in a vacuum to promote high numbers. Sort of like how you could benchmark nginx with a hello world response. It's cool to see the high numbers but it doesn't help folks understand how things would work in a real app.
Having a breakdown of the average and p95/p99 response times at 100, 500, 1000, 2000, 10000, 25000 and 100000 connections all sending messages at varying rates along with seeing CPU and memory usage on a certain tier of VPS would be amazingly useful. You could take that data and factor in how your app might deal with similar conditions.