Phoenix Dev Blog – Streams

https://fly.io/phoenix-files/phoenix-dev-blog-streams/

by losvedir • 3 years ago

254 88 3 years ago

fly.io

revskill5• 3 years ago

I'm not sure what's exactly problems which liveview tech solves.

In real world applications, it's always "polling", because you're not sure when server finished your request.

Or liveview is for toy application ?

Note: You seems mislead the point here, to build interactive apps, of course you can just use websockets. What's more liveview solve ? I guess liveview = html + websocket.

Touche• 3 years ago

Huh? LiveView is for interactive apps. It's not finished until the user leaves the page. It's not polling.

Cyph0n• 3 years ago

It is not polling - it relies on Websockets.

realusername5• 3 years ago

In realworld apps you have a lot of "dynamic" areas which are just "click there, ask the server for the changes and reflect that on the web page", this is where liveview is great.

Another case are dynamic elements based on external factors not based on user actions (like for example the message counter on a social network), those are pretty annoying without liveview because you need to build a whole frontend event system just to change a number.

revskill5• 3 years ago

Are you sure Facebook or Twitter is using liveview for their social feed ?

ing33k• 3 years ago

check out https://zcashblockexplorer.com/ , it uses LiveView.

https://zcashblockexplorer.com/mempool

sb82443• 3 years ago

"What problem does React solve? You can just use HTML and jQuery to build websites."

To me LiveView is not about interactive apps so much as it is a way to build applications, period. You can build in a way that may bring you more joy, performance, and dev speed than you could otherwise.

Interactivity is a side effect, and it's a great one. But I wouldn't recommend LiveView if someone only wanted interactivity. I'd recommend LiveView if someone wants a different way to build than the React+API status quo.

revskill5• 3 years ago

React solves the composition of components, which lacks in HTML technologies.

What about liveview ? That's the question. They're different.

jjtheblunt• 3 years ago

liveview is similar, in spirit, to how X11 apps had a client side library and a server side library (ultimately Xlib on one end), and were connected by a socket (bidirectional) over which minimal-ish data would fly back and forth to keep the client side displaying what the server wanted, and the server aware of events from the client side.

liveview is also using a socket, whose existence springs to life via the "websockets" modernization where the client is a browser. and the traffic bidirectional over the socket again keeps the server side library aware of events, and the browser-side aware of UI alterations to display.

Existenceblinks2• 3 years ago

Not all websockets are equal. If you've ever tried PhoenixChannel + PubSub .. you will know why. Also LiveView + Presence built on top of that with all niceties. And if you have more than 1 node, these also work in distributed fashion.

nelsonic2• 3 years ago

Streams in LiveView are a game-changer for long-lived data-heavy apps like news feeds/readers or analytics dashboards that update steadily over time. We've been using LiveView in production for the last couple of years and it keeps getting better. Great post and continued updates from Chris & community. :-)

lucasyvas• 3 years ago

LiveView is a great pattern, but it's worth noting that it is not universally useful or better. If latency of UI change is more important than the latency of data update itself, doing the UI update on the client will always make more sense and the data can slide in shortly after.

There is no silver bullet, and sometimes doing a UI update on the client is still a better UX.

I can foresee a future where everyone goes down the LiveView rabbit hole, only to improperly blame it for causing too much UI update latency in some cases.

When it all goes well, it's very clean. If you can't make sure the server is evenly loaded amongst all your clients and close to them, it will probably feel quite poor in comparison to some client side update code.

brightball2• 3 years ago

That’s definitely true, but in my experience the data update is the 80% use case.

ch4s32• 3 years ago

I think you’re directionally correct, but LiveView has a JS api that can fire off front end events. You can tie in React, Vue, Alpine, or whatever if you want.

realusername5• 3 years ago

If the UI change requires no network calls, it's better to use a JS hook or/and Alpine in my opinion.

yencabulator• 3 years ago

The parent is talking about a scenario where the network action may take longer, and you want the UI to remain responsive. Consider a save button that goes through state transitions dirty->saving->saved.

