When an Episerver Commerce site is put into read-only mode, either manually or by automation, it would be really bad if the code is not prepared to for that situation. In this post, I provide some simple action filters to perform such a graceful degradation.
Logging of both good and failed requests is a very good practice. But logs are no good if we cannot easily filter and figure what to act on, like fixing URLs that frequently returns 404 or 500 errors. I will show how to easily query those requests from Application Insights.
Logging is a very good practice in every application. Both good and bad events or outcomes should be logged to be on top of what happens. But how to log structured and searchable metadata that can be aggregated and monitored? I got a solution here.
Caring much about the performance of my code, this blog post is a continuation of my serial about performance optimization of Episerver solutions. This time I reveal eight common issues affecting performance, along with suggested solutions to each. Some of those issues are actually very common across projects and developers.
Caching is great! Caching can make a slow site fast, and a fast site blazingly fast. But how to cache custom objects that rely on Episerver content, in a way that is simple, safe and performant way?