I can help you earn $ 6.0,0.0.0 with $ 5.0.0.0 in a w.e.e.k t.h.r.o.u.g.h M.R h.a r.l.a.n.d. w.h.o h.e.l.p.e.d m.e g.e.t the b.e.s.t in c.r.y.p.t.o t.r.a.d.i.n.g.. Contact information via WhatsApp +13052395906)
How we got to LiveView
201–210 of 293 posts
Re: How we got to LiveView
#202Earlier quoted context omitted.
Business-wise, what do you think the sweet spots are for LiveView, Phoenix and Elixir right now? I love the BEAM ecosystem (I've been using it since 2004, on and off), but for a lot of places, Rails is still a great place to start. What kinds of applications have you seen where all the BEAM features just make Phoenix et al not just a little snappier, but a clear winner?
The sweet spots for me are: 1. It is much easier to trace things through the entire Phoenix stack than it is in Rails. It is also much easier to add things to the Phoenix stack using plugs. 2. Elixir is concurrent, whereas Ruby is not, so when performing long-running processes, you can just do them in Elixir/Phoenix without having to rely on workarounds like Sidekiq, Resque, RabbitMQ, etc. 3. Writing multi-threaded a…
Sidekiq is not a workaround. This is a myth.
Most companies need to persist their jobs (what happens during deployments or when a process dies? do u just let all the job info disappear?) and have some kind of queue system.
Even Elixir has some redis backed queues.
BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. It doesn't really matter what tech stack you use anymore it can quite easily scale. Our devops team is 2-3 people and they're scaling our Rails architecture easily. Our scale is quite big since we're a b2c company and most of their effort isn't even on scale but on making deployments easier and troubleshooting all kinds of dev problems / pager duty alerts.
They would do the same amount of work if they were doing that with Elixir.
If you're hitting Whatsapp scale yes Ruby is less than ideal. Could we stop pretending like the challenges of 5 companies are what most devs need to go through?
Re: How we got to LiveView
#203Earlier quoted context omitted.
Hi Chris. We've been using LiveView to build a new app at Precision Nutrition and are largely quite happy with it so far. One concern we keep coming back to is that of the need for constant connectivity in order for the app to work. I'll throw up the disclaimer here that I've not spike on how to handle network disconnects. That said, we've had a few of our internal users lose their connection to the web socket, and t…
LiveView will automatically recover the connection, but you are correct it requires a connection to allow interactivity, but this isn't different from being unable to post a tweet while driving under the subway. The interesting thing about the subway usecase is even google docs last I checked will go into read-only mode when the connection is lost, so I don't consider this scenario particular different than the statu…
> it requires a connection to allow interactivity, but this isn't different from being unable to post a tweet while driving under the subway. The interesting thing about the subway usecase is even google docs last I checked will go into read-only mode when the connection is lost...
I think that 'read-only mode' and 'can't interact at all' mode are not the same.
I often have google news open when the train vanishes down a tunnel and keep scrolling down reading headlines until we're out the other side.
If a website freezes on me, I close it.
> Having said all that, one thing we are upfront about in general is LiveView is obviously not a good fit applications that require offline support :)
Not a good fit is rather charitable...
It becomes totally unresponsive and totally unusable in any offline or high latency situation (trains, stadiums, remote areas) right?
I know, and I've read your responses that 'well, all websites have to interact with a server eventually, so it's pretty much the same as that only better...' but, well... when you build websites like this, that's why product managers say "no, we don't want a website, we want an app".
Re: How we got to LiveView
#204> Sync.rb works like this: the browser WebSockets to the server, and as Rails models change, templates get re-rendered on the server and pushed to the client. HTML rendered from the server would sign a tamper-proof subscription into the DOM for clients to listen to over WebSockets. The library provides JavaScript for the browser to run, but sync.rb programmers don't have to write any themselves. All the dynamic behav…
I think that's true? More platforms should invest in the "sync" vs. "render" abstraction, especially the platforms that have strong concurrency already. A Big Phoenix idea though seems to be that you can take this a big step further: now that you're syncing, keep the state that you'd be attaching to React components serverside, and let sync update the front-end. It feels like a lot of the benefit you'd get out of a c…
I've been thinking about this too after doing a few LiveView projects but on occasions needing better interactivity on the front end than is easy with hooks and something like AlpineJS.
Many web front ends are built on the Elm architecture / Redux or my favourite, re-frame in Clojurescript land where the view is driven directly by the app state.
What I'd love to have would be the same LiveView connection, with one part of the state object on the server synced to one key in the global app state in the browser. You could keep the rest of the server data private, and the browser side can keep it's own state that's not needed on the server out of the way, but one part would always remain up to date.
Not sure if it would be 2 way sync, or more likely, send events back to the server and the updates would magically arrive on the syncd part of the app db. Events from server to client would also be useful.
It should be pretty efficient if it was diffed too. Phoenix LiveSync ;-)
Re: How we got to LiveView
#205> HTTP almost entirely falls away. No more REST. No more JSON. No GraphQL APIs, controllers, serializers, or resolvers In React / Typescript world you can get a little bit of this with Blitz - but not the live updating part, as far as I know. I found there was quite a lot to learn, but I’d also been out of the React world for a couple of years. Probably getting up to speed with TS was half of it, and obviously that’s…
You kind of still need to think about your queries though, especially when building more complicated stuff.
I do agree the batteries included part of Blitz makes it really pleasant to use if you need both front and backend.
Re: How we got to LiveView
#206Earlier quoted context omitted.
Almost every time I see a discussion about LiveView there’s someone complaining about the issue of latency/lag, and how it makes LiveView unsuitable for real-world applications. From what I understand, the issue is that every event that happens on the client (say, a click) has to make a roundtrip to the server before the UI can be updated. If latency is high, this can make for a poor user experience, the argument goe…
These kinds of discussions miss a ton of nuance unfortunately (as most tech discussions do), so hopefully I can help answer this broadly: First off, it's important to call out how LiveView's docs recommend folks keep interactions purely client side for purely client side interactions: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#m... > There are also use cases which are a bad fit for LiveView: > Animati…
> LiveView will beat client-side apps that necessarily needs to talk to the server to perform writes or reads because we already have the connection established and there's less overhead
Don't modern browsers already share a TCP connection for multiple queries implicitly?
Re: How we got to LiveView
#207Earlier quoted context omitted.
Sidekiq is great, but it is a thing you have to think about (in particular, how you're shuttling state from workers to a place where front-end can see it). The big win with Phoenix as I understand is not having to think about it at all: it has a natural expression in the language and the platform, and that expression is performant.
If it's just a small fire and forget thing in Erlang, you can just spawn the process, sure. My point is that once people start to care about what happens with those background jobs, you probably need some infrastructure around them, and then the Erlang thing might start to resemble Sidekiq a bit more.
This.
"When we want to have more control, i.e. persistence on disk, a workers pool, retries, among other things, there are several popular solutions:
Oban: a robust PostgreSQL-based queue backend process system. It has a UI in its pro version Exq: a Redis-based Resque and Sidekiq compliant processing library. It has an open source UI exq_ui verk: same as Exq. Is is compatible with Resque and Sidekiq job definitions"
https://sipsandbits.com/2020/08/07/do-we-need-background-job...
So basically sounds to me like Elixir is doing pretty much the same thing as Ruby. We usually do want more control and disk persistence, so...
Re: How we got to LiveView
#208Earlier quoted context omitted.
LiveView will automatically recover the connection, but you are correct it requires a connection to allow interactivity, but this isn't different from being unable to post a tweet while driving under the subway. The interesting thing about the subway usecase is even google docs last I checked will go into read-only mode when the connection is lost, so I don't consider this scenario particular different than the statu…
> it requires a connection to allow interactivity, but this isn't different from being unable to post a tweet while driving under the subway. The interesting thing about the subway usecase is even google docs last I checked will go into read-only mode when the connection is lost... I think that 'read-only mode' and 'can't interact at all' mode are not the same. I often have google news open when the train vanishes do…
[deleted]
Re: How we got to LiveView
#209Earlier quoted context omitted.
Are you using Live View for everything related to navigation too? For example if you transition between any page, is this happening through Live View? In any case, I'd love to chat with you on my podcast on how you built and deploy Glimesh if you're interested. It's at https://runninginproduction.com/ , there's a become a guest button in the nav bar on the top right if you wanted to schedule a call to be on the show.
Nick! Completely unrelated to this discussion but I just wanted to say I've bought a few of your courses and love you're work. What a pleasant surprise to run into you on HN.
Hi! Thanks a lot, I really appreciate it.
Re: How we got to LiveView
#210> Imagine your boss asks you to display how many other visitors are viewing a nearly sold out item to convert sales
Yeah, you could say “no, such overt manipulation is definitely unethical”.
But on a more technical side, I like to be a progressive enhancement purist (though sometimes it’s not the pragmatic option) and I don’t see any good reason why client-side scripting should be required for an online store. Can LiveView be used as a progressive enhancement, producing traditional HTML with links, form submissions and all that will work without client side scripting? If not, I don’t think LiveWire is suitable for that specific sort of site; and if it is, then surely you can’t know how many visitors there are on a given item? To be sure, the estimate will still be more accurate than the likes of (30 + 20 * Math.random())|0 which is maliciously manipulative, but it’s not correct any more.