Initial issue

[tanguilp]

@niccolox I've configured the dependencies and the project so that:

• we no longer use a CSRF token for CSWSH check
• session is always sent to the liveview, even if not set (it's going to be an empty map)

I've described the pattern we can use there: https://github.com/phoenixframework/phoenix/pull/5667#discussion_r1434309025

We at least need one login deadview to set the cookie, to demonstrate the unauthenticated vs authenticated flow. This login view can just be a login / password view with any password being accepted.

[niccolox]

ok, do you want to create a markdown checklist of tasks / features and assign them?

I will fork and add a fly.io deployment toml and dockerfile

[niccolox]

We at least need one login deadview to set the cookie, to demonstrate the unauthenticated vs authenticated flow. This login view can just be a login / password view with any password being accepted.

I assume you want phx.auth.gen ? https://hexdocs.pm/phoenix/mix_phx_gen_auth.html

I think we want to align with the canonical "Phoenix way" of doing things, this will help with acceptance and community buy in

[niccolox]

I created a PR here https://github.com/tanguilp/cacheable_liveviews/pull/2

I think I am misunderstanding your requirements, but I thought it would be easier just to push some code for feedback

[tanguilp]

Well it's not really about my requirements but how I see things :)

Now you have extensive experience with HTTP caching and therefore another vision.

My initial idea was to:

• demonstrate feasibility of LV caching (using the modified libraries)
• give an example to future users
• make a video & advertise

This is why I was thinking of something very simple similar to wax_demo:

• no DB, so that it can be launched locally without a DB running / Docker launched - allows using hosting without DB as well. Instead (D)ETS can be used should we need to store something (but do we?)
• fake authentication process (like Wax: any login, password=123456) and no registration → simplifies running the demo and there's IMO actually no need to gather GDPR data
• one main LV page that is the front shop page - number of reviews are "live" (artificially updated by LV) as well as price → cached
• optionally: other LV catalog pages, but we could end up actually opening an online shop :) → cached
• login page, that is a deadview (needed to set the session) → obviously not cached

For instance main page would like something like this:

That's what was in my mind. Now if you see things differently (and you sure do!), let's discuss what you wanna see in this demo & what you intend to demonstrate.

[tanguilp]

BTW I'm not sure I'm going to have time before new year to work on this.

And if you want to take another direction for the demo, please do and I'll assist!

[tanguilp]

@niccolox Happy new year!

So I didn't have time to focus on this :see_no_evil: The discussion to include it in Phoenix has not led to the inclusion of the feature. For now my plan is:

• to complete implementation in phoenix and phoenix_live_view
• to make a demo
• to write an article on it and gather feedback from users for further inclusion in phoenix and phoenix_live_view

I'll be very busy until end of February, so it won't happen before March.

BTW you didn't answer how you imagine the demo :)

[niccolox]

hi @tanguilp I am using LiveView again and the performance is terrible and am looking again at your caching ecosystem

did you work more on LiveView caching?

if not, I think I will be building either dead views with zero cookies for landing pages and SEO and Liveview probably behind nginx or Varnish which is crazy, but that's the reality I think

[tanguilp]

Hi Nicholas!

I underestimated the time & energy to implement all of what we discussed late last year as you can see :)

I tried to merge some required changes to Phoenix, but unsuccessfully. Since then I didn't make progress on this issue, which is still in my list. I pretty much know what has to be done, but it's not my priority at the moment. I hope I can achieve it S2 this year. If you have a urgent need and you're ready to pay for PS then I can reprioritize.

Good news is that I'm working on a LiveView app atm, so I have a better understanding of how to do it.

Putting your app behind a RP for caching will not work though, because session check by liveview is based on cookies, and a cached page will be valid only for the user with the cookie that generated the page. This is one of the 2 main changes that have to be done to make HTTP working with LV. Note that at the beginning at least, I'll implement it in a custom Phoenix & custom Liveview repositories, it won't be in the main packages.

[tanguilp]

@niccolox I'm almost done and I just need to write an article now. Feel free to check it out