Add support for IDistributedCache to the SDK

[xantari]

Motivation

Currently, the SDK provides a CacheManager that uses IMemoryCache.

In order to support more advanced scenarios utilizing commonly used distributed caching libraries such as:

• Microsoft.Extensions.Caching.Distributed.MemoryDistributedCache
• Microsoft.Extensions.Caching.Redis.RedisCache
• Microsoft.Extensions.Caching.SqlServer.SqlServerCache
• Microsoft.Extensions.Caching.StackExchangeRedis.RedisCache

we'd like to introduce support for the IDistributedCache interface.

Proposed solution

There are several approaches that we can take:

1. Create a new implementation if the IDeliveryCacheManager that would be able to serialize the Delivery*Response objects. Depending on whether the implementation will be byte[]-based or string-based, it will require some changes in the Delivery*Response and underlying objects (such as Taxonomy) in terms of decorating them with certain attributes, implementing serializers, etc.
   If we choose to go this way, I'd vote for:

• moving all the logic from the Delivery*Response objects to the DeliveryClient (everything that's related to IModelProvider or Newtonsoft.Json)
• removing Kentico.Kontent.Delivery.Abstractions's dependency on Newtonsoft.Json.Linq
• getting rid of dynamic properties - I think we can replace them with strongly-typed collections of objects (not sure why we haven't done so yet)
• make all the models POCO with public constructors
  This approach is best performance-wise as it stores the objects after the strong typing facilitated by IModelProvider. And also goes in line with the caching model we've laid out with the introduction of the IDeliveryCacheManager.

2. Implement an HTTP response-level caching. This can be achieved e.g. using Polly

• https://nodogmablog.bryanhogan.net/2018/11/caching-in-polly-6-and-the-httpclientfactory/
• https://github.com/App-vNext/Polly/wiki/Cache
• Polly.Caching.MemoryCache
• Polly.Caching.IDistributedCache
  This would be advantageous in that we could reuse the newly supported HttpClientFactory and use a more standardized approach to caching. However, I'm not sure how the cache eviction would work and whether we could somehow reuse the IDeliveryCacheManager which is also used to invalidate cache keys (e.g. by webhook calls).

3. Similar to (2) - introduce the caching on the level of DeliveryClient.GetDeliverResponseAsync

Let's try the approach no. 1 first.

Additional context

• See the discussion on issues with binary serialization of the Delivery*Response objects in (Binary) serialization of Taxonomies not supported #192
• https://dev.to/j0nimost/implementing-cache-in-net-core-3-0-part1-4bkj

[petrsvihlik]

we'll probably use a DI-based contract resolver and load classes AsImplementedInterfaces

the question is whether to use Autofact or something simpler such as Scrutor: https://github.com/khellang/Scrutor

[petrsvihlik]

done in #226

[petrsvihlik]

Hey @xantari
would you like to give it a try? any feedback would help us a ton!

[xantari]

@petrsvihlik Opened bug #227 That I found while testing this.

[xantari]

@petrsvihlik Found another one: #228

[xantari]

@petrsvihlik So far it seems to work well except that I've found a different issue I hadn't anticipated.

Everyone is working from home for a few months now, and as such we are operating over VPN. Our VPN tunnel maxes out at around 1MB/s (which is another issue altogether) and I don't have super fast upload speed.

The BSON serialized data is fairly massive for some reason when being placed into the cache (which is sending/receiving data over the VPN to our SQL Server (which uses in Memory SQL tables so it's supposed to be fast).

I have no idea why the BSON objects are so massive, but it took my home page about 99 seconds to load now as it had to store/fetch the cached data over VPN.

See here for length of data:

You'll see our mega menu is 14 megabytes!

I'm trying to figure out why the BSON values are so large.

[xantari]

BTW, I tested a bit with some of the objects as just JSON, and they are just as big. So it's really just a matter for us to figure out how to get our own local distributed caches setup for each developer that doesn't go over a slow data link...

[xantari]

BTW, Thanks so much for this feature!!!

[petrsvihlik]

@xantari thank you for testing it!

I added an example of how to make it work with a local Redis instance on Windows: https://github.com/Kentico/kontent-delivery-sdk-net/wiki/Caching-responses#distributed-caching---example-from-v1400-rc1

[petrsvihlik]

@xantari btw I tested (.\bombardier.exe -l -c 125 -r 5000 -d 10s https://localhost:5001) the Redis cache on my local windows machine on the .NET boilerplate project and the results are pretty impressive. The response times were at about 50ms and throughput about 4.7K requests/s.