Support redirecting to Azure CDN

[marklagendijk]

Currently we already have the AzureBlobStorageCache that allows storing the cache on Azure Blob Storage.

In ImageProcessor.Web there was the option to redirect to the Blob Storage / CDN Endpoint on top of the Blog Storage instead of serving the image via the web application.
This is nice for several reasons:

• With CDN endpoints one can serve the image from a location close to the user.
• Not having to serve the image itself reduces load on the web application server.

I looked a bit at the code to see how hard it would be to add this to the AzureBlobStorageCache. As far as I can see the core logic doesn't support redirection, yet. So both the core logic and the AzureBlobStorageCache would have to be extended.

[marklagendijk]

After more digging through the issues etc. I found the following.

In this issue @JimBobSquarePants wrote:

I understand that they would just act as "caches" meaning the local web application would still have to load the content and serve it, hence invalidating the CDN part of it?

That's not how I would use the cache no. For scaled applications that require a CDN you would install the middleware into a single application that would be the end point for your CDN. All you client facing applications would request the images using the url + querystring from the CDN and that would only call the endpoint when it is not contained within it's own cache. You gain the full benefit of the CDN then.

This is a good point, so the current solution already allows for the case where the CDN is put in front of the application serving the image:

• All image urls point to a CDN endpoint
• The CDN serves the image from cache if it has it cached already, else calls the webapplication
• The webapplication generates the image using ImageSharp.Web

That being said I still think that there is a use case for the redirection based approach, because that is a lot simpler to setup for users.
The main question is whether it is worth the effort / complexity required to implement this in ImageSharp.Web.

[JimBobSquarePants]

As I described in the other issue you quoted you really don't want to do this.

Basically you gain no localization benefit since the application has to process the request to do the 302 redirect to the endpoint. That's why a pass-through streaming option was added to ImageProcessor.Web (which I see you're familiar with and is possibly a driver for your request due to familiarity)

The processing pipeline as you've listed is absolutely the best way to use a CDN with the middleware.

Configuring your own application as a CDN endpoint is actually really simple.
https://docs.microsoft.com/en-us/azure/cdn/cdn-add-to-web-app it's a couple of text fields when you create your CDN.

[marklagendijk]

Thanks for the reply!
I will go with this solution then. Familiarity was indeed the main reason.
My current plan was to:

1. Port our web-application (CMS) to .NET Core
2. Deploy to Azure and get to production
3. Look into putting a CDN in front of the application

I was just trying to make ImageSharp a drop in replacement for ImageProcessor.
Now I'll:

1. Try serving the images directly from the application using the PhysicalFileSystemCache performs well enough as a temporary solution.
2. If not do the CDN before moving to production

[JimBobSquarePants]

Excellent. I'm glad my explanation is clear.

ImageSharp.Web is much, much faster than ImageProcessor.Web so will scale for many applications. It's basically everything I'd wish I'd designed the first time around.

[dLopes-SE]

@JimBobSquarePants Thanks for your explanation.

(1) My first approach was to create a new container where the cached files would be stored. However, since we serve our application requires a CDN.

(2) Putting a CDN in front of the application revealed to be the best option right? This way, option (1) seems to be worthless since the CDN is already "caching" the images (due to unique URLs). I'm I thinking right?

[deanmarcussen]

@dLopes-SE

1. Good choice
2. Container still useful, as experience with Azure Edge (and others) says that the CDN will still choose, at it's leisure, whether to dump it's cache, or check the source to see if it has been updated. Additionally they tend to be PoP based, so one CDN presence may have cached the image, another may not.

[dLopes-SE]

@deanmarcussen Thanks a lot for your explanation.

I'll then put a CDN in front of the web app and create a new container to save the cached images. Additionally, I'll create a rule that deletes cached images that haven't been modified in the last X hours/minutes. Basically, I'm setting a TTL for these images.

Thanks for your support @deanmarcussen and @JimBobSquarePants. Please tell me if I'm wrong about anything :)

[deanmarcussen]

For infos we quite successfully run all our ImageSharp.Web sites through a CDN, with the setup @JimBobSquarePants describes above.

Probably the key component to it for us is using razor tag helpers to generate urls (and resizing / profiling information), which are able to read from IOptions to automatically prefix the CDN endpoint href when configured.

This makes the move from development to production reasonably trivial.

We find it works well for both the performance, plus the reduction in disc space from the PhysicalFileSystemCache

[JimBobSquarePants]

Yep, tag helpers are definitely your friend here. Outside the scope of this library of course but I would recommend anyone to develop them.