NVM I take it back they still exist in the DOM, I misinterpreted the docs.

I'll give you scroll position and viewport. But that regarding DOM elements, that's literally the first sentence in the docs:
"It is often useful to limit the number of items in the UI" :D

Isn't that what limiting streams is for?
hexdocs.pm/phoenix_live...

mix ecto.drop

Absolutely on your side if an avatar is all you need but for apps handling more than that, I like the boilerplate because it gives more clarity

The platform handles large galleries with large files ~20-200mb but there is a delay until the user is able to view their gallery, we use that delay to offload the image processing to lambda services to reduce overall cost and load on our application servers

But we have yet to see how this will perform in production but I am quite happy with everything and besides some tinkering it didn't require much time to implement.
What part you find to be leaking?

Yes waffle is not as extensive as active storage. We use it together with 'Image' to calculate metadata while uploading is in progress. Additionally we use an embedded schema backed by a jsonb column to store metadata alongside with the image itself.
So it's `embeds_one :image` and we are good.

You are correct, and my prior answer is a bit misleading. We needed an eager way of creating variants to have tighter control of when and how image creation happens. We ended up using undocumented functions of active storage's API some of which have been silently made private from rails 7 to 8.

Just to give an example of problems with active storage:variant creation jobs download your file from your storage every time you create a variant.If you want to create a lot of variants this is a huge overhead.
Most of the time I felt like it's an over engineered avatar handler. Maybe skill issue🤷

I worked in a rails code base that handles a lot of attachments and I would have wished for something like waffle instead of the opinionated active storage.
I do dislike some parts of waffle, but I really appreciate the loosely coupled approach which let's me handle things my way.

Ran into this couple of times. Now I am trying to always convert dt's to Unix timestamps before I do any kind of comparison or calculation on them.

It is quite easy to block your entire CPU with image processing, leaving the application in an unusable state.
Moving the image processing to dedicated servers/functions makes a big difference, I promise :)

A while ago I struggled with this as well, even though I used rails.
We had to scale the servers up to handle short bursts of huge amounts of processing jobs.

We managed to save us a lot of struggle and costs by moving to lambda fns.

With phx I probably would have done this with FLAME.

That's only true for dev credentials.
The default for new projects depends on env variables to set your database connections. I don't see a benefit of using .pgpass really since you'd probably have more than just DB credentials in your project, thus using env variables would be more flexible.

That's not correct, since || would also "work" with false while coalesce requires x to be nil to return y.