Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got to LiveView

fly.io

Post reply on HN
Print view View original

261–270 of 293 posts

Re: How we got to LiveView

#261

Post by joelbluminator »

0x000000001 wrote: post #257
joelbluminator wrote: post #233

Earlier quoted context omitted.

I don't know about Oban. I don't think it's bad design for the workers to be separate from your main app like in Sidekiq (they do 'require' the app but they are essentially separate from the servers). Anyway making this point as a huge win for Elixir over Ruby seems really exaggerated to me.

It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.

What if you want to scale your job workers and your servers separately?

Re: How we got to LiveView

#262

Post by innocentoldguy »

0x000000001 wrote: post #231
joelbluminator wrote: post #202

Earlier quoted context omitted.

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 us…

In Elixir you'd use Oban instead of sidkiq and you get more performance and it scales out horizontally with your app. Each new instance of your app is essentially a new sideqik server as a bonus edit: > BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. This is a hilarious statement which I hope is satire

I don't see BEAM and OTP as being synonymous with Kubernetes. They have some overlaps but they aren't drop-in replacements for each other. If anything, they are complimentary technologies.

The advantages of BEAM and OTP are that I can spawn new concurrent processes throughout a cluster and then use the actor model to send direct messages to those processes from any other processes, regardless of where the sender and receiver happen to be. I can also easily configure Behaviours so they automatically run on either a single node or every node in the cluster, depending on what they are doing.

In both cases, if a node goes down, Elixir will automatically restart any affected processes on another node. When a process has an issue, I can surgically handle that issue at the individual process level. Kubernetes doesn't handle problems that granularly.

One advantage of Kubernetes is autoscaling. OTP and BEAM don't do that.

By using libcluster, you can combine Kubernetes and BEAM/OTP and get the best of both worlds.

Re: How we got to LiveView

#263

Post by olah_1 »

wut42 wrote: post #219
olah_1 wrote: post #53

Imagine building federated tech with this. ActivityPub stuff like Mastodon, Peertube, etc. The performance on small servers would be incredible.

https://pleroma.social is an ActivityPub server like Mastodon but in Elixir.

Would be awesome if a Pleroma front-end was written in this way. Just host one app that is ultra-performant.

Re: How we got to LiveView

#264

Post by tmyllymaki »

keewee7 wrote: post #72

Has anyone tried server-side Blazor in ASP.NET Core? How does that differ from the LiveView approach?

I've written multiple apps in server-sided Blazor. For intranet apps its fantastic. When the server is not located nearby the delay gets more noticable and its not pleasant to use.

Currently on .NET 5 the missing of hot-reload is the biggest issue. Otherwise its really a breeze to build anything.

Re: How we got to LiveView

#265

Post by dnautics »

0x000000001 wrote: post #258
dnautics wrote: post #249

Earlier quoted context omitted.

Point is, they are just plugs. You can put routes in an endpoint, it'll work just fine. The distinction is just a -often useful- prescriptive opinion by Phoenix. (Plug does not split between endpoints and routers)

very true, but the abstraction is pretty useful

it's useful if your project gets very large. It is a non-negligible cognitive cost when your project is very small and you are new to Elixir and Phoenix

Re: How we got to LiveView

#266

Post by davidw »

joelbluminator wrote: post #261
0x000000001 wrote: post #257

Earlier quoted context omitted.

It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.

What if you want to scale your job workers and your servers separately?

I think it's nice that you can run everything in the same server. If you're scaling, and want to split everything up, that's a "nice problem to have", but it's convenient if you can just run everything in the same application/codebase when you're getting started.

I do agree with you that's not a huge win compared with Rails, but it is nice to have. I think you'd have to look more at something like "lots of concurrent, long-lived connections" for the real wins over Rails for the BEAM ecosystem. I mean, you can do that in Ruby if you want to, but it's going to be cleaner and simpler with Elixir/Erlang.

Re: How we got to LiveView

#267

Post by AlchemistCamp »

cs44 wrote: post #83
akoutmos wrote: post #46

Earlier quoted context omitted.

For a lot of the LiveView applications that I write (which is actually quite a few these days), I will usually lean on something like AlpineJS for frontend specific interactions, and my LiveView state is for things that require backend state. For example, if I have a flag to show/hide a modal to confirm a resource delete, the show/hide flag would live in AlpineJS, while the resource I was deleting would live in the s…

I'm surprised to see so few mentions of AlpineJS. Personally, PETAL has become my de facto stack.

The main thing that's kept me from using Alpine in my serious projects is that it doesn't work with a strict CSP.

Re: How we got to LiveView

#268

Post by wut42 »

olah_1 wrote: post #263
wut42 wrote: post #219

Earlier quoted context omitted.

https://pleroma.social is an ActivityPub server like Mastodon but in Elixir.

Would be awesome if a Pleroma front-end was written in this way. Just host one app that is ultra-performant.

When I was still working on Pleroma, I was stealth building a fully featured frontend on Hotwire + LiveView for some parts. Sadly this won't go further :-)

Re: How we got to LiveView

#269

Post by wut42 »

iudqnolq wrote: post #259
wut42 wrote: post #218

Earlier quoted context omitted.

There is a misplaced `}` :) He actually wanted to do : def handle_event(save, params, socket) do ... {:noreply, socket |> put_flash(:info, "It worked!" |> redirect(to: "..."))} end which would work.

Ah. It's a nonstandard formatting though.

Agree-- Even if it's possible I always feel dirty to do that kind of "magic", and always prefer this way:

    def handle_event(save, params, socket) do
      socket = socket
      |> put_flash(:info, "It worked!")
      |> redirect(to: "...")
      {:noreply, socket}
    end
I feel like it's more readable this way.

Re: How we got to LiveView

#270

Post by jarpineh »

chrismccord wrote: post #108
jarpineh wrote: post #34

Earlier quoted context omitted.

Hi. I got a couple of things: I seem to remember in the original announcement presentation there was a demo of SVG being updated inside a page 60 times per second. All from server. Did this actually become feasible? I’m thinking graphs and maps with live data. I might not need as smooth animation there. Though that could make for nice dashboards. Other bit that interests me is web apps for long running tasks. What’s…

The 60fps rainbow works as a fun stress test demo, but really you should not be pushing events down the wire every 16ms to animate something on the client :) That said, you are right that SVG charts/maps are a surprisingly fantastic fit for LiveView. You could actually render a fully interactive and dynamically updating chart by only sending SVGs – and it will probably send less data than hydrating the same client-si…

Hey, thanks a lot. These are great tips. Context Charts look really good and lightweight to run. Porcelain seems verty promising. Guess I’ll start with one of the tutorials elsewhere in the thread. Good info here all around. Much appreciated.
Post reply on HN