[HN Gopher] Phoenix Dev Blog - Streams
___________________________________________________________________
Phoenix Dev Blog - Streams
Author : losvedir
Score : 184 points
Date : 2023-03-04 13:16 UTC (9 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| lucasyvas wrote:
| 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.
| POiNTx wrote:
| 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/
| bongobingo1 wrote:
| May be of interest to you:
| https://www.youtube.com/watch?v=I4vVxtrow-E
| POiNTx wrote:
| Thank you, haven't seen this before. Similar to
| LiveState[0] also
|
| [0] https://github.com/launchscout/live_state
| brightball wrote:
| That's definitely true, but in my experience the data update is
| the 80% use case.
| ch4s3 wrote:
| 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.
| realusername wrote:
| If the UI change requires no network calls, it's better to use
| a JS hook or/and Alpine in my opinion.
| sph wrote:
| 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.
| rhgraysonii wrote:
| 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.
| ch4s3 wrote:
| 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.
| manmal wrote:
| Until the linked post is up again, here's another source:
| https://phoenixframework.org/blog/phoenix-1.7-final-released
| wzy wrote:
| How is the link down given that Fly.io is an cloud/edge hosting
| service?
| [deleted]
| emerongi wrote:
| A plumber's house always has a dripping tap.
| marcus_cemes wrote:
| The two are not mutually exclusive, it's probably not an issue
| with horizontal scaling.
| jesperwe wrote:
| https://status.flyio.net/ currently shows a partial outage.
| adamnemecek wrote:
| 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 wrote:
| If streams are the coalgebras, what do you consider the normal
| algebras of programming?
| andrewflnr wrote:
| 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.
| revskill wrote:
| 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.
| jjtheblunt wrote:
| 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.
| Existenceblinks wrote:
| 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.
| sb8244 wrote:
| "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.
| revskill wrote:
| React solves the composition of components, which lacks in
| HTML technologies.
|
| What about liveview ? That's the question. They're different.
| sph wrote:
| You can compose components in recent versions of Live View
| as well.
| sb8244 wrote:
| "you just need to write better code to have composition
| with jQuery"
|
| To be clear I don't believe that, but that's analogous to
| what I hear when I see this.
|
| LiveView has composition of components, so there's an
| immediate answer to your question. You've already answered
| another piece with built-in soft real-time.
|
| In all honesty, if you have looked at LiveView and don't
| understand what it brings then I'm not sure if you looked
| sincerely.
| revskill wrote:
| I know what it does. Instead of boilerplate to declare
| channels to handle live websocket, now you can just bind
| the real data to a DOM html. Isn't it ? Is there any more
| to bring ?
|
| React and similar technologies actually not just scrap
| your boilerplates, it's real abstraction (forget the DOM
| API) with state and componentation. It's not like you
| scrap your jquery boilerplate).
|
| I see people mess with DOM Api in their application,
| which is not the right way, because it's mixing different
| abstractions together to create a mess.
| sb8244 wrote:
| LiveView is also state and components. + It has a view of
| the DOM to optimize the data it sends over wire.
|
| It's a complete way to build complex apps. I've
| personally built fairly decent complexity SaaS (18mo of
| dev) completely on LiveView + some react when it made
| sense.
|
| Saying it's just HTML pushed over WebSocket is like
| saying React is just virtual DOM with components. There's
| much more to it when you get into it.
|
| Plus it's enjoyable. I had significantly more fun and
| development speed building on it than the typical
| React+API approach.
|
| That said it's still situational and I don't blindly
| recommend it to everyone. I think Elixir has one of the
| best graphql implementations (Absinthe), so I still
| recommend React+GQL as well.
| brightball wrote:
| It's much more than that.
| Existenceblinks wrote:
| > I see people mess with DOM Api in their application,
| which is not the right way
|
| I found people who's stuck in DOM abstraction like React
| keeps reinvesting what platform is already capable of.
| Some abstract is so nasty e.g. forwardRef .. like really?
| Real Event bubbling is so much better, it visit every
| damn node you got the ref for free.
| realusername wrote:
| Liveview solves the dynamic areas in a easy way, that's the
| differentiating factor.
| revskill wrote:
| No ? I can easily use a React <LiveComponent
| websocketUrl="" /> to have a dynamic live area.
| realusername wrote:
| Can you point me the react API page for that? I've never
| seen that.
| UlisesAC4 wrote:
| He is trolling us. That does not exist.
| dmitriid wrote:
| Liveview solves the "write a fully dynamic and interactive
| application with next to zero Javascript that you need to
| write by hand" or, if you will, "server-driven UI apps".
|
| And it's hard to overstate, but to also properly explain,
| how important this is and how it feels like magic when you
| do it. Because it lets you tap into everything Elixr (and
| Erlang VM) have to offer on the backend without ever having
| to think of "how the hell do I bring all that to the
| client".
|
| My use-cases are: a big chunk of data is being processed,
| and while its being processed regular updates are sent over
| PubSub. Most actions a user initiates are long-ish-running
| and their updates are also sent over PubSub. Things that
| _other_ users are doing are sent over PubSub and possibly
| need to be reflected in the UI.
|
| In "traditional" JS-on-the-client-whatever-on-the-server
| model you have a plethora of questions of how to get that
| to UI: which endpoints to query, which updates to send over
| the wire, the formats, the frequence, authorisation,
| auth...
|
| With LiveView your "client" is an Elixir view living on the
| server which just updates the view based on those PubSubs
| (or timers, or Kafka streams, or user-initiated actions,
| or...) and LiveView takes care of upating the DOM/HTML in
| the browser.
|
| "Build a real-time Twitter clone in 15 minutes with
| LiveView and Phoenix 1.5" will give a good overview of
| this: https://www.youtube.com/watch?v=MZvmYaFkNJI
|
| [1] Built-in in Phoenix,
| https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html
| Touche wrote:
| Huh? LiveView is for interactive apps. It's not finished until
| the user leaves the page. It's not polling.
| Cyph0n wrote:
| It is not polling - it relies on Websockets.
| realusername wrote:
| 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.
| revskill wrote:
| Are you sure Facebook or Twitter is using liveview for their
| social feed ?
| realusername wrote:
| I'm piking a need that is common even for small websites. I
| even had to implement a similar concept for a small job
| board.
| nelsonic wrote:
| Facebook or Twitter using LiveView wasn't implied by the
| comment. It's just an _example_ use-case.
| ing33k wrote:
| check out https://zcashblockexplorer.com/ , it uses LiveView.
|
| https://zcashblockexplorer.com/mempool
| nelsonic wrote:
| 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. :-)
| cambaceres wrote:
| 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?
| floodfx wrote:
| 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
| bongobingo1 wrote:
| 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.
| emerongi wrote:
| > 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.
| lukevp wrote:
| There's a big difference from a UX perspective between
| clicking a button and having nothing happen and clicking a
| button and seeing something immediately happen, regardless
| of how long the data takes to retrieve.
| bongobingo1 wrote:
| Yes but my point is if you don't do anything in LV, you
| click the button and it sits there seemingly doing nothing,
| then patches the DOM with the update. Possibly the default
| "topbar" will show depending on its timeout configuration.
|
| So you need to pay some attention to applying-css/hooking-
| into-the-tooling (phx-click-loading) to show that a button
| was indeed clicked and is working on fetching data.
|
| Some things such as flipping between tabs can feel _quite
| bad_ if you click and the tab-button just puts a spinner
| there or the button just "fades a bit". Its much nicer to
| replace the content pane with some mock-blocks to show
| "yes, the tab swapped and its loading data" which is where
| you need JS to temporarily hide/show some things.
|
| And once you start doing that you should really be
| measuring the avg rtt on the socket because showing the
| mock-content for 1ms then swapping the real content is
| _also bad_ , so you need JS again to figure the best UX for
| that client.
|
| Or you simply render all the tabs in one go and again, duck
| into JS to perform the local show/hide.
| a_bored_husky wrote:
| > which is where you need JS to temporarily hide/show
| some things
|
| You do not need to write that JS though. LiveView comes
| with a few helpers to assist in client-only features.
| bongobingo1 wrote:
| I even wrote that in my original comment :)
| marcus_cemes wrote:
| 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.
| lilactown wrote:
| website seems down?
| faraaz98 wrote:
| it does
| the-alchemist wrote:
| HTTP ERROR 502 for me
___________________________________________________________________
(page generated 2023-03-04 23:00 UTC)