Let's discuss Phoenix LiveView

The authorisation and authentication problem maybe I’m just not seeing? Once you’ve authenticated (I do this as per the docs with a short lived phoenix token), it’s a case of either authorising on channel join and or on handle_out? Your auth checks can just check your existing authorisation modules/rules? I have mine setup very similarly to bodyguard (I’d link it but I’m on mobile), so I can pretty much call them anywhere -cli, api, channel, etc.

Right now liveview would be super helpful for me as it stands, and I’ve love to get my hands on even the some alpha thing to see how well it behaves for my use case - I’m actually using stimulusjs controllers and channels to do a small subset of the features, but I have to hand roll them per page. I will agree It would be nice if it didn’t necessarily render the whole template and layout but the talk did say it’s early stuff and there are optimisations that could be made

The LiveView demo was awesome. I’m very keen to play with it even it’d be in alpha stage…

Isn’t it similiar to Drab?

It is very similar to Drab, and I think it’s strange that the existence of Drab wasn’t even acknowledged in that talk. We can’t claim that LiveView was inspired by Drab, because Chris’s idea dates from as far as 2013, but I believe Drab deserved a mention as the first successful implementation of similar functionality in the Phoenix ecosystem.

In my opinion, I’ve always been in favor of diffing on the client, except for the fact that you’re sending large amounts of data back and forth, so I can see myself using LiveView rather than Drab. As I said in my comment, the main reason I didn’t write something like that myself was my (maybe stupid) reluctance in sending the entire page’s HTML down the pipe.

I wonder if LiveView can be “hacked” into reuseable “widgets” which on can embed in “normal” pages. I guess we’ll know when it comes out. Something like unpoly + morphdom.

Yes, that’s true, but something you can do with a controller is adding a plug that handles authorization for all actions. That keeps the bodies of the actions cleaner. I’m not aware of a similar concept for channels.

Maybe Phoenix should try to duplicate the functionality based on HTTP requests on top of the channel infrastructure: you could have a channel router, a channel pipeline, channel plugs, etc.

Or maybe authorization should be handled at the level of the context access functions.

Ive specifically been explicit with my auth checks so far partially to reduce magic for the junior and partially because I don’t always have a nice mapping between permission and action.

I used to have the checks in the context list, get, etc functions only, but I found that as I needed to check in more places like channels or other places where the schemas were already loaded, that I’d need to check them independently. I’m not 100% happy with how I’m dealing with auth checks, but I feel putting them solely in contexts puts you into a corner.

I wish its stable version releases with Phoenix 1.4. I wanna use it immediately with Phoenix 1.4.

Thank you @chrismccord !

I basically built a channel router myself because of the number of endpoints I had and the duplication of logic between them. I didn’t have to build pipelines and plugs though, because I put all the common functionality in the routing.

OK, can somebody please enlighten me why this is going to take the world by storm because obviously I’m missing something.

Let me explain:

Even back in 2009 when I developed my first (multipage, servlet-based) web application I was using jQuery to make ajax calls, copy DOM fragments from invisible sections of the page, splicing in the retrieved data, and then replacing the relevant section of the page.

To me Drab/LiveView are an evolution to this approach modernized with shadow DOMs and web sockets which allow data to be pushed from the server. So what am I missing?

If this is so amazing then I have to conclude that the majority of the web development community is suffering from framework blindness because they either don’t know or don’t want to know how HTML/CSS is processed in the browser.

Granted I have wondered why approaches like hyperHTML haven’t been getting more press but what do I know?

Then there are the “engineering concerns”. When it comes to page generation most templating approaches provide a relatively clear separation between the server code and the (template) markup code. Furthermore page generation builds the client’s initial state. To keep things simple once the client has that state/page it should be the client’s responsibility to manage it.

So generating HTML in other parts of the server code seems counter productive because you are fragmenting the page (and page management) across the server code base, so it becomes increasingly difficult to get a unified (maintenance) view of the page for layout and styling purposes - there is an unpleasant increase in coupling between the server code and the page.

To me it makes more sense to send plain data (no markup) to the client and leave the responsibility of managing the necessary page changes to the code residing on the client.

It’s not. I agree it’s being overhyped. It doesn’t really allow you to do anything new, it’s just a simpler way of doing what you’ve always done before. And a way to avlid writing Javascript so that the rendering ligic lies only in the server.

Simple from which perspective? Why is it simpler to have the client manage the view changes while the server manages the initial view? To me it’s simpler if the server manages everything. At least it allows you to use only a single programming language (elixir) and a single build pipeline (mix).

I share some of your caution/skepticism, but I’m trying to keep an open mind. This is the first time I’ve really dealt with a server-side technology that makes stateful connections practical in web apps. It’s a boon to backend-oriented developers who want to minimize use of javascript, which I can sympathize with. It will be great for initial prototypes, but at scale it will also exhibit strange timing issues that will require CRDTs or similar to deal with, and that will take away from its simplicity.

I think it’s all going to come down to where it fits in a correctness/simplicity tradeoff.