Probably by design - or just not implemented yet - but it seems the flags for the RazorFormat plugin are missing.
I am especially keen on seeing the MinifyHtml and UseAdvancedCompression added to the .Net Core version.
One idea might be to use https://github.com/Taritsyn/WebMarkupMin/wiki/WebMarkupMin:-ASP.NET-Core-1.X
This could work, but it does not play nicely with ServiceStack by throwning a ‘NotSupportedException: Stream does not support writing.’ exception. Not sure if this is ServiceStack causing this or the WebMarkupMin package…
Please read the v4.5.2 release notes, none of the existing RazorFormat implementation is available in .NET Core. We’ve developed a new version of RazorFormat based MVC Razor Views, but we no longer have fine-grain access to how Razor Views are created or executed so these features are not possible in .NET Core.
We’re not going to take a dependency on it, but anything that works for MVC Razor Views automatically works for ServiceStack’s RazorFormat. Like I said we’re just using MVC Razor Views as they are, everything about the execution and behavior of the views is controlled by MVC. ServiceStack RazorFormat functionality is essentially just choosing which views to render and rendering them.
Right. I will ask the guy(s) from WebMarkupMin to check out ServiceStack, since there is an issue with the outputstream. Their lib cannot compress or minifiy the stream as soon as ServiceStack touched it.
Don’t know what “as soon as ServiceStack touched it” means, we’re just resolving the view using MVC’s IRazorViewEngine.GetView() API then rendering it to the HTTP Response OutputStream.
If you prefer we could have an option that buffers the results, serializes it to a HTML string then compresses that HTML string before writing it to the response?
By the “touched it” I meant: When ServiceStack handles the request. It seems that the output stream can no longer be written to after ServiceStack handles the request. For your information, see the issue I posted with them: ServiceStack + WebMarkupMin issue
Having buffers would not help in this case, since then I would still need to use bits and pieces from the WebMarkupMin package and do minification ‘manually’. The nice thing of the new pipeline is that everything should be chainable. Using WMM save this from ServiceStack and means you do not need to maintain this yourself. Win/win.
ok I’ve had a look at their WebMarkupMinMiddleware.cs implementation and it shows that their replacing the Response Output Stream with a MemoryStream that they then Transform which isn’t going to work if the Stream is Disposed of after it’s written to response. So I’m now leaving the Stream open so it can be re-read in this commit.
Which will now resolve this issue and minify the razor output after changing your ServiceStack dependencies to use wildcards (recommended for .Core NuGet packages):
Request.ToOptimizedResultUsingCache does not work anymore when I add the WebMarkupMiddleware. Kind of obvious, since the optimized result is… optimized.
It seems that using WMM breaks more than it fixes. Although I see good use in the minifiers, the way the library handles the streams and output is not that well architected.
My personal feeling is that adding bits and pieces from the library to ServiceStack would be good. It would however be best if the library could work with ServiceStack and vice versa. Any chance for a coop?
Replying to myself…
The library ads some overhead. I tried mitigating a lot of the overhead, but going from 7000 RPS back to 50 RPS… That’s not the way to do it. WMM is out.
IMO this only makes sense if you’re caching the HTML views as it has to buffer the response, parse/minify as a HTML string and serialize the string response, and if you’re already compressing the response, minifying HTML won’t buy you much.
using Loader.IO with 10k requests per second, reponse times stay on 113 milliseconds at average. I expect this to go lower with optimized views (I will experiment with minified views on publish)
THX!