Phoenix 1.6, RC0 released
phoenixframework.org
phoenixframework.org
What has me really excited was that I was looking at Fly.io to create a global mesh of servers for a liveview app so people can connect to whatever is closest, and guess who just joined Fly.io's team? Chris! I think this is going to be a very productive stack that will get you far far ahead of the competition once you learn it's patterns. Complicated features become trivial to implement with great UX to your customers.
[1] https://pragprog.com/titles/liveview/programming-phoenix-liv...
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-social-ch...
And of course Bleacher Report, which has been on Phoenix since 2014, well before 1.0.
On the sponsorship side, DockYard invested in my work for the last six years where I spent the majority of the year working on oss, and I've just joined https://fly.io where I'll spend 85% of my time working on Phoenix and related libraries. So we are well covered on the corporate sponsorship side. We also have Michael Crumm on the Phoenix team who works at Cargo Sense, where they support a portion of his time working on LiveView. Of course it would be great for other large companies leveraging value out of our work to give back, but we're well established on the sponsorship side :)
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 flattered to be critiqued by you!
That said, I think one important asset of Elixir (in my view) is not the raw performance, but the overall "total cost of ownership" (including maintenance work, and software is a lot of maintenance).
Being able to simplify architectures is something that is nicely done with Elixir, actually.
If a part of an app needs to play a "proxy" role (like here https://github.com/etalab/transport-site/tree/master/apps/un...), then I just add a component to the app, and I can keep the incoming connections under hand, all while issuing external queries etc.
If there is a need to do some rich interactive dashboards, I can use LiveView.
If I need to demonstrate some simple stuff, I can use "Mix.install" to create one-off scripts.
If I need to do more data-science, I can tap into LiveBook, VegaLite etc.
All this with a small team or as a solo developer, is quite great, much more than raw performance, in my eyes.
I mean...the argument about "the hassle of training and hiring in a whole new language" applied just as much when Rails took off. While Ruby had been around since the mid-90s, it was definitely an esoteric language for the decade or so prior to Rails.
Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists, and now benefits from having a lot of people who know it. But being able to reduce hardware costs by 90% while giving up little of the flexibility, and bundling in a lot of real time features can be quite compelling; we'll just have to see.
Usually I reply something like "You know Discord?".
I hope it does one day, but not to replace Rails.
It's a really hard sell because I think eventually we're all going to converge to the same real-time, low server cost setups. At this point it becomes how fast is it to build my app and what is it like to maintain it.
Rails 7 is coming out with a neat feature that will build in encrypted fields at the DB level for Active Record with a way to situationally decrypt them in case you need to debug something specific in production. Then, any time a developer accesses those decrypted fields an audit log will be generated. It'll also audit log any Rails console access[0].
These are really big things to not have to deal with. Will Ecto ever get this sort of thing? Maybe, maybe not. But I think the bar is raising overall where if things like this aren't added in the future you have a less chance of being adopted by the masses because not everyone has the resources to spend months developing stuff like this in house.
Did we exist without it in the past? Absolutely, but I think we need to be comfortable with adjusting our expectations that higher standards are coming as there's more framework competition and languages coming out. LiveView is a great example of this, only a few months after it was announced a bunch of popular frameworks released their take on it that play to the strengths of that framework of choice. Now there's kind of an expectation that it shouldn't take an SPA to develop a mostly document driven application with a nice user experience.
Personally I would want features that help me build apps faster and more securely while having to pay $40 / month to host my app instead of a framework that doesn't have these features but it costs me $20 / month to host it instead. Sure if you take this to completion and say but if you have 10,000 servers running it's double the cost but for most applications you can host a pretty popular and profitable app for less than $100 / month with any modern tech stack without making performance compromises (ie. <= 100ms page responses for the p95).
[0]: https://twitter.com/gregnavis/status/1431149713470930944
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 amounts of load.
IMO that would be a very useful thing to look at and could push folks into using Phoenix more so than they already do because having a bunch of tiny websocket connections open (the old 2 million connection benchmark) isn't really relatable to a typical web application that you mentioned people are building like dashboards, feeds and other things. Livebook is a concrete application with features that might appear in many other web apps.
Something like that would be worthy of a demo video at a talk or even your YouTube channel if you were ever fishing around for what people in the community might want to see.
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.
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.
That 300ms load time is actually because it queries Australia when you first load the page. Each region keeps its own counter and it grabs the current value from all of them at load time. It's probably worth optimizing that. :)
I gotta say I am a huge fan and liveview is a game changer in many ways. Great work with Phoenix.
Building a LiveView app out of components, and sending messages back to the server and re-rendering, feels a lot like building a react app! This is a real intuitive and easy to use flow. (I remember when react came on the scene and its "one way dataflow" was so groundbreaking to me.) That said, a react app where every state update is a round-trip to the server is probably not ideal. I know that there's the PETAL stack for this sort of thing. I guess my question is: with so much functionality available in pure Elixir/LiveView, what's your decision process when embarking on a new app about when to try to get by with just that, vs bringing in react or a full SPA frontend and simple API backend?
Separate question: what's the best dev environment and tooling for Elixir/Phoenix/LiveView these days? My VSCode setup is pretty great for React, particularly with format-on-save nesting and indenting my JSX properly. I miss that when working in (h)eex templates.
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)
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".
A few follow-ups:
a. Will pre-prod environments be included in those plans you outlined above (eg Dev, Test, Stage)
b. Any plans to make it easier on Developers to have local/remote environments for development? (Eg GitHub Codespaces)
c. Do customers typically also use 3rd party security offerings like Cloudflare in conjunction with fly.io - or do you see more customer just using fly.io without any additional protection?
d. One thing that Cloudflare Workers does that’s interesting is that it deploys your webasm code to every pop/region they have & them orchestrate the communication between the regions to keep data consistent. Is similar functionality on roadmap?
e. Any rough order of magnitude on timing for what you described?
1. Self service snapshots/restores
2. Get it out of beta
3. Single command database and apps management
My time estimates are always wrong, but that feels like 3 months.
The really slick Phoenix release process is going to happen in parallel but it's hard to say when.
We are a SAAS for managing sports teams and clubs https://www.sportmember.com and our current stack is Ruby on Rails, GraphQL and React Native for our app.
When deciding to develop this new feature we narrowed it down to these two options:
1) Rails/GraphQL/React
2) Elixir and LiveView
What's great about Elixir and LiveView is
1) The whole GraphQL API layer was not necessary to build. The best API is no API ;-)
2) No need to duplicate code like for example for validation on the frontend and the backend
3) Developing the whole feature using just Elixir instead of having to switch between TypeScript and Ruby
This means that we have been able to develop this feature in about 2/3 of the time which is pretty nice!
In one of the HEEx examples in this post it mentions components and uses a weather component as an example with: <MyApp.Weather.city name="Kraków"/>
I'm curious, what would the syntax look like if you wanted to create something like a card component that has an optional header, body and footer where you would want your arguments to be blocks of arbitrary HTML that you pass in and not a single string variable?
Basically a way to do something like this (a more simplified version since I don't know what the API would be):
<Foo name="bar">
<p>Custom stuff!</p>
</Foo>
I think this might be called slots in other frameworks, but they seem essential to be able to create re-usable components unless HEEx has an undocumented way to do this? It looks like Surface has this at https://surface-ui.org/slots.
What are the benefits of using HEEx over Surface? I know they're working together and in the end will share similar functionality and maybe Surface will use HEEx under the hood but as an end user building web applications with Phoenix is there a single case where I would use HEEx instead of Surface? If not, why isn't Surface part of core Phoenix or not heavily pushed as what to use for a templating solution in the docs?
But in a re-usable card component you might decide to have a title, body and footer block where the footer is optional and perhaps falls back with a default value if it's undefined. Slots with Surface handle this use case based on their docs. I think there's a lot of component use cases where you'd want the idea of having multiple blocks.
The docs you linked don't cover if HEEx supports anything like that, or being able to use multiple named blocks in 1 component. I tried to read the source but render_block is a macro and I couldn't proceed to trace it.
I chose to stick to base LiveView in my apps because it works fine (slots are nice but not essential), and I want to avoid too much API churn and learning curve for other devs on the same team. The best Surface features are being gradually refined and merged into LV. HEEx is a great example of that.
Crap. I literally just built this out for a personal Phoenix project two weeks ago (using Bamboo instead of Swoosh because I could get it working for SES more easily). Guess I'll see about adopting the official and probably far better solution. Since there are also published upgrade steps. CURSE YOU FOR BEING SO HELPFUL, PHOENIX DEVS!