POiNTx2• 3 years ago

On this note I've been developing LiveSvelte these last 2 weeks. It's not finished yet but it's promosing. Takes a way a lot of the UI update issues with LiveView as you can have local state very easily while still maintaining reactivity with LiveView wherever you need it.

LiveSvelte: https://github.com/woutdp/live_svelte/

bongobingo16• 3 years ago

May be of interest to you: https://www.youtube.com/watch?v=I4vVxtrow-E

sph4• 3 years ago

On one hand I've been waiting for LiveView to stabilize and get to its 1.0, on the other hand every release is more awesome than the previous one, and I'm speaking as someone that has been using it since its first public release.

Thanks Chris and all the contributors for your hard work.

ch4s32• 3 years ago

It’s reasonably stable and when there are bumps, it’s usually easy to deal with them in my experience. We’re all in for most new applications where I work.

rhgraysonii• 3 years ago

I have been a Live View skeptic for years. Recently in 30 days we were able to build an MVP of a complex tool (ingesting ML models, time series + regular databases, complex FE interactions, live notifications, more) that blew the minds of the higher ups and got a ton of buy in building using it from the org as a whole after the success. There were a few bumps, but as a whole, it’s largely been a _delightful_ experience and I found myself pleasantly surprised as a whole.

I would have little fear diving in at this point. We are not a small org and it was a big bet that has paid off.

cambaceres• 3 years ago

I have been developing with React/Node for 7+ years now and I have started to look for something else. Perhaps this would be something to try. I'm specialized in developing web portals/backoffice systems, would this be suitable for this? What limitations are there?

bongobingo16• 3 years ago

RTT is the big limiting factor.

It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX.

This isn't hard, it has support for interop with plain JS or existing libraries and a somewhat limited built in system for basic show/hide/set/remove attributes (somehow lacks a "toggle_class" and "toggle_attribute" function though so you can write those yourself...). You can dispatch any custom JS event from it to cover .. anything you need.

If you're exclusively deploying to on-site/one-site/geographically-constrained systems, then you actually skip that issue...

You also have to re-think about how write code as Elixir is immutable, though I see that as a bonus.

Phoenix (and by extension LiveView) are actually a lot smaller than you might think coming from Rails or the like, mostly leveraging existing tools.

Elixir/Erlang/BEAM make building systems incredibly pleasurable. It ships with many tools to make and connect complicated things together, in a reliable way. Depending on what you make you may find it very liberating after working with Node.

emerongi2• 3 years ago

It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX.

Most JS UIs behave like this: open a list view, watch a spinner until data is fetched from the server. There is practically no difference between that and showing a spinner first and then the list.

marcus_cemes2• 3 years ago

I think this is a great use case. From my experience, having everything in one language is a huge plus. You can pull data from the database and just inject it into the view. The closest I've gotten to this in the JS/TS world is a Prisma + tRPC + SvelteKit for E2E type safety, but there's a huge cost in complexity and language server performance and some extra boilerplate.

The main limitation is likely offline apps, LiveView requires a persistent connect to the server. I doubt this is something you'll encounter for your use case.

stoicjumbotron• 3 years ago

I'm planning on adding tRPC to the Prisma + Nest + Next stack so can you elaborate on "language server performance"?

floodfx• 3 years ago

LiveViewJS[1] might be of interest. Same protocol as Phoenix LiveView with a JS/TS server implementation.

I was looking for something else after years in React ecosystem and came across Phoenix LiveView but I wanted to write in Typescript.

(Note: Am author)

[1] https://LiveViewJS.com

theptip• 3 years ago

For back-office stuff, these days you can be really productive with Django/HTMX or Hotwire, both in the same broad paradigm as Phoenix LiveView.

lilactown• 3 years ago

website seems down?

faraaz98• 3 years ago

it does

the-alchemist• 3 years ago

HTTP ERROR 502 for me

wzy• 3 years ago

