WIP FEATURE: Faster asset loading

[Sebobo]

The thumbnail and preview urls are now built as async Uris, to generate them very quickly and not require loading the resources during the generation of the asset list.

This and some other optimisations in this change make the Assets query at least 50% faster in my test cases.

• [x] Create async Uris for thumbnails and previews
• [x] Only load necessary data for each assets asset source
• [x] Optimise caching behaviour to prevent the browser from loading the same images again
• [x] Further tests and checks of UX and API

[Sebobo]

Hi @bwaidelich, I have a question regarding the API, you don't have to dive deep into the code, or something:

Background:

I made this change as I noticed that the preview and thumbnails Uris of the asset proxies are quite slow to generate, based on the AssetSource etc... So I change them to return redirects instead which makes the response much faster and with the cache settings I achieved faster UI performance.

Now the question:

Should I provide both uri types as thumbnailUri and asyncThubmnailUri or similar, oder just provide the async ones like I did with the current state of this change? I could ignore the old Uris in the request from Media.UI, but anyone who wants them from the GraphQL API could still query them.

[bwaidelich]

I'm not deeply into this, but in general we should never return URLs that trigger redirects IMO (for the "frontend" that is). The problem with "async" URLs is that they end up in caches leading to every request to that resource ending up in two round trips for all eternity (OK, until caches are flushed – but "eternity" sounds more dramatic).

For the backend it's a different story.

But let's assume we want to create the GraphQL API in a way that it could be used from the frontend, I wonder what a useful API for that would be

[bwaidelich]

type Asset {
    # ...
    thumbnailUrl: Url
    previewUrl: Url
    thumbnail(maximumWidth: Int, maximumHeight: Int, ratioMode: RatioMode, allowUpScaling: Boolean): Image
}

Those three fields should only render the corresponding image once they are invoked, right? So maybe you can just tweak the client code to only ever include those when you really need to (e.g. for the detail view)

[Sebobo]

For the backend I need the thumbnails Uris immediately as I show all of the queried assets. In theory I could request the preview uri there on demand, but that adds complexity again.

Probably this mainly affects the NeosAssetSource, as other asset sources usually provide the Uris with all the other data and don't need additional processing. So it's maybe worth a shot to investigate the NeosAssetSource / thumbnail api what could be improved there and this way maybe also speed up normal page rendering. I often noticed how many DB requests are done for pages with several images.

[Sebobo]

I will abandon this. I improved the performance in other places and things are quite fast now.