Live data from Hacker News

Build a real-time Twitter clone with LiveView and Phoenix 1.5

phoenixframework.org

241–249 of 249 posts

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#241

Earlier quoted context omitted.

I'll say Elixir isn't perfect. There are a few annoying bits that won't be changed due to backwards compatibility, that 98% of people won't run into. For example: a = [foo: "bar", foo: "baz"] Keyword.get(a, :foo) #==> gives you "bar" a[:foo] #==> gives you "bar" my_struct = struct(SomeStructWithFoo, a) my_struct.foo #==> gives you "baz" But really, this minor, minor inconsistency is near the top of my list of complai…

What's the problem there? A map has unique keys, a keyword list is just a list of {atom, term}, so there might be duplication. They are similar but they are not the same thing and are not to be used in the same places.

The problem is that it violates the principle of least surprise. Thankfully this sort of thing is not rampant in Elixir, and I discovered the example only after something like 50k lines of very joyful code.

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#242
post #43

Earlier quoted context omitted.

Yup, launching soon. Probably will open source it too.

Do you have somewhere we can register/watch to be notified ? Also interested here.

You can follow my updates here as the other commenter has mentioned. Thanks!

https://medium.com/build-ideas/

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#243

Earlier quoted context omitted.

Unlike a Promise, I hope you can cancel processes in Elixir

You can cancel a Promise by using AbortController and its AbortSignal, still experimental but supported in most browsers already.

I'll stick to Futures for; Futures work everywhere now and aren't immediately invoked when called with new.

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#244

Earlier quoted context omitted.

The patches don't need to be processed by the template engine to render them?

It turns out that Elixir/Phoenix templating is, in general, astoundingly fast, and that diffing operations are highly optimized at the language level due to the data structure (IO list) used. Here's some information: https://www.evanmiller.org/elixir-ram-and-the-template-of-do...

Due to the efficient diff'ing and data format, in practical terms I’d estimate a normal web app doesn’t require much more server resources with LV than a rest api backend. Maybe double? Of course that’ll depend drastically on the web page and template size used. Loading the text of full novels might not fair well!

On the extreme end I have a few pages that plot IoT data where it can take ~3 seconds to do a drop down in LV... Granted the server is serving a dozen SVG plots with a total of ~80,000 data points and performs the server template diff in that time. That’s on a RPi3 "server", which are also processing data, running similar pages on 4-10 browser tabs and running its own web browser. Haven't gotten close to using up the ram. Much of the slowness in that case is due to Chrome choking on that much SVG. I haven’t bothered optimizing the server side by dropping already rendered graphs.

Hope that helps give some insights. It'd be interesting to hear from people running high traffic sites.

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#246
post #22

Earlier quoted context omitted.

Yes, there are two Blazor variants. Serverside Blazor is basically the same thing as Phoenix Live View, client side Blazor is providing some optimized Mono runtime as webassembly.

From an empty repo, how many minutes do you think it would take one to do what Chris McCord did in Phoenix Live View in Blazor?

I have no idea. Probably longer. But it is the same idea. The big gains come from going back to the simpler server side programming model. I'm working on a big Angular application right now for which something like Live View would be the ideal fit. That said, a switch to Elixir would be a very hard sell in my company. Blazor would be easier because it's .NET.

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#247

Earlier quoted context omitted.

You can cancel a Promise by using AbortController and its AbortSignal, still experimental but supported in most browsers already.

I'll stick to Futures for; Futures work everywhere now and aren't immediately invoked when called with new.

Not sure exactly what futures you're referring to as there are no "native" futures in any browser (that I know of) so they are either implemented on top of Promises or by using callbacks, and still doesn't solve the problem of cancellation...

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#248
post #246

Earlier quoted context omitted.

From an empty repo, how many minutes do you think it would take one to do what Chris McCord did in Phoenix Live View in Blazor?

I have no idea. Probably longer. But it is the same idea. The big gains come from going back to the simpler server side programming model. I'm working on a big Angular application right now for which something like Live View would be the ideal fit. That said, a switch to Elixir would be a very hard sell in my company. Blazor would be easier because it's .NET.

I also don't know enough about c#, to comment on this being a risk for blazor but having the BEAM's process isolation is absolutely critical to minimizing programmer error from turning into a let's say a DOS attack risk, or possibly worse.

I worry that all these other platforms rushing to emulate liveview are missing that extremely critical component of this model. If you aren't certain about what I mean, I suggest watching Sasa juric's "the soul of erlang and Elixir" video where forward progress of the system is unimpeded by a panic or a process that attempts to hog processing via an infinite loop, both are detectable in the running system, and able to be easily identified (down to the malfunctioning function name) in the in-prod system.

Re: Build a real-time Twitter clone with LiveView and Phoenix 1.5

#249

Earlier quoted context omitted.

I'll stick to Futures for; Futures work everywhere now and aren't immediately invoked when called with new.

Not sure exactly what futures you're referring to as there are no "native" futures in any browser (that I know of) so they are either implemented on top of Promises or by using callbacks, and still doesn't solve the problem of cancellation...

You're right. There's not a native solution. I've used Fluture (https://github.com/fluture-js/Fluture) for while now as it follows the Fantasy Land spec. The canceler is returned in the Future's constructor. The biggest feature difference in comparison to Promises is that you can pass around a Future adding to the data transformation without it being invoked until fork is called.

It's good to know that there exists a way to do this natively now though.

Post reply on HN