How is the link down given that Fly.io is an cloud/edge hosting service?

emerongi2• 3 years ago

A plumber's house always has a dripping tap.

marcus_cemes2• 3 years ago

The two are not mutually exclusive, it's probably not an issue with horizontal scaling.

jesperwe• 3 years ago

https://status.flyio.net/ currently shows a partial outage.

esistgut• 3 years ago

Today they rolled some kind of upgrade and my backend become unreachable for hours, this is not my first problem with them. I assembled a quick docker-compose.yml and moved to Hetzner. Fly is pushing a lot of blog worthy stuff but it is not production ready.

manmal• 3 years ago

Until the linked post is up again, here‘s another source: https://phoenixframework.org/blog/phoenix-1.7-final-released

adamnemecek2• 3 years ago

Streams are a fundamentally underappreciated data structure because they are generally not implemented optimally. Streams correspond to coalgebras and that whole field is like the missing half of programming.

WJW• 3 years ago

If streams are the coalgebras, what do you consider the normal algebras of programming?

andrewflnr• 3 years ago

Structs. Regular objects. If you haven't heard the term "algebraic data types", searching it will probably give you an idea of how the "algebra" part fits in.

adamnemecek2• 3 years ago

Lists.

endisneigh• 3 years ago

Anyone have a good example of an app, in production, that's publicly accessible, that uses liveview? I'd like to check out the experience for myself.

pdgonzalez872• 3 years ago

Sure!

- Here is a thread on ElixirForum: https://elixirforum.com/t/phoenix-liveview-in-production-exa... - Here is a neat little aggregator: https://liveviewdemos.com/, and here is the code for it: https://github.com/leandrocp/phoenix_live_view_collection

bbkane• 3 years ago

I had to wait 10s for that list to load :/

college_physics• 3 years ago

How imprortant is elixir in all this? Is it merely the frontrunner of a useful new pattern? E.g., do erlang, BEAM or functional programming play a critical role or will other stacks effectively replicate this and how are they doing so far, which would be the next more mature?

say_it_as_it_is• 3 years ago

People will replicate LiveView in other languages but fall short in some areas. Golang might pull it off. Rust might in another 5 years.

sph4• 3 years ago

Live View is well integrated with the lightweight process/actor model that is central to Erlang and Elixir, where state and asynchronous events much are easier to code and troubleshoot than other languages.

So while you can replicate Live View everywhere, it's never going to be as convenient or expressive as the real thing.

On the project I am working on I have a Live View dashboard that's getting updated in real time from distributed async events coming from any server in the cluster with less than a dozen lines of code, and using nothing more fancy than standard Phoenix libraries (Phoenix.PubSub) and BEAM primitives (pg2, nodes, mailboxes, etc.). Porting Live View to Go, Python, Rust, Javascript is the easy part. You'll still miss the BEAM dearly.

PYTHONDJANGO• 3 years ago

I would like to study that code - wold you like to put that code on github or can you link to any similar example? Thank you very much!

nickjj3• 3 years ago

I've been using Hotwire[0] for a while now (Turbo + Stimulus) which works with any back-end, it's been great. It builds on everything you already know and doesn't require rewriting your app. Everything is treated as progressive enhancements.

It's not the same exact model and I wouldn't classify it as a replication of LiveView, it's more of an extension of the Turbolinks model from 2016 with a decent story for adding in frontend JS where needed.

I think it's comparable from a bottom line point of view of it being a solution that lets you send snippets of HTML over the wire (literally the tagline of Hotwire) to very quickly build nice feeling web apps with minimal to no Javascript.

Instead of going all-in with state and Websockets like LiveView, Hotwire sticks to a stateless HTTP model and sprinkles in Websockets only when necessary such as when broadcasting an event to any connected clients. I've used it in Flask before and it took a few minutes to get going. For the broadcasting bits server side, it works with Rails out of the box since this toolset was extracted from Hey and Basecamp. Other frameworks have their own ports tho.

