How to handle dynamic compression in embeded resources?

AnderssonPeter / CompressedStaticFiles

asp.net core middleware to send compressed static files to the browser without having to compress on demand, also has support for sending more advanced image formats when the browser indicates that i has support for it.

Apache License 2.0

88 stars 18 forks source link

How to handle dynamic compression in embeded resources? #34

Closed aloksharma1 closed 2 years ago

aloksharma1 commented 2 years ago

Hello, now that i have replaced static file middleware with yours and removed responsecompression middleware, how do you suggest we do compression on fly for dynamic resources embeded in dll files (e.g. RCL in my case).

thanks

AnderssonPeter commented 2 years ago

This library only works with file located directly on disk, but one idea would be to have a post build step that extracts the files to disk? This way it should magically work.

What is RCL? And how are those files served without this library?

aloksharma1 commented 2 years ago

RCL is reusable razor class library check here, i am serving those files using ManifestEmbeddedFileProvider , extracting and putting these files in new places doesnt make sense in this case; they are mostly for backend.

AnderssonPeter commented 2 years ago

If they are mostly for backend what is the point of being able to serve them compressed?

But any way this library doesn't support embedded files natively but you could try to add a custom IAlternativeFileProvider but I'm not 100% that it will work, and if you do i have no idea where to store the compressed versions of the files.

AnderssonPeter commented 2 years ago

On second thought it might work right out of the box if you embed the compressed files in the same place as the uncompressed files, the middleware should use the ManifestEmbeddedFileProvider and discover both versions.

But i have no idea how to add the compressed versions to the same assembly.

aloksharma1 commented 2 years ago

the second option is good, but i have way too many files to consider. what if i change the priority of your middleware with response compression middleware ? will both work in that case?

aloksharma1 commented 2 years ago

ok i did some tinkering, here is my solutions if anyone needs it in future:

filewatchers are not helpful as its embedded resources, the only good way is using second option suggested by peter.
now dynamic iis compression also does the job, but this kills the purpose of saving resources in first place
so we have to add a small middleware listen for stream and and queue for the embedded file for compression and store it on disk (this is still the best solution as compression will only happen once & in my case i have 1000s of such files so i cant increase dll size any further).

AnderssonPeter commented 2 years ago

If you would move the extract and compression to build time instead of runtime then you could use zopfli giving you smaller gzip files. (Might increase build time a lot so only do this when building a release version)

Added benefit is that you don't risk any old files being used instead of the new ones.. (Don't know how you deploy but if its a simple copy and paste and you don't delete your compressed files, then you might serve a compressed file with old content)

aloksharma1 commented 2 years ago

as i said, only problem is very huge directory & unknown number of files.. .also i am using broltisharp & zopfli with on fly middleware giving same amount of compression. thanks for the input though.