chrismccord

6 ms·

31.
by chrismccord 2y ago
Thanks! This kind of thing was lacking for some time, and with the HEEx engine + function components released a couple years ago, we laid the groundwork for extensible component libs, and the community has put out some great options. We lis
32.
by chrismccord 2y ago
Will keep this in mind! My ElixirConfEU keynote just used limit/offset pagination, but shows how easy it is to do bidirectional infinite pagination. Streams allows you to keep a virtualized infinite list in the DOM without keeping the
33.
by chrismccord 2y ago
I need to polish the code, but here's more advanced optimistic UI example added to an existing demo app (TodoTrek). It uses recent LiveView features that allows any client code to hook into the full optimistic UI/server sync prim
34.
by chrismccord 2y ago
Thanks! Love to hear it! Note that LiveView also fully works on the LongPoll transport (which is enabled by default), and we have automatic fallback to longpoll support if websocket fails for whatever reason. So even in the case of obscure
35.
by chrismccord 2y ago
Phoenix creator here – excited to finally have shipped this! Happy to answer any elixir/phoenix/liveview questions. In case folks missed it, buried in the blog post is a new installer that lets folks try out elixir/phoenix in
36.
by chrismccord 2y ago
Author of the post (and Phoenix/LiveView/FLAME) here! I'm happy to answer any questions about how this works. The distributed features of the Erlang VM makes this kind of application outrageously easy to implement. And with F
37.
by chrismccord 3y ago
If you're talking about inflight work that is running on the runner, there is a Terminator process on the runner that will see the parent go away, then block on application shutdown for the configured `:shutdown_timeout` as long as act
38.
by chrismccord 3y ago
> Or are Flame pools strictly children of each individual parent? Confirm. Each parent node runs its own pool. There is no global coordination by design. > Does it make a difference in pricing or anything else to run on hot workers in
39.
by chrismccord 3y ago
They handle scaling at only highest level, similar to spinning up more dynos/workers/webservers like I talk about in the intro. FLAME is about elastically scaling individual hot operations of your app code. App Engine and such are
40.
by chrismccord 3y ago
I talk about FLAME outside elixir in one one of the sections in the blog. The tldr; is it's a generally applicable pattern for languages with a reasonable concurrency model. You likely won't get all the ergonomics that we get for
41.
by chrismccord 3y ago
Good question. The pools themselves in your app will be per usecase, and you can reference the named pool you are a part of inside the runner, ie by looking in system env passed as pool options. That said, we should probably just encode the
42.
by chrismccord 3y ago
Yes, more sophisticated pool growth options is something I want longer term. We can also provide knobs that will let you drive the pool growth logic yourself if needed.
43.
by chrismccord 3y ago
This is actually a feature. If you watch the screencast, I talk about Elixir supervision trees and how all Elixir programs carefully specify the order their services stop and stop in. So if your flame functions need DB access, you start you
44.
by chrismccord 3y ago
The FLAME.Pool discussed later in the post addresses this. Runners are pooled and remain configurable hot for whatever time you want before idling down. Under load you are rarely paying the cold start time because the pool is already hot. W
45.
by chrismccord 3y ago
Ingest looks like an awesome service! I talk about job processors/durability/retries in the post. For Elixir specifically for durability, retries, and workflows we reach for Oban, which we'd continue to do here. The Oban job
46.
by chrismccord 3y ago
Bring-your-own-container is certainly better than proprietary js runtimes, but as you said it carries every other negative I talk about in the post. You get to run your language of choice, but you're still doing all the nonsense. And y
47.
by chrismccord 3y ago
Thanks! I try to address this thought in the opening. The issue with this approach is you are scaling at the wrong level of operation. You're scaling your entire app, ie webserver, in order to service specific hot operations. Instead w
48.
by chrismccord 3y ago
Thanks for the thoughts – hopefully I can make this more clear: > * Pretending that starting a fly machine doesn't cost the same as triggering via s3 seems disingenuous. You're going to be paying for resources wherever you dec
49.
by chrismccord 3y ago
It starts your whole app, including the whole supervision tree, but you can turn on/off services based on whatever logic you want. I talk a bit about this in the screencast. For example, no need to start the phoenix endpoint (webserver
50.
by chrismccord 3y ago
Author here. I’m excited to get this out and happy to answer any questions. Hopefully I sufficiently nerd sniped some folks to implement the FLAME pattern in js , go, and other langs :)
51.
by chrismccord 4y ago
While we use JS and websockets, even with js disabled or curling the page will send all the HTML. So the initial render is strictly a regular html page with all your expected content.
52.
by chrismccord 4y ago
Phoenix is actually quite small if you look at the source and patterns. It would be interesting to compare to other frameworks. We get a lot for free from the platform, so even if you include Phoenix pubsub the feature set for size of the f
53.
by chrismccord 4y ago
Creator of Phoenix here. I was delightfully surprised to see Phoenix as most loved on the survey since I forgot SO survey was a thing this year. So we can rule out some coordinated voting effort. Truthfully, while we’re still a smaller comm
54.
by chrismccord 4y ago
> Write interactive & collaborative code notebooks in Elixir Think Jupyter Notebooks (if you're familiar with the python world), but collaborative and for Elixir.
55.
by chrismccord 4y ago
To tame the snark from the quoted comment, I think it's worth breaking down. Current SPA trends are about deploying your app separate from the backend, often CDN-style close to the user (because speed of light matters). Most apps at sc
56.
by chrismccord 4y ago
Yeah we expose interfaces to ignore blocking on the LSN, but the way this works is by proxying the Ecto Repo interface with our own Repo. So you could call your underlying Repo directly if you wanted to perform a write without blocking on t
57.
by chrismccord 4y ago
One of the points about read replicas and read-your-own-writes is correct to call out, but on the Elixir side we have an answer to that: > It seems like this would add a whole new class of bugs, like “I just submitted a form to change a
58.
by chrismccord 4y ago
As the creator of Phoenix, I've never written an Erlang program fwiw. That said, I frequent the Erlang docs and most seasoned Elixir developers will do the same because the standard library is a wealth of features, and the documentatio
59.
by chrismccord 4y ago
This is really exciting to see! LiveView / Livebook + NX / Axon is a neat way empower folks in the ML space. Everything is way more approachable if you can easily wire up your models and visualize and play with them in a UI.
60.
by chrismccord 5y ago
The biggest difference (at least for Phoenix LiveView) is having a stateful backend represent the UI and we do away entirely with HTTP APIs/serializers/resolvers. So you get both interaction and push updates from the server at any

More ›