[0] https://hotwired.dev/

bongobingo16• 3 years ago

solution that lets you send snippets of HTML over the wire

I haven't touched rails in a long time but isn't that how it all used to be done way back when? I feel like my original rails apps were making requests and I was returning HTML partials to be (crudely) diffed into the DOM?

john-tells-all• 3 years ago

wow that looks fun and useful - thanks!

noloblo2• 3 years ago

it is very hard for other languages to pull this off

as Erlang OTP uses a shared nothing architecture

each green thread has it own GC

communication is only via message passing

it is ok to fail over as the threads are easy to replicate as they are cheap

it is possible Golang via ergo as golang gets concurrency right, but doesnt have evolution systems and BEAM

Haskell via cloud haskell might replicate live view... but they are not the sensible defaults as in erlang/elixir/otp

Python never as their async concurrency parallelism story is ill-thought out w GIL limitations. Rust very very hard as their async concurrency design is extremely complex...

lopatin• 3 years ago

I've never used LiveView. Why is an asynchronous programming model required to pull it off?

noloblo2• 3 years ago

But you never know with rustaceans as there is a strong enduring culture to rewrite in rust

quechimba• 3 years ago

I'm working on a VDOM in Ruby using Haml kinda like JSX is used in React. It performs pretty well but I don't know how it scales. The syntax is probably the best part. Memory usage not so much, however I haven't done any optimizations.

mikl• 3 years ago

Part of the “magic” of LiveView is having a server-side process per connected user, to keep state and enable fast re-renders. This is where Elixir’s runtime (BEAM/OTP) really shines. To my knowledge, no similar technology has accomplished this so far, instead they put state in Redis or another database and need to re-load it from there every time an event needs to be processed server-side.

zapt02• 3 years ago

There's a TypeScript port that works rather well: https://github.com/beenotung/ts-liveview

weatherlight• 3 years ago

No one is mentioning that in Elixir/Erlang (and a bunch of other FP langs) a string is implemented as an immutable linked list of integers. linked lists have the property of its nodes being all stored separately in memory, which means we don’t really need to worry about space/time complexity while adding/deleting nodes in the list.

For example, A -> B -> C -> D is a linked list, but so is B -> C -> D, C -> D and so on, and each linked list is just a sub structure of another linked list.

This is interesting, because now we can confidently say that A -> B -> C -> D is a different list from B -> C -> D (even though one recursively contains the other one). Because we have that guarantee (along with the fact that a list CAN'T change), we don't have to define the same data twice, and we can reuse existing linked lists! This is called Structural sharing. Adding to this list as an extremely low memory cost.

If we go back to our html snippets that we are sending down the wire, you can see why all of this would have an advantage over how an imperative lang might represent strings under the hood.

ramchip• 3 years ago

Your explanation of structural sharing makes sense but there's a lot of nuance there:

1. Elixir strings are Erlang binaries (byte arrays), not charlists. Charlists are becoming rare nowadays even in Erlang because they're so memory-inefficient.

2. Comparing two lists for equality requires traversing them, you can't just look at the first node. If they were built independently they won't share structure.

3. HTML templating is (reasonably) efficient because of iodata, not charlists.

sph4• 3 years ago

Just to add to your explanation, Lisp cons cells works that way as well, and are implemented as linked list.

The great and often unmentioned pro of cons cells/linked lists is that they are a very simple form of persistent data structure, that make immutability and memory sharing very easy, so are an excellent primitive to build a garbage-collected immutable and shared-nothing language upon like Erlang, or Clojure.

chabad360• 3 years ago

There is a port for Go: https://github.com/jfyne/live . However, the API is not nearly as clean and nice, and it's probably not as efficient as Phoenix either. But overall it's really made a number of applications much easier to build and it has allowed me to avoid mountains of JS.

eptgrant• 3 years ago

Maybe a little off topic, but for a .NET dev, what benefits does LiveView offer over Blazor Server Side?

Phoenix Dev Blog – Streams

Related